72 óra kiberbiztonsági káosz (2026. október 19–21.)

Időszak: 2026. október 19–21.

‍Esetek: 11. Ezek ellátásilánc-támadások, bizalmi infrastruktúra elleni incidensek, ügyféladat-kitettségek és kritikus biztonsági javítások.

‍Kiindulópont: egy „72 Hours of Cybersecurity Chaos” infografika. Minden esetet külön, elsődleges vagy megbízható forrásból ellenőriztem (lásd a forráslistát a végén).

Mi történt

Milyen kár keletkezett

• Aktívan kihasznált hibák: az Amazon szerint a PHP2Shell-hibákat széles körben kihasználják. Az UpdraftCentral-kulcsokkal október 18. és 19. között ténylegesen hátsó ajtót telepítettek WordPress-oldalakra. A hátsó ajtó rejtett Editor-fiókot hoz létre, amely megkerüli a bejelentkezést és a kétlépcsős azonosítást, és a bővítmény törlése után is megmarad.
• Fertőzött kiadás: a LiteLLM kártékony v1.107.0 kiadása a PyPI-n kb. 1,5 órán át, a Docker Hubon kb. 2,5 órán át volt elérhető. Aki ekkor telepítette, annak a gépéről a kártevő minden elérhető felhős és API-kulcsot ellophatott.
• Kitett titkok és adatok:
  • Railway: ügyfelek API-kulcsai, adatbázis- és registry-hitelesítő adatai kerülhettek ki.
  • SBI: 3 897 ügyfél neve, telefonszáma, születési dátuma, címe és hitelezési adatai jelentek meg a dark weben.
  • ConnectWise: a Huntress szerint legalább 162 Microsoft 365-bérlő kompromittálódott.
• Bizalmi kockázat: az eMudhra gyenge kulcsaival a böngészők által elfogadott hamis tanúsítványokat lehetett volna kiállítani. Visszaélésről nincs adat. Az eMudhra kilép a globális SSL/TLS-piacról.
• Kihasználás nélküli kritikus hibák: a Chrome, a GitLab, a Node.js és a Cisco esetében kihasználásról nincs hír, de a súlyosság miatt azonnali frissítés indokolt.

Milyen biztonsági hiányosságok vezettek az esetekhez

A 11 esetből legalább öt nem klasszikus programhiba, hanem kulcs- és bizalomkezelési hiba:

• LiteLLM: egy nyilvános GitHub-tárolóba 2026. május 27-én véletlenül bekerült egy mesterkulcs. Ezzel a támadók GitHub-tokeneket szereztek, megkerülték az ágvédelmet és a kiadási jóváhagyást, és egy hasonló nevű tárolóból adták ki a kártékony verziót.
• UpdraftCentral: a kulcsok a felhőből szivárogtak ki. A Patchstack értékelése szerint a kulcs létrehozása alapértelmezetten be van kapcsolva, a kulcsok soha nem járnak le, és az oldalak minden aláírt parancsot külön megerősítés nélkül végrehajtanak.
• eMudhra: egy szkripthiba miatt a 2025. áprilisi kulcsgeneráláskor egy második, gyenge kulcskészlet jött létre. Mivel a címkéi hasonlítottak a helyes kulcsokéra, tévedésből ezt használták aláírásra.
• ConnectWise: egy több bérlős beszállítói OAuth-alkalmazás széles jogosultságait használták ki. Egy esetben az alkalmazás globális rendszergazdai szerepkört rendelt magához.
• Railway, SBI: a kiváltó okot egyik szervezet sem közölte. Az SBI esetében egy indiai digitális jogi szervezet felvetette, hogy az adatok közvetítőkön vagy értékesítési ügynökökön keresztül szivárogtak ki (nem megerősített feltevés).
• A többi eset (PHP, GitLab, Node.js, Chrome, Cisco) memóriakezelési és egyéb programhiba. Itt a gyors javítás a lényeg, beleértve a beágyazott példányokat és a saját tanúsítványtárakat is.

Mi a tanulság, mit kell tenni

1. A titkokat leltárba kell venni. Tudni kell, hol vannak API-kulcsok, tokenek és tanúsítványok. A kódtárolókat titokkeresővel kell rendszeresen átvizsgálni.
2. Rövid élettartam és rotáció. A távfelügyeleti és integrációs kulcsoknak legyen lejárata. Incidens esetén minden érintett kulcsot azonnal cserélni kell. A Railway, a LiteLLM és az UpdraftCentral érintettjeinek is ez az első teendője.
3. Ellátási lánc. A függőségeket rögzített verzióval kell telepíteni (pin), és ellenőrizni kell a kiadások eredetét. A LiteLLM-et használóknak a gyártó a litellm==1.106.2-t javasolja, és a környezet teljes újraépítését.
4. Beszállítói hozzáférések. A felhős alkalmazások és szolgáltatásnevek jogosultságait rendszeresen felül kell vizsgálni. A nem használt integrációkat le kell tiltani.
5. Gyors javítás. A kihasznált kritikus hibákat (PHP2Shell) napokon belül, a CVSS 9–10-es hibákat (GitLab, Snort 3) soron kívül kell javítani. Frissíteni kell a saját tanúsítványtárat használó szoftvereket (Go, Python certifi, Node) is az eMudhra-tanúsítványok visszavonása miatt.
6. Ügyfélértesítés. Adatkitettségnél az érintetteket értesíteni kell. Az SBI-t éppen azért érte kritika, mert a befektetőket tájékoztatta, az érintett ügyfeleket nem.

Egy mondatban: a 72 óra legtöbb esetében nem programhiba, hanem egy rosszul kezelt kulcs nyitotta ki az ajtót. A titkok kezelése ma ugyanolyan fontos, mint a javítások telepítése.

Megjegyzések a forrásokhoz

• A The Hacker News cikkoldalai nem voltak megnyithatók, onnan csak az RSS-összefoglalókat használtam. A tényeket gyártói és kutatói közleményekből, illetve megbízható másodlagos forrásokból ellenőriztem.
• Pontosítások az infografikához képest:
  • eMudhra: a kulcsokat nem ellopták, hanem gyengén generálták, ezért voltak visszafejthetők.
  • UpdraftCentral: a kihasználás október 18-án kezdődött.
  • Cisco: mindkét kiadás belső tesztelésből származik, kihasználásról nem tudni.
  • Chrome: a 6 kritikus hiba kihasználásáról nincs adat.
• Csak keresési találatból származó, nem ellenőrzött adatok:
  • Az UpdraftCentral érintett oldalainak becsült száma (kb. 400 ezer).
  • A TeamUpdraft ügyféladatbázisának feltörése és az UpdraftPlus 1.26.13-as javító kiadása.
  • A Chrome kritikus CVE-listája egy másodlagos forrásból (GBHackers) származik, a Google közleményének szövege nem jelent meg teljesen.
• A 162+ bérlő a Huntress adata a ConnectWise-esetről (a 2026. október 19-i heti riportból).
• Az SBI-ügyben a „Siriusim” nevű csoport 375 ezer sorra és 2 722 PDF-re vonatkozó állítása nem ellenőrzött.