GitHub mostantól 48 órával a létrehozásuk után lejáratja az ellenőrizetlen npm trusted publishing konfigurációkat, miután kutatók kimutatták, hogy egy támadó úgy is feltölthetett új verziót más felhasználó csomagjához, hogy nem kellett hozzá megszereznie az áldozat hitelesítő adatait.

„A konfigurációd az első sikeres publikálás után válik ellenőrzötté, és onnantól nem jár le” – közölte a Microsoft tulajdonában lévő leányvállalat, GitHub közleménye. „Ha megváltozik a tároló vagy a projekt azonosítója, új bizalmi kapcsolatot kell létrehozni, új, 48 órás ellenőrzési időablakkal – a szokásos szerkesztések nem indítják újra a határidőt.”

A módosítás csökkenti annak kockázatát, hogy egy tároló vagy projekt neve tulajdonosváltás után is megbízhatónak számítson – tette hozzá GitHub. Emellett az npm mostantól elutasítja a trusted publishing tokeneket a GitHub Actions issue_comment eseményeiből is, az eddig is érvényben lévő pull_request_target korlátozás mellett.

A dokumentáció frissítésében GitHub rögzíti, hogy az újonnan létrehozott trusted publisher konfigurációnak két napon belül végre kell hajtania az első sikeres publikálást. Ez hitelesíti a konfigurációt, és hozzáköti a „tároló megváltoztathatatlan azonosítójához”.

A lépés a Bloom Security eredményeire reagál. A cég feltárt egy kiskaput az npm trusted publishing megoldásában, amellyel több ezer csomagot át lehetett venni, és Shai-Hulud-szerű, láncreakciós ellátási lánc támadást lehetett kiváltani. A hibát 2026. június 6-án jelentették GitHub felé.

„Képzeljük el: egy támadó feltör egyetlen csomagot. Egy népszerű csomag karbantartójának gépén futó AI ügynök automatikusan lehúzza egy projekthez” – mondta Golan Myers biztonsági kutató. „Ezt az egy végpontot használják arra, hogy rosszindulatú kódot toljon fel a népszerű csomagba. A csomag összes felhasználója ki van téve a veszélynek. Mindez azért, mert egyetlen, megfelelő jogosultságokkal rendelkező ember kompromittálódott.”

A trusted publishing funkciót 2025 júliusában vezették be az npm-ben, hitelesítő adatok nélküli azonosítási módszerként. Lehetővé teszi, hogy a fejlesztők CI/CD platformról – például GitHub Actions segítségével – töltsenek fel npm csomagokat OpenID Connect (OIDC) tokenekkel.

Trusted publishing használatakor a fejlesztő CI/CD szolgáltatója egy adott workflow futáshoz rövid élettartamú kriptográfiai tokent generál, amelyet az npm registry egy előzetesen engedélyezett konfiguráció alapján ellenőriz.

Ez megszünteti a hosszú élettartamú npm titkok tárolásának, cseréjének és kézi kezelésének szükségességét, így csökkenti a hitelesítő adatok kiszivárgásának kockázatát. Emellett automatikusan provenance attestations-t hoz létre az npm csomagokhoz, ami lehetővé teszi a felhasználóknak, hogy megállapítsák, hol készült a csomag, és ki tette közzé, ezzel erősítve a szoftver-ellátási lánc biztonságát.

A Bloom Security kutatása szerint azonban ennek a biztonsági architektúrának hibája volt abban, ahogyan az adott tárolót azonosította. Ezt slugnak is hívják, vagyis a tulajdonos vagy szervezet és a tároló nevének kombinációját, „owner/repository” formátumban.

„A tároló címét rögzíti […] ahelyett, hogy a GitHub által hozzárendelt állandó azonosítót használná – legalábbis addig, amíg ebből a tárolóból először nem adnak ki verziót” – magyarázta Myers. „Olyan ez, mintha a zár azt ellenőrizné, mi van kiírva az ajtóra, nem pedig azt, kié a ház: ha a tulajdonos elköltözik, az kapja meg a kulcsot, aki beköltözik.”

Másképp fogalmazva: a numerikus azonosítók, amelyek megmaradnak a tároló átnevezése vagy áthelyezése után is, bekerülnek a GitHub OIDC tokenjeibe, az npm viszont teljesen figyelmen kívül hagyja őket egészen addig, amíg abból a tárolóból először sikeresen nem publikálnak.

Így a bizalom egy névhez kötődik, nem pedig egy megváltoztathatatlan tárolóazonosítóhoz. Ezt a kiskaput úgy lehet kihasználni, hogy valaki lefoglal egy elhagyott slugot, és ezzel örökli a hozzá tartozó bizalmat. Ahhoz, hogy a támadás sikerüljön, csak az szükséges, hogy az áldozat trusted publisher beállítása egy olyan GitHub slugra mutasson, amelyet a támadó meg tud szerezni, és a tárolóból még soha nem publikáltak verziót az npm-re.

