Ebben a hírlevélben a legtöbb biztonsági történet közvetlenül veled történő dolgokról szól: egy adathalász SMS-ről, egy kiszivárgott jelszóról, egy hamis webáruházról. Ez most más. Az alábbi incidensek a fejlesztőkkel történtek — azokkal az emberekkel, akik az általad nap mint nap használt alkalmazásokat és szolgáltatásokat írják. Azért tartoznak mégis ide, mert az ok egyszerű: ha valaki megmérgezi a szoftverek készítéséhez használt eszközöket, a méreg nem marad a készítőnél. A termékkel együtt kerül ki.

Nemrég két olyan dolog is történt, amely jól szemlélteti ezt. Egyik sem kapott akkora figyelmet, mint egy nagy adatbetörés, mert egyik sem kifejezetten téged érintő betörés. Mindkettő azt a folyamatot támadja, amely előállítja a szoftvert, amit később telepítesz, megnyitsz vagy amelybe bejelentkezel.

Megbízható márkának álcázott hamis bővítmények

Az Open VSX nyilvános piactér kódszerkesztő-bővítmények számára — ezek azok a kis kiegészítők, amelyeket a fejlesztők azért telepítenek, hogy automatikus kódkiegészítést, lintelést és integrációkat kapjanak a naponta használt eszközeikhez (a Visual Studio Code és több nyílt forráskódú rokona is innen tölt le). 2026. július 26. és augusztus 1. között a Manifold Security biztonsági kutatói 77 hamis bővítményt találtak a nyilvántartásban. Mindegyik egy valódi, megbízható bővítmény nevét és névterét másolta, de olyan fiókból tették közzé, amely nem birtokolta az eredetit — ez a megszemélyesítés klasszikus esete, amelyet néha névtérfoglalásnak neveznek.

A lefoglalt nevek nem véletlenszerűek voltak. Az AMD, a LEGO Education, a Hyperledger, az Azure, az Artsy, a Salesforce nyílt forráskódú projektjei, egy amerikai szövetségi ügynökség, valamint — egyfajta sötét iróniával — maga a bővítménypiactér identitását kölcsönözték. A 77 csomag mindegyike egyetlen domainre telefonált haza, amelyet mindössze 11 nappal az első hamis csomag megjelenése előtt regisztráltak; ez a minta összehangolt, célzott kampányra utal, nem opportunista másolgatásra.

A hamis bővítmények többsége szerény dolgot művelt: csendben visszaküldte a gépnevet a támadó szerverére, ami önmagában talán csak annak ellenőrzése volt, hogy ki telepítette a csalit. A kutatók azonban azt találták, hogy a 77-ből nagyjából egynegyed — 19 csomag — ennél tovább ment. Az aktiválás után néhány másodperccel begyűjtötték a gépnevet, az operációs rendszer felhasználónevét, a szerkesztő adatait és a gépazonosítót. Ezután elolvasták azt a projektet, amelyet a fejlesztő megnyitva tartott: a git távoli tárhelyét (amely felfedi a szervezetet és a tárhelyszolgáltatót), a commit e-mail-domainjét, az aktuális ágat és a legutóbbi commitot. A folyamatos integráció értékeit is lekérték — azokat a hitelesítő adatokat és konfigurációkat, amelyek lehetővé teszik, hogy az automatizált rendszerek emberi jelszóbevitel nélkül építsék és telepítsék a kódot.

Ezek az adatok nem használhatók valaki bankszámlájának megcsapolására. Másra viszont igen: annak kiderítésére, hogy a fejlesztő mely vállalatoknak dolgozik, hogyan néz ki a belső infrastruktúrájuk, és miként lehet beférkőzni oda.

9,8-as, tízből értékelt hiba a szoftvert felépítő gépben

A második incidens a TeamCityt érinti, amely a JetBrains által készített folyamatos integrációs és folyamatos szállítási (CI/CD) platform. Ha a kódszerkesztő az a hely, ahol a fejlesztők megírják a szoftvert, akkor a CI/CD-platform az automatizált gyártósor, ahol a kódot lefordítják, tesztelik és éles környezetbe küldik — gyakran úgy, hogy egyetlen ember sem kattint a „telepítés” gombra. A TeamCity sok vállalatnál ennek a gépezetnek központi eleme.

A CVE-2026-63077 néven nyilvántartott, a lehetséges 10-ből 9,8-as súlyossági értékű sérülékenységet a TeamCity helyben telepített verzióiban hozták nyilvánosságra. Ez deszerializációs hiba — olyan hibakategória, amelyben a program annyira megbízik a beérkező adatokban, hogy ellenőrzés nélkül közvetlenül futó kóddá alakítja azokat. A gyakorlatban ez lehetővé tette, hogy a támadó bejelentkezés nélkül kérést küldjön egy sérülékeny TeamCity-szervernek, és tetszőleges parancsokat futtasson, magának a TeamCity-szolgáltatásnak a jogosultságaival. A JetBrains javításokat adott ki (2025.11.7 és 2026.1.3 verziókhoz, valamint javító plugint a régebbi, 2017.1 vagy újabb telepítésekhez), az Egyesült Államok Kiberbiztonsági és Infrastruktúravédelmi Ügynöksége (CISA) azonban azóta arra figyelmeztet, hogy a támadók aktívan kihasználják a javítatlan rendszereket.

