Se la vostra azienda ha un'applicazione di IA, un chatbot o uno strumento interno che si collega a modelli come GPT, Claude o Gemini, fate oggi una sola domanda al vostro team tecnico: qualche server, portatile o pipeline di build ha installato LiteLLM nella versione 1.107.0 il 21 ottobre 2026? Quella versione è stata pubblicata da attaccanti ed è rimasta su PyPI per circa due ore, tra le 14:39 e le 16:23 ora di Riad, con circa 49.000 download. Ruba chiavi cloud, chiavi dei fornitori di IA, password di database e chiavi SSH. Se la risposta è sì, disinstallarla non basta: ricostruite la macchina da un'immagine pulita e cambiate ogni chiave a cui poteva accedere. La versione sicura è la 1.106.2.

Che cosa è successo esattamente?

LiteLLM è una libreria e un gateway open source che permette a una sola applicazione di dialogare con decine di modelli di IA attraverso un'unica interfaccia, ed è per questo che molte aziende la mettono al centro dei loro prodotti di IA. Secondo Chainguard, ha superato i 100 milioni di download su PyPI nell'ultimo mese, e più di 2.000 altri pacchetti dipendono da essa, quindi molti team la installano senza saperlo.

Secondo il rapporto ufficiale sull'incidente di LiteLLM, gli attaccanti hanno ottenuto token di accesso GitHub finiti nei log del progetto. Alle 10:08 UTC del 21 ottobre hanno usato una credenziale privilegiata di sviluppatore per aggirare la protezione del branch e modificare il flusso di pubblicazione in modo che compilasse da un repository dal nome simile, «Berri-AI/litellm» invece di «BerriAI/litellm». Alle 11:39 UTC i file malevoli sono arrivati su PyPI, e alle 11:46 UTC sono uscite immagini Docker contaminate con i tag v1.107.0, latest, main-latest e main-stable. PyPI ha rimosso la versione entro le 13:23 UTC, e i tag Docker sono stati ripuliti alle 14:20 UTC, cioè alle 17:20 a Riad.

È il secondo attacco allo stesso progetto quest'anno. Chainguard ricorda che a marzo 2026 un gruppo aveva usato un token PyPI rubato per pubblicare le versioni 1.82.7 e 1.82.8.

Che cosa ruba la versione malevola?

Il pericolo è che non aspetta che la vostra applicazione usi LiteLLM. La versione aggiungeva file di avvio di Python che si eseguono ogni volta che Python parte su quella macchina, anche per un comando che non c'entra nulla. Secondo l'analisi di Wiz, il ladro raccoglieva:

  • Chiavi cloud di AWS, Google Cloud e Azure, da file di configurazione, variabili d'ambiente e metadati del server.
  • Chiavi API di OpenAI, Anthropic, Cohere e altri fornitori di IA, cioè la vostra fattura e i vostri dati.
  • Chiavi SSH private, cronologia della shell e password e cookie salvati nei browser.
  • Fino a 500 credenziali di fornitori conservate nel database di LiteLLM Proxy.

Gli attaccanti non sono rimasti fermi. Wiz ha visto credenziali AWS rubate messe alla prova circa 4,5 ore dopo il furto, da server di build e nodi Kubernetes. Il malware installava anche una seconda fase che scarica codice remoto ogni ora, così la macchina resta aperta anche dopo la rimozione del pacchetto.

La mia azienda è coinvolta?

Probabilmente no, se il vostro team blocca versioni esatte e non ha aggiornato nulla tra le 14:39 e le 17:20 ora di Riad del 21 ottobre. Potreste esserlo se vale uno di questi casi:

  • Un server o un container esegue «pip install litellm» senza versione fissa, oppure scarica il tag Docker «latest».
  • Una pipeline CI/CD ha ricompilato quel pomeriggio.
  • Uno sviluppatore ha provato LiteLLM sul suo portatile quel giorno.
  • Il vostro sistema usa un altro pacchetto che dipende da LiteLLM.

LiteLLM afferma che i clienti della sua versione Enterprise privata non sono stati colpiti.

Cinque passi da fare oggi

  • Cercare: la versione 1.107.0 nei file di lock, nei log di build e nelle immagini dei container, e i file cook.pth e sitecustomize.py nella cartella dei pacchetti Python.
  • Ricostruire: se la trovate, non limitatevi a disinstallare. Il rapporto ufficiale avverte che eseguire pip in un ambiente infetto può riattivare il malware. Ricostruite la macchina o il container da un'immagine pulita.
  • Cambiare tutte le chiavi: chiavi e ruoli cloud, chiavi dei fornitori di IA, password dei database e chiavi SSH raggiungibili dalla macchina. Date per scontato che siano già nelle mani degli attaccanti.
  • Esaminare i log: controllate l'attività cloud dal 21 ottobre in cerca di chiamate insolite come GetCallerIdentity, e tenete d'occhio la fattura del vostro fornitore di IA per spese che non riconoscete.
  • Bloccare le versioni: installate litellm==1.106.2 o una correzione ufficiale successiva, e bloccate ogni libreria con un file di lock invece di scaricare «latest» in automatico.

Se avete letto il nostro articolo precedente sulle chiavi dimenticate nel codice degli agenti IA, la lezione è la stessa da un'altra angolazione: le chiavi di IA sono ormai tra i segreti più preziosi della vostra azienda, e il luogo in cui si concentrano diventa un bersaglio.

Il punto di vista di Origami

Qui nessuno ha hackerato il codice di LiteLLM in sé. Gli attaccanti hanno cambiato il modo in cui viene compilato e pubblicato, quindi la sola revisione del codice sorgente non avrebbe scoperto nulla. Per questo proteggere i prodotti di IA dipende meno dalla scelta della libreria e più da come la si gestisce: versioni fisse, una chiave distinta per ogni ambiente con solo i permessi necessari, limiti di spesa presso ogni fornitore di IA e un registro chiaro di chi accede a cosa. Quando in Origami costruiamo sistemi di IA per le aziende, trattiamo il gateway dei modelli come la parte più sensibile del sistema, perché custodisce le chiavi di tutto. Se volete far controllare la vostra applicazione di IA rispetto a questo incidente, o riorganizzarne chiavi e permessi, contattateci.

Fonti