Két rosszindulatú LiteLLM-kiadás jelent meg márciusban a PyPI-n, nagyjából 40 percre. Olyan hitelesítőadat-lopó kódot tartalmaztak, amely képes volt felhőkulcsokat, SSH-kulcsokat, Kubernetes-tokeneket, adatbázis-jelszavakat és más titkokat begyűjteni azokról a rendszerekről, amelyek telepítették őket.

A CloudSEK kiberfenyegetés-elemző cég most azt közölte, hogy egy általa megszerzett adathalmaz – amely nagyjából 434 000, a támadók által begyűjtött fájlból áll – több mint 2500 szervezet esetében jelezhet potenciális kitettséget.

Ezek a számok nem az áldozatok számát jelentik. A CloudSEK a The Hacker Newsnak elmondta, hogy az anyag bizalmas hírszerzési forrásokból származik, és olyan zsákmányolt fájlokból és logokból áll, amelyeket a kampányhoz tartozónak ítéltek, nem pedig az általuk megnevezett szervezetektől közvetlenül gyűjtött adatokból. A fájlokat tehát ellopták.

A CloudSEK az adathalmazt nyilvános keresőként tette közzé, amely név vagy domain alapján kereshető, és bizalmi szint szerint szűrhető. Minden sorban szerepel a szervezet neve és domainje, a kiszivárgott titkok száma, a futások száma, valamint egy High vagy Medium minősítés.

A magas bizalmi szint azt állítja, hogy az adott fájl melyik szervezet rendszeréről származik. A döntés a CI runner környezetben talált azonosítási jelekre épül, elsősorban a host-azonosságra és a valódi committer domainekre. A szervezet saját domainjének is meg kell jelennie ahhoz, hogy a találat megkapja a legmagasabb minősítést.

A tároló-nevek alapján csak közepes bizalmi szint adható. Az érintettek között szerepel többek között az NVIDIA, a Cisco, a Deloitte, a Volkswagen, a FedEx, a Siemens és az X Corp is. Mindez önmagában nem bizonyítja, hogy a megszerzett hitelesítő adatokat fel is használták, ezért a CloudSEK és a LiteLLM is azt tanácsolja az érintetteknek, hogy forgassák meg a kulcsokat, ne pedig a bizonyítékokra várjanak.

A LiteLLM egy nyílt forráskódú AI gateway, amely alkalmazásokat köt össze több modell-szolgáltatóval. A projekt az 1.82.7 és 1.82.8 verziókat azonosította kompromittáltként, és azt közölte, hogy ezek március 24-én 10:39 UTC-től körülbelül 40 percig voltak elérhetők, mielőtt a PyPI karanténba tette őket. A felhasználóknak ugyanakkor azt javasolják, hogy aznap 16:00 UTC-ig minden telepítést tekintsenek gyanúsnak.

A The Hacker News augusztus 12-én a PyPI-n ellenőrizte, hogy egyik verzió sem szerepel már a csomag kiadástörténetében, miközben az 1.82.6 és az 1.83.0 továbbra is elérhető.

Az FBI július 2-án kiadott FLASH-20260702-01 jelzésű figyelmeztetése szerint a kapcsolódó szereplők várhatóan jóval az első kompromittálás után is fel fogják használni a TeamPCP-kampány során kiszivárgott hitelesítő adatokat. A szervezeteknek azt javasolták, hogy forgassák meg a CI/CD titkokat, a publikálási tokeneket és a releváns időablakban elérhető felhőhitelesítő adatokat.

Ha egy hosszú élettartamú titkot – például statikus felhőkulcsot, SSH-kulcsot vagy publikálási tokent – ebben az időablakban lemásoltak, az mindaddig használható marad, amíg nem forgatták meg vagy nem vonták vissza. Ezért az FBI útmutatása a hitelesítő adatokra fókuszál, nem magára a csomagra, és ezért javasolja az FBI és az Aqua is, hogy a csapatok térjenek át a hosszú élettartamú tokenekről az ideiglenesekre.

Az 1.82.8-as verzió tartalmazott egy litellm_init.pth nevű fájlt, amelyet a Python az interpreter indulásakor feldolgoz, így a kód minden Python folyamat indulásakor lefutott az adott környezetben, függetlenül attól, hogy bármi importálta-e a LiteLLM-et.

A kompromittált csomagokat úgy tervezték, hogy begyűjtsék a környezeti változókat, az SSH-kulcsokat, a felhőhitelesítő adatokat, a Kubernetes-tokeneket és az adatbázis-jelszavakat, majd a lopott adatokat titkosítás után a models.litellm[.]cloud címre küldjék. Ez egy támadók által kontrollált domain, amelynek semmi köze a projekthez.

A Unit 42 kampány-elemzése szerint a payload olyan környezeti változókat olvasott ki, amelyek modell API-kulcsokat tartalmaznak, köztük az OPENAI_API_KEY és ANTHROPIC_API_KEY változókat.

Ez a viselkedés megfordítja a szokásos triázskérdést. Kevésbé számít, hogy egy csapat tudatosan használja-e a LiteLLM-et, mint az, hogy a hoston bármi telepítette-e. A projekt figyelmeztetése kiemeli, hogy egy rögzítetlen, tranzitív függőség – például egy agent framework vagy egy orchestration eszköz által behúzva – úgy is telepíthette, hogy senki nem választotta ki tudatosan.

