Il 23 ottobre LiteLLM ha corretto la ricostruzione dell’attacco alla propria supply chain: il primo token GitHub del proprietario dell’organizzazione era stato ottenuto tramite Agent Platform, usando una chiave master pubblicata in un repository pubblico il 27 maggio e mai revocata. L’attacco del 21 ottobre ha portato alla pubblicazione di artefatti malevoli della versione 1.107.0 su PyPI e nei registri di container.
La chiave master ha aperto la strada ai token GitHub
Secondo la ricostruzione di LiteLLM, il 10 ottobre l’attaccante usò la chiave esposta per accedere all’Agent Platform sperimentale e ottenere un token GitHub CLI OAuth appartenente a un proprietario dell’organizzazione. In seguito, alcuni workflow furono usati per sottrarre i token di due maintainer. L’ipotesi iniziale secondo cui il primo token provenisse dai log di un deployment fu corretta nel rapporto pubblicato il 23 ottobre.
| Data | Evento |
| 27 maggio 2026 | Un file di configurazione contenente la chiave master fu pubblicato in un repository pubblico. LiteLLM afferma che la chiave non venne revocata. |
| 10 ottobre 2026 | L’attaccante usò la chiave per accedere ad Agent Platform e ottenere il token del proprietario; in seguito, alcuni workflow esposero i token di due maintainer. |
| 21 ottobre 2026 | L’attaccante alterò il workflow di rilascio e furono pubblicati gli artefatti compromessi della versione 1.107.0. |
| 23 ottobre 2026 | LiteLLM pubblicò la ricostruzione della catena di attacco, correggendo l’ipotesi iniziale sui log. |
Per indirizzare il rilascio, l’attaccante usò il repository sorgente simile Berri-AI/litellm, distinto dal legittimo BerriAI/litellm. Questo non era il nome di un diverso registro di immagini: LiteLLM indicò come coinvolti i tag delle immagini distribuite tramite Docker Hub e GHCR, compreso ghcr.io/berriai/litellm.
Versione PyPI, tag dei container e orari
LiteLLM identificò tutti e sette i wheel PyPI di litellm==1.107.0 come compromessi. I file furono caricati il 21 ottobre tra le 11:39:51 e le 11:40:13 UTC; PyPI mise il pacchetto in quarantena entro le 13:23 UTC.
Su Docker Hub e GHCR i tag coinvolti erano v1.107.0, latest, main-latest e main-stable. Le immagini compromesse furono pubblicate alle 11:46:56 UTC. LiteLLM riferì che i tag interessati su GHCR non erano disponibili entro le 13:51 UTC e che quelli su Docker Hub furono rimossi o reindirizzati verso immagini pulite entro le 14:20 UTC.
Chi amministra ambienti LiteLLM può confrontare i registri di installazione e di pull con quei nomi e quegli orari. La verifica riguarda sia i pacchetti PyPI sia le immagini dei container; controllare soltanto la versione attualmente installata non ricostruisce da solo che cosa sia stato scaricato o avviato durante la finestra indicata. LiteLLM dichiarò che il proprio registro enterprise privato non era stato coinvolto.
I file di avvio e i dati presi di mira
Wiz ha descritto tre file inseriti nella directory Python site-packages: cook.pth, cook.py e sitecustomize.py. Questi file erano progettati per attivarsi all’avvio di Python. L’analisi di Wiz descrive un loader remoto destinato a Linux e macOS e un malware che cercava credenziali del browser, chiavi di servizi cloud e di fornitori di AI, chiavi SSH e GPG, cronologia della shell e credenziali conservate nel database del proxy LiteLLM.
Wiz ha stimato circa 49.000 download della versione 1.107.0 sulla base dei dati di ClickPy. Si tratta di una stima dei download del pacchetto. Tra le 16:20 e le 17:01 UTC del 21 ottobre, Wiz ha inoltre osservato controlli delle credenziali AWS, comprese chiamate sts:GetCallerIdentity e richieste per elencare modelli su Amazon Bedrock.
Le indicazioni di LiteLLM per gli ambienti coinvolti
LiteLLM consigliò di fissare la versione 1.106.2 o un’altra release esplicitamente precedente all’attacco. Per gli ambienti interessati, le indicazioni dell’azienda comprendevano la rimozione dei file malevoli, la ricostruzione degli ambienti dove opportuno e la rotazione dei segreti accessibili dai sistemi coinvolti.