Amint egy ilyen slug felszabadul, miután a karbantartó átnevezi, áthelyezi vagy törli a tárolót, a támadó a következő lépéseket követheti:

• Létrehoz egy tárolót a felszabadult „owner/repository” útvonalon, amitől a GitHub új tárolóazonosítót ad ki.
• Létrehoz és elindít egy npm publish workflow-t, amely OIDC tokent generál az újra megszerzett sluggal és az új numerikus tárolóazonosítóval.
• Beküldi a tokent az npm exchange végpontra. Az npm látja, hogy a tárolóra vonatkozó állítás egyezik a tárolt sluggal, és kiad egy publish hitelesítőt.
• A támadó időkorlátos publish tokent kap egy olyan csomaghoz, amely nem az övé, és rosszindulatú módosításokat tolhat fel a registry-be.

Az ilyen típusú támadást SlugFest kódnéven emlegetik. Lehetővé teszi, hogy a támadó egy új, „rosszindulatú” verziót adjon ki az áldozat csomagjából a legitim csomagnév alatt, miközben örökli a meglévő hírnevet, letöltésszámot és függőségi kapcsolatokat. Ez pedig nagyszabású ellátási lánc támadásokhoz vezethet.

A fejlesztői gépeken futó AI agentek tovább bonyolítják a helyzetet. „Az agentek maguk oldják fel a függőségeket, jellemzően a legújabb verziót választják, és ritkán ellenőrzik, honnan származik a csomag” – közölte a Bloom Security. „Ha egy visszaszerzett slugon keresztül rosszindulatú verzió kerül kiadásra, az emberi ellenőrzés nélkül töltődik le és fut le.”

A kiberbiztonsági cég szerint több mint 1500 sebezhető csomagot találtak, amelyeket összesen már több mint 10 millió alkalommal töltöttek le.

Az npm csomagokat karbantartó fejlesztőknek a következő lépéseket javasolják:

• Ellenőrizzék a trusted publisher kötéseket, és győződjenek meg róla, hogy a felsorolt repository slug továbbra is egy általuk felügyelt tárolóra mutat.
• Ha a repository nevét megváltoztatták vagy áthelyezték, töröljék a meglévő trust bindingot, és hozzák létre újra az aktuális slugra mutatva.
• Figyeljék az előre nem várt npm publish eseményeket.
• Minden alkalommal töröljék a trust bindingokat, amikor egy repository-t törölnek, áthelyeznek vagy átneveznek.

„A támadáshoz nincs szükség bennfentes tudásra, hitelesítő adatok ellopására vagy versenyhelyzetre” – mondta Myers. „Az egyetlen előfeltétel a slug elérhetősége (egy olyan bindingnál, amelyet még nem használtak publishra), ami teljes egészében az áldozat saját repository-higiéniáján múlik.”

„A kutatás azt mutatja meg, amit a biztonsági közösség újra és újra lát az ellátási lánc elleni támadásoknál: az ember által olvasható azonosító és az általa jelölt dolog közötti kötés a legfontosabb állandó bármilyen bizalmi rendszerben. Ha ezt a kötést észrevétlenül ki lehet cserélni – pusztán egy repository átnevezésével, nem pedig támadói tevékenységgel –, a bizalmi garancia összeomlik.”

Nem ez az első alkalom, hogy szokatlan ellátási lánc támadási vektorokat azonosítottak. Augusztus elején a Bloom Security azt is kimutatta, hogy az Open VSX és a Microsoft VS Code Marketplace egyaránt lehetővé tette, hogy extension packek a piactereken nem létező extensionökre hivatkozzanak.

Az Extension Resurrection néven emlegetett technikát fel lehet használni arra, hogy eltérítsék azokat az extensionöket, amelyekre ezek a megbízhatónak tekintett csomagok már hivatkoznak, pusztán azzal, hogy lefoglalnak egy üresen hagyott névteret. Az Open VSX-ben 87, a VS Code Marketplace-en pedig 677 packet jelöltek sebezhetőként.

„A támadók lefoglalhatják ezeket az üres helyeket, rosszindulatú kódot tehetnek közzé alattuk, ami automatikusan települ a megbízható packkel együtt – így észrevétlenül juttatnak el frissítéseket mindenkihez, aki korábban telepítette a packot” – jegyezte meg akkor Myers. „Mivel az extensionök teljes hozzáféréssel futnak a hosthoz, ez gyakorlatilag távoli kódfuttatást jelent, a legitimáció látszata mögé rejtve.”