A LiteLLM-incidens a TeamPCP ellátási lánc elleni kampány része, amelyet az Aqua Security Trivy szkenneréhez kötnek. A Google a TeamPCP-t UNC6780 néven követi. Az Aqua közlése szerint a támadók a hiányos hitelesítő-adat-rotáció után is hozzáférést tartottak fenn, és március 19-én erőből felülírták 77-ből 76 trivy-action verziótag rosszindulatú commitjaival, valamint mind a hét setup-trivy taget, miközben kiadták a rosszindulatú Trivy 0.69.4 kiadást.

Az ökoszisztéma-kompromittálást CVE-2026-33634 azonosítóval követik, amelyet március 26-án vettek fel a CISA ismert, aktívan kihasznált sebezhetőségeket tartalmazó katalógusába. A The Hacker News augusztus 12-én megerősítette, hogy a CVE-rekord már a BerriAI LiteLLM 1.82.7–1.82.8 verzióit is érintettként sorolja fel a Trivy-komponensek mellett.

Az, hogy a rosszindulatú LiteLLM-kiadások pontosan hogyan kerültek fel a PyPI-ra, a nyilvános beszámolókban eltérően jelent meg. A CloudSEK jelentése szerint a mérgezett build állította elő és publikálta a kiadásokat, a LiteLLM saját incidensjelentése egy közvetlen PyPI-feltöltésre mutat, amely megkerülte a hivatalos CI/CD workflow-t, míg a Unit 42 arról írt, hogy a támadók a Trivy-breachen keresztül megszerzett PyPI publikálási tokeneket vették célba.

Amikor rákérdeztek az ellentmondásra, a CloudSEK vitatta, hogy ez valódi ellentmondás lenne. „Ezek ugyanannak a támadási láncnak a különböző szakaszai, nem egymásnak ellentmondó magyarázatok” – közölte a cég a The Hacker News-szal. A CloudSEK bizonyítékai azt fedik le, hogyan szerezték meg a hitelesítő adatot, míg a LiteLLM és a Unit 42 megállapításai azt, hogyan használták fel utána.

A rosszindulatú kiadásokra vonatkozó PyPA-figyelmeztetés ugyanilyen sorrendet ír le: egy, a kompromittált Trivy-függőségen keresztül kiszivárgott API-token segítségével töltötték fel a két verziót. A cikk írásakor a BerriAI még nem válaszolt arra, hogy saját forenzikus vizsgálata melyik forgatókönyvet támasztja alá.

A CloudSEK szerint az adathalmazon belüli hozzárendelés két független ellenőrzésen fut át. Egy index a CI-azonossági változók alapján rendel minden fájlt egy szervezethez, egy külön tulajdonosi ellenőrzés pedig a letöltött logokból újraszámolja a tulajdonost, és felülírhatja az első hozzárendelést. „Ha a kettő nem egyezik, a jelentést visszatartjuk” – mondta a cég, és a végső minősítés mindig a két bizalmi szint közül az alacsonyabbat veszi figyelembe.

A 434 000-es szám a begyűjtött fájlokat és exfiltrációs eseményeket jelenti, nem pedig különálló pipeline-okat, futásokat vagy jobokat. A CloudSEK szerint egy begyűjtött fájl nagyjából egy job futásának felel meg, de amíg nincs független deduplikáció és ellenőrzés, ezt nem tekintik egyedi jobok számának.

A cég nem kívánta kommentálni, hogy a közzététel előtt értesítette-e a név szerint szereplő szervezeteket, és azt sem árulta el, hogy bárki vitatta-e a listára kerülését.

A kampány lefelé gyűrűző hatása akkor is bizonyított, ha a CloudSEK által becsült lépték nem. A Checkmarx szerint a Trivy-támadáson keresztül megszerzett hitelesítő adatok jogosulatlan hozzáférést tettek lehetővé a GitHub tárolóihoz, és rosszindulatú artifactok publikálását. A Mercor közölte, hogy érintette a rosszindulatú LiteLLM-verziók ügye, de sikerült megfékeznie a jogosulatlan aktivitást.

A CERT-EU külön értékelésben, magas bizalmi szinttel állapította meg, hogy az Európai Bizottság egyik AWS-fiókja a Trivy ellátási lánc elleni támadása révén kompromittálódott, és nagyjából 91,7 GB tömörített adatot szivárogtattak ki.

Azoknak a szervezeteknek, amelyek a saját kitettségüket vizsgálják, három lépést érdemes megtenniük:

• Ellenőrizzék, hogy március 24-én, a LiteLLM által megadott 10:39–16:00 UTC auditablakban futott-e LiteLLM 1.82.7 vagy 1.82.8 telepítés.
• Forgassák meg minden olyan rendszer titkait, amelyeket ezek a rendszerek elérhettek.
• Keressenek a GitHub szervezetükben tpcp-docs vagy docs-tpcp nevű tárolókat, amelyeket az FBI a kampány indikátorai között sorol fel. Az Aqua figyelmeztetése a CVE-hez hozzáteszi, hogy a malware tpcp-docs- előtaggal hozta létre ezeket, és a lopott adatokat data-<timestamp> taggel ellátott release assetként töltötte fel, így a pontos névre keresés könnyen elnézheti őket.