Október 19-én, hétfőn 14:47-kor valaki lecserélte az OVHcloud parancssori eszközének (ovhcloud CLI) egyik letölthető fájlját. 15:30-ra már öt kiadás összes fájlja kártevős volt, a v0.11.0-tól a v0.15.0-ig. 16:21-kor az OVHcloud mindet leszedte. A kettő között nagyjából 250 letöltés történt.

Átnéztem a cég október 20-i biztonsági közleményét. A legérdekesebb rész az ok. A támadó nem az OVHcloud rendszerét törte fel.

Egy fejlesztő személyes MacBookjára 2025. október 20-án felkerült egy színválasztó bővítmény. A közlemény szerint ez fertőzött volt. Az onnan ellopott kulcsokkal módosították a kiadásokat, majdnem pontosan egy évvel később.

A beszállítója legnagyobb kockázata tehát nem a céges rendszere, hanem a fejlesztője otthoni gépe és személyes fiókja.

Mit vitt el a kártevő

Az OVHcloud szerint a támadók az eredeti eszközt fordították újra, és adatlopó kódot építettek bele. A közlemény listája:

Kategória Mit keresett
Szerverhozzáférés SSH-kulcsok
Felhőfiókok AWS, Google Cloud, Azure és DigitalOcean hozzáférései
Infrastruktúra Docker- és Kubernetes-konfiguráció, Terraform-kulcsok
Fejlesztői fiókok .netrc, globális Git-beállítás, NPM-beállítás
AI-kódolóeszközök VS Code, Cursor, Continue, Sourcegraph Cody, OpenCode, Hermes és Claude helyi adatai, előzményei

Az utolsó sorból látszik, hogy a támadók már az AI-eszközök fájljaiban is titkot keresnek. Egy AI-asszisztens beszélgetési előzményében könnyen ott marad egy beillesztett jelszó vagy API-kulcs. Ezek az előzmények ugyanúgy a gépen vannak, mint az SSH-kulcs.

A program a gyűjtött fájlokat archívumba csomagolta, és egy külső szerverre küldte. A gyártó szerint aki az időablakban letöltötte és futtatta az eszközt, annak minden titka érintett. Ami azon a gépen volt, azt úgy kell kezelni, mintha kiszivárgott volna.

Miért nem az OVHcloud a sztori

Az OVHcloud gyorsan reagált. Egy ügyfél 15:50-kor jelezte a gyanús működést. 31 perccel később minden fertőzött fájl lekerült. 19:16-kor kiadták a tiszta v0.16.0-t. A közlemény szerint a forráskód és a belső buildrendszer nem sérült.

A gyenge pont kettő volt, és mindkettőt ők maguk írták le. A GitHubon a kiadásokat utólag módosítani lehetett. A cég GitHub-szervezetéhez pedig a fejlesztők a személyes fiókjukkal csatlakozhattak. A közlemény hozzáteszi, hogy a legtöbb techcég így dolgozik.

A minta nem új. A Vercel áprilisi betörése is egy beszállító munkatársának otthoni gépéről indult.

Ez a mondat szól a magyar cégvezetőnek. A fertőzött bővítmény 2025 októberében került fel, a kiadásokat 2026 októberében cserélték le. Egy nagy európai felhőszolgáltatónál is egy ügyfél vette észre a bajt. A 12 fős fejlesztőpartnerénél ki venné észre?

Mit mond a magyar törvény

Az EU kiberbiztonsági irányelvét (NIS2) Magyarországon a 2024. évi LXIX. törvény ültette át. A 6. § (5) d) pontja a közreműködőkről szól. Ilyen az, aki a cég rendszerét létrehozza, üzemelteti vagy karbantartja. Ilyenkor a vezetőnek kell gondoskodnia arról, hogy a szükséges kiberbiztonsági követelmények szerződéses kötelemként teljesüljenek.

A 6. § (6) szerint a vezető ilyenkor is felel. A 11. § (9) a cég informatikai biztonsági felelősének ad jogot. A törvény szóhasználatában ez az elektronikus információs rendszer biztonságáért felelős személy. Ő tájékoztatást kérhet a közreműködőtől a követelmények teljesüléséről.

Lefordítva: ha a cége a törvény hatálya alá tartozik, az IT-partnere személyes gépe az Ön megfelelési kérdése. Ha Ön a beszállító, a kérdés visszafelé is megjön: a belga partner is bizonyítékot kér.

Ördög ügyvédje

Ha a tézis igaz, minden 10 és 250 fő közötti cégnek át kellene írnia a beszállítói szerződéseit. Az első megszorítás a törvény hatálya.

A versenyszférában a törvény főleg a 2. és 3. mellékletben felsorolt ágazatok cégeire vonatkozik. Ezek közül azokra, amelyek középvállalkozásnak minősülnek vagy legalább 50 főt foglalkoztatnak. Ugyanígy azokra, amelyeknek az árbevétele és a mérlegfőösszege is meghaladja a 10 millió eurót [1. § (1) d)]. Néhány szolgáltatótípusra mérettől függetlenül [1. § (1) e)]. Egy 20 fős kisvállalkozásnak, amely nem ezekben az ágazatokban működik, ez nem kötelezettség, csak jó gyakorlat.

A második megszorítás a szerződésről szól. A szerződés nem állítja meg a fertőzött bővítményt. Annyit tud, hogy előre tisztázza, ki ellenőrzi a fejlesztői gépeket, mikor kell jelezni, és ki fizeti a kulcscserét. Ez kevesebb, mint védelem. Incidens után viszont ebből derül ki, ki mit köteles tenni. Kiindulásnak jó a 12 pontos beszállítói kiberkérdőív.

A harmadik: a nagyjából 250 letöltés világszám. Magyar érintettségről nincs adat, és ebből a cikkből sem következik, hogy lenne.

Három kérdés hétfőre

  1. Futtatta-e valaki az ovhcloud CLI-t október 19-én 14:47 és 16:21 között? Önöknél vagy az IT-partnernél. Ha igen: az érintett titkok cseréje vagy letiltása, a fájl törlése, a v0.16.0 telepítése. Ez a gyártó saját teendőlistája.
  2. Tárol-e valaki céges hozzáférést személyes gépen vagy személyes fiókban? Ha erre senki nem tud gyors választ adni, az is válasz.
  3. Mi van erről a szerződésben? Ki ellenőrzi a fejlesztői eszközöket, mennyi idő alatt jelez a partner incidenst, és ki fizeti a helyreállítást?

Az OVHcloud 31 perc alatt lezárta az incidenst. A rést egy évvel korábban nyitotta meg egy otthoni gépre telepített bővítmény.

Források
  2. 2024. évi LXIX. törvény Magyarország kiberbiztonságáról, Nemzeti Jogszabálytár (2026. október 1-jei időállapot)

Kiber · Vas Marcell

Jogi megjegyzés: tájékozódás, nem jogi tanács. Incidensnél szakértő.

AI-közreműködés: AI-asszisztált szöveg, Vas Marcell persona, szerkesztői jóváhagyással. (Loop Magazin, 2026)