LiteLLM 1.107.0 compromessa: infostealer e RAT da PyPI e Docker

Il 21 ottobre 2026 la pipeline di rilascio di LiteLLM, il gateway open source di BerriAI che offre un’interfaccia unica verso OpenAI, Anthropic, Google Gemini e altri fornitori di modelli, ha pubblicato una versione malevola: la 1.107.0, su PyPI, Docker Hub e GHCR. Conteneva un infostealer per credenziali cloud, di sviluppo e di servizi IA, più un trojan ad accesso remoto (RAT). È il secondo attacco alla catena di fornitura del progetto quest’anno, dopo quello di marzo legato allo scanner Trivy usato nella sua CI/CD.

Cosa è successo

Secondo il rapporto di LiteLLM, l’attaccante ha usato i token OAuth della GitHub CLI di tre sviluppatori: un account ha modificato la pipeline e avviato il rilascio, un secondo lo ha approvato, un terzo ha cancellato i registri del workflow. Secondo SecurityWeek ha anche disattivato le protezioni dei branch e fatto puntare il rilascio al repository Berri-AI/litellm, a un trattino da quello legittimo BerriAI/litellm. Il workflow ha poi firmato e pubblicato gli artefatti avvelenati: le immagini firmate introdotte dopo marzo non sono bastate.

L’azienda ritiene che i token siano stati presi dai log di una sua installazione interna di LiteLLM esposta su internet, in cui è comparso un account utente inatteso dal nome innocuo. Ha osservato casi specifici in cui Claude Code inserisce il token della GitHub CLI nel corpo di una risposta: se i corpi delle risposte vengono registrati, il token finisce nei log. Come l’attaccante sia entrato non è confermato; LiteLLM sospetta una vulnerabilità corretta di recente. Un articolo di The Hacker News del 24 ottobre indica nel titolo una master key di LiteLLM trapelata: non abbiamo potuto leggerne il testo.

Finestre di esposizione dal rapporto, riportate da BleepingComputer:

• PyPI: litellm==1.107.0, tutte e sette le wheel per Windows, Linux e macOS, dalle 11:39 alle 13:23 UTC;
• Docker Hub: tag v1.107.0, latest, main-latest e main-stable dalle 11:46 alle 14:20 UTC, verso l’indice sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e;
• GHCR: stessi tag fino alle 13:51 UTC, anche per le varianti litellm-database e litellm-non_root.

SecurityWeek, unica tra le fonti, stima oltre 49.000 download. L’ultima versione pulita è la 1.106.2; i clienti del registro privato enterprise non sono coinvolti.

Dettagli tecnici

Il codice dell’applicazione non è stato toccato: il pacchetto aggiungeva tre file nella radice di site-packages.

• cook.pth: le righe eseguibili dei file .pth vengono elaborate a ogni avvio dell’interprete, e questa avvia cook.py, l’infostealer;
• sitecustomize.py: importato anch’esso all’avvio, lancia un loader separato che ogni ora legge un puntatore ospitato su GitHub (dead drop), poi scarica ed esegue codice Python.

Il malware parte quindi a ogni avvio di Python nell’ambiente, anche se l’applicazione non usa LiteLLM, e anche lanciando python o pip per indagare.

Secondo Wiz l’infostealer ha 16 moduli. Raccoglie credenziali AWS (~/.aws/, variabili d’ambiente, metadati EC2/ECS), Google Cloud, Azure, Kubernetes e Docker; segreti di Git, GitHub, npm, PyPI e CI/CD, file .env, chiavi SSH e GPG, cronologia della shell; chiavi API di OpenAI, Anthropic e altri fornitori, file di autenticazione di Codex, Claude, Gemini e Cursor; password, cookie e cronologia dei browser. Cerca anche le credenziali dei fornitori salvate nel database del proxy LiteLLM: secondo i ricercatori è un’intenzione, non una riuscita dimostrata. I dati, cifrati con AES-256-CBC e chiave protetta da RSA-4096, partono con una POST HTTP verso www.litellm[.]dev/healthcheck.

Indicatori pubblici: secondo Aikido, /tmp/.pc_once_* (l’esfiltrazione è avvenuta) e /tmp/remote_code_loader.lock (il loader è partito o è attivo); poi il dominio litellm[.]dev, il repository Berri-AI/litellm e il digest dell’immagine indicato prima.

Uso delle credenziali: Wiz ha visto l’attaccante, circa 4 ore e mezza dopo l’esfiltrazione, verificare chiavi AWS prese da runner CI e nodi Kubernetes e provare l’accesso ai modelli di Amazon Bedrock (LLMjacking); in pochi ambienti ha poi elencato ruoli, utenti e chiavi IAM.

Nella nostra lettura le tecniche MITRE ATT&CK pertinenti sono T1195.002 (Compromise Software Supply Chain), T1546.018 (Python Startup Hooks), T1552 (Unsecured Credentials) e T1102.001 (Dead Drop Resolver).

Impatto per le aziende europee e italiane

Un gateway IA concentra le chiavi di più fornitori e spesso gira con identità cloud e accessi a database: il danno può andare ben oltre le chiavi API. Sono esposti anche postazioni di sviluppo e runner CI che hanno installato la libreria come dipendenza. Due lezioni generali: una firma valida dice che l’artefatto non è cambiato dopo la firma, non che fosse sicuro; e i log di un gateway IA possono raccogliere segreti.

Per i soggetti NIS2 la sicurezza della catena di fornitura è una misura obbligatoria: l’esecuzione della 1.107.0 su sistemi con accesso all’infrastruttura va valutata come possibile incidente da notificare, in base agli accessi ottenuti. Se il database del proxy conservava log con dati personali, va valutata anche la notifica prevista dal GDPR.

Cosa fare subito

1. Individua ambienti, postazioni e runner con la 1.107.0 e le immagini scaricate nella finestra con i tag latest, main-latest o main-stable: lockfile, registri dei pacchetti, digest.
2. Non avviare Python né pip sui sistemi sospetti: cerca dall’esterno cook.pth, cook.py, sitecustomize.py e i file in /tmp, e nei log di rete il dominio litellm[.]dev. L’assenza di indicatori non prova che l’ambiente sia pulito.
3. Isola e ricostruisci da immagini fidate, conservando le prove: togliere solo il pacchetto può lasciare attivi i file di avvio e il loader. Fissa la 1.106.2 per hash o digest, non per tag.
4. Ruota tutti i segreti raggiungibili: cloud, fornitori di IA (anche quelli salvati nel proxy), Kubernetes, CI/CD, Git e registri, chiavi SSH; chiudi le sessioni dei browser delle postazioni colpite.
5. Cerca l’uso delle credenziali dal 21 ottobre: chiamate a Bedrock, enumerazione IAM, nuove chiavi, consumi anomali dei token dei modelli.
6. Rafforza la pipeline: approvazione indipendente delle modifiche ai workflow di rilascio, niente corpi delle risposte nei log del gateway, interfacce di gestione non esposte su internet.

Come aiuta ARXDOME

ARX Sentry raccoglie con il suo agent l’inventario di software e processi di computer e server Windows, Linux e macOS e controlla l’integrità dei file nelle cartelle stabilite: aiuta a trovare le macchine su cui gira LiteLLM e a notare file nuovi dove non dovrebbero esserci. Se una macchina è sospetta, ARX Shield permette di isolarla dalla rete in attesa della ricostruzione.

Ultimo aggiornamento: 24 ottobre 2026