Aki irányítja egy vállalat buildszerverét, az irányítja azt is, mit szállít a vállalat. Ez nem elméleti felvetés — szó szerint ez az eszköz feladata.

Ugyanaz a forgatókönyv, két különböző bejárat

Ezek egymástól független incidensek, különböző kutatóktól, mégis hasonló a mintázatuk. Egyik sem egy kész terméket támad. Mindkettő egy korábbi lépést támad — azt a szerkesztőt, amelyben a fejlesztő kódot ír, vagy azt a szervert, amely a kódból kiadott verziót készít. Ez a szoftverellátási lánc elleni támadás meghatározó jellemzője: egyetlen célpont feltörése helyett egy olyan upstream elemet kompromittálsz, amelytől sok célpont függ, és hagyod, hogy a saját megbízható folyamatuk vigye tovább helyetted a hozzáférésedet.

Érdemes őszintén beszélni arról, amit még nem tudunk. A héten napvilágot látott egyik jelentés sem tárt fel megerősített esetet arról, hogy egy downstream alkalmazást vagy felhasználót közvetlenül ennek következtében kompromittáltak volna — a bővítménykampány felderítésnek és hozzáférésgyűjtésnek tűnik, a TeamCity kihasználását pedig aktívként írják le, megnevezett áldozatok nélkül. Ez megszokott; az ellátásilánc-kompromittálásokat gyakran jóval azelőtt fedezik fel a belépési pontnál, hogy (vagy ahelyett, hogy) a végső következményeket vissza lehetne követni.

Miért a te problémád is, nem csak az övék

Valószínűleg soha nem telepítesz kódolási bővítményt, és nem üzemeltetsz CI/CD-szervert. De több száz ilyen rendszer kimenetét használod: a banki alkalmazásodat, a jelszókezelődet, a gyereked iskolai portálját, azt a böngészőt, amelyben ezt olvasod. Mindez átment valamelyik fejlesztő szerkesztőjén és valamelyik vállalat buildfolyamatán, mielőtt eljutott a telefonodra. Ha e lánc bármelyik elemét csendben kompromittálják, a rosszindulatú módosítás egy szokásos, rutinszerű szoftverfrissítéssel együtt érkezhet — olyannal, amelyet azért telepítesz, mert azt mondták, hogy a frissítés a biztonságos megoldás.

Ezért hangzik a jogsértési utóelemzésekben szereplő tanács néha furcsán a nem műszaki olvasók számára: egy vállalat azt mondja, hogy rendszereit egy buildszerveren keresztül, egy ellopott fejlesztői hitelesítő adattal vagy egy rosszindulatú függőséggel kompromittálták, és ez elvontnak tűnhet azzal szemben, hogy „valaki kitalálta a jelszavamat”. Pedig nem elvont. Ugyanaz az eredmény — az adataid vagy az alkalmazásod sértetlenségének kompromittálása — egy olyan ajtón keresztül következett be, amelynek létezéséről nem is tudtál.

Ami ténylegesen segít

Nem tudod ellenőrizni a bankod CI/CD-folyamatát, és nem is kellene. Néhány szokás azonban valóban csökkenti az ilyen típusú kockázatnak való kitettségedet:

Tartsd bekapcsolva az automatikus frissítéseket, de ne tekintsd a frissítéseket automatikusan megbízhatónak. A frissítések révén jutnak el a futtatott szoftverekhez az olyan javítások, mint a fent említett TeamCity-javítás — a naprakészség bezárja azokat a réseket, amelyeket a támadók aktívan vizsgálnak. Ugyanakkor egy frissítés csak annyira jó, amennyire jó az azt előállító folyamat, és éppen ezt a folyamatot célozzák itt; nincs tökéletes egyéni védelem egy valóban megmérgezett upstream kiadással szemben, ezért ez alapvetően a szolgáltató felelőssége, nem a te problémád.

Ha fejlesztőkkel dolgozol vagy fejlesztőket irányítasz, két konkrét, ellenőrizhető teendő: győződj meg róla, hogy minden kódszerkesztő-bővítményt a ténylegesen ellenőrzött kiadói fiókból telepítettek, nem csupán egyező név alapján (az Open VSX és a hasonló piacterek feltüntetik a kiadó kilétét — ellenőrizd, ne csak az ikonban és a címben bízz); ha pedig a szervezeted helyben telepített TeamCityt futtat, még ma ellenőrizd, hogy a 2025.11.7 vagy 2026.1.3 verziót használja-e, illetve alkalmazták-e a javító plugint, ne a következő karbantartási ablakban — a CISA figyelmeztetése azt jelenti, hogy ezt aktívan kihasználják, nem csupán elméleti veszélyről van szó.

Mindenki más számára a hasznos szemléletváltás egyszerűen a tudatosság: amikor egy vállalati adatbetörésről azt olvasod, hogy „kompromittált fejlesztői eszközre” vagy „buildrendszerre” vezethető vissza, az nem valami szűk körű technikai lábjegyzet. Ugyanabba az eseménykategóriába tartozik, mint a jelszószivárgások és az adathalász csalások, amelyekről ez a hírlevél gyakrabban ír — csak egy réteggel feljebb kezdődött, még azelőtt, hogy a termék egyáltalán eljutott volna hozzád.