Il 21 ottobre, la versione 1.107.0 di LiteLLM (una libreria che funge da gateway per i modelli, posizionata a monte delle chiavi API di OpenAI, Anthropic e decine di altri provider) è apparsa su PyPI nascondendo una backdoor. File wheel malevoli e un hook di avvio di Docker raccoglievano variabili d'ambiente e credenziali per poi trasmetterle all'esterno. L'esposizione totale è durata circa 100 minuti. Il punto di accesso era rimasto latente fin da maggio, quando un token di accesso principale, trapelato in un repository pubblico su GitHub, aveva smesso silenziosamente di funzionare per il manutentore originale, passando di fatto nelle mani di qualcun altro. Se un team di sviluppo ha scaricato il pacchetto in quella precisa finestra temporale, chi ha sferrato l'attacco si è ritrovato con un mazzo di chiavi in grado di sbloccare i provider dei modelli, i database e, spesso, qualsiasi risorsa accessibile tramite quelle variabili d'ambiente. Un altro capitolo della supply chain AI sotto attacco.
100Minuti di permanenza della backdoor su PyPI 6 mesiDalla fuga del token all'uso come arma 3Campagne contro la supply chain dell'IA in ottobre
Non un incidente. Uno schema ricorrente.
La backdoor di LiteLLM ha conquistato i titoli dei giornali perché ha colpito le fondamenta stesse dell'ecosistema dell'intelligenza artificiale. Tuttavia, è sufficiente osservare ciò che è accaduto nel resto del mese. All'inizio di ottobre, il worm npm Shai-Hulud (una campagna autoreplicante che da settembre imperversa nell'ecosistema JavaScript) è riemerso in alcuni pacchetti di Tensorlake. I ricercatori hanno notato che l'ultima variante conteneva un interruttore distruttivo: una logica in grado di cancellare i file al verificarsi di determinate condizioni. Parallelamente, una campagna nota come GhostAction ha iniziato a iniettare flussi di lavoro malevoli tramite GitHub Actions all'interno di repository legittimi, esfiltrando in modo invisibile i segreti della Continuous Integration, ovvero le stesse credenziali utilizzate per firmare i rilasci e accedere agli account cloud. Sul fronte degli utenti finali, inoltre, finti programmi di installazione per strumenti di sviluppo (tra cui falsi script di configurazione per Claude Code) hanno rastrellato le credenziali di chi ha digitato un comando curl con troppa leggerezza.
Vettori diversi, ma un unico disegno. Lo stack dell'IA concentra credenziali di straordinaria importanza in luoghi del tutto ordinari: chiavi di gateway che permettono di addebitare costi su qualsiasi provider, variabili d'ambiente che contengono gli URL dei database, segreti di CI con diritti di distribuzione e token con permessi estesi a interi account cloud. La supply chain recapita il codice ostile esattamente in quei punti. E non serve che il codice sia particolarmente sofisticato: gli basta essere eseguito una sola volta, per un minuto, su una macchina che ha già effettuato l'accesso a ogni sistema.
Perché gli stack IA sono peggiori di ciò che li ha preceduti
Qualsiasi gruppo di sviluppo software deve affrontare il problema delle dipendenze; chi lavora con l'IA, però, se ne ritrova altri tre sovrapposti. Il primo è la densità delle credenziali: un gateway per i modelli è, per sua stessa natura, un intermediario di spesa. Comprometterlo non significa soltanto rubare dati, ma ottenere un accesso a consumo ai modelli più avanzati, addebitandolo sulla carta di credito di qualcun altro. È esattamente il meccanismo su cui si basano le campagne di attacco per l'inferenza a noleggio analizzate di recente. Il secondo fattore riguarda gli strumenti, che sono recenti e in rapida evoluzione: nei primi sessanta giorni di quest'anno sono state registrate oltre 30 CVE contro i server MCP, un protocollo che ha mosso i primi passi da pochissimo. Nuovi livelli software vengono rilasciati ogni settimana, mentre la disciplina della revisione del codice scarseggia. Il terzo elemento è il raggio d'azione ereditato: quando un agente opera con accesso in scrittura, una dipendenza corrotta non si limita a sottrarre segreti. Al contrario, agisce con i permessi dell'agente, sfruttandone l'impalcatura per colpire l'infrastruttura reale.
L'aspetto più scomodo riguarda l'economia dell'attacco. La backdoor di LiteLLM non è costata nulla a chi l'ha creata, se non un po' di pazienza: una chiave trapelata a maggio, mesi di attesa silenziosa e, infine, la pubblicazione di una singola release. Difendersi, invece, impone a ogni team a valle una tassa permanente fatta di verifiche, blocco delle versioni e monitoraggio continuo. Questa asimmetria riassume l'intera storia della sicurezza informatica del 2026, e la supply chain è l'ambito in cui tale squilibrio risulta più redditizio per chi attacca.
I programmi di installazione vengono eseguiti con i privilegi dell'utente. L'intero attacco si riduce a questo.
Le soluzioni che richiedono solo un pomeriggio
Nulla di ciò che segue rappresenta una novità nel campo della sicurezza del software. La vera anomalia risiede nel numero esiguo di team IA che ha applicato queste difese alle proprie dipendenze, forse perché lo stack viene percepito come qualcosa di magico, e la magia raramente viene sottoposta a revisione.
Bloccare e verificare le dipendenze Python e npm. È fondamentale inserire versioni esatte con i relativi hash nel file di blocco, imponendone il rispetto durante la Continuous Integration. Quando viene rilasciata la versione 1.107.1 come correzione, l'obiettivo deve essere installare la build che è stata verificata, non ciò a cui punta casualmente un tag in un martedì qualunque.
Trattare le chiavi del gateway dei modelli come i gioielli della corona. Servono chiavi separate per ogni ambiente e per ogni servizio, limiti di spesa per ciascuna di esse, oltre a una rotazione programmata e una rotazione immediata in caso di sospetto. Una chiave di gateway in grado di richiamare tutti i provider a partire da un unico segreto rappresenta un singolo punto di vulnerabilità travestito da bilanciatore di carico.
Controllare il traffico in uscita per le build e gli agenti. Un software che ruba credenziali è efficace solo quanto lo è il suo percorso di rete. Se la CI e gli host degli agenti possono comunicare esclusivamente con una lista consentita di endpoint, la fase di esfiltrazione di tutte le campagne descritte in precedenza fallirà, che lo faccia in modo rumoroso o silenzioso.
Revisionare le modifiche ai flussi di lavoro esattamente come il codice che eseguono. GhostAction ha successo perché una pull request che modifica un file YAML viene spesso scambiata per un'operazione di routine. Un flusso di lavoro di GitHub Actions alterato non è altro che codice arbitrario in esecuzione con i segreti del repository: merita lo stesso livello di attenzione di una modifica al livello di autenticazione.
Mai installare copiando e incollando comandi shell nel terminale. Le campagne basate su finti programmi di installazione funzionano perché eseguire curl | bash bypassa ogni istinto di cautela che si applicherebbe normalmente a una dipendenza. I file di installazione vanno scaricati tramite canali verificati, controllandone i checksum. Qualsiasi strumento che richieda le chiavi API al primo avvio andrebbe trattato con lo stesso sospetto riservato a uno sconosciuto che chiede il portafogli al primo incontro.
Piazzare delle esche dove operano i ladri. Un honeytoken (una finta chiave AWS o un finto URL di database inserito nell'ambiente CI) trasforma un'esfiltrazione silenziosa in un avviso immediato del sistema di monitoraggio, poiché solo un malintenzionato andrebbe mai a toccarlo.
La finestra di vulnerabilità di LiteLLM è durata 100 minuti, e i team che avevano bloccato le versioni tramite hash sono risultati immuni persino in quel frangente. Le altre campagne del mese si sono rivelate più lente e pazienti. Chi attacca la supply chain non ha bisogno di superare le difese avanzate: gli basta superare le impostazioni predefinite. È tempo di stabilire impostazioni predefinite migliori.
Questo discorso si ricollega al resto della mappa sulla sicurezza dell'IA che stiamo delineando: l'avvelenamento degli strumenti come nuova SQL injection, le conseguenze di quando un agente ottiene l'accesso in scrittura, la sandbox che ha fallito silenziosamente e il picco di CVE che rifornisce di vulnerabilità questo ecosistema.