TL;DR: le versioni LiteLLM 1.82.7 e 1.82.8 pubblicate su PyPI il 24 marzo 2026 contenevano codice malevolo capace di raccogliere credenziali. Se una delle due versioni è entrata in un portatile, una pipeline CI/CD o un server, aggiornare il pacchetto non basta: bisogna ricostruire l’esposizione, isolare il sistema, ruotare i segreti raggiungibili e verificare gli accessi successivi. Per una PMI, la difesa più efficace è ridurre in anticipo i segreti persistenti disponibili a ogni build.

Un attacco alla supply chain software non deve violare direttamente il tuo sito WordPress o il tuo cloud. Gli basta entrare in un componente che consideri affidabile. Nel caso LiteLLM, due release malevole sono finite sul canale ufficiale PyPI e sono rimaste disponibili per circa 40 minuti. Una finestra breve, ma sufficiente per raggiungere installazioni automatiche, build e dipendenze transitive.

Il punto operativo non è stabilire se il numero finale delle vittime sarà 2.500, 25.000 o più. Queste stime vanno ancora lette con cautela. Il punto è un altro: una singola dipendenza eseguita vicino alle chiavi dei modelli AI, al repository e all’infrastruttura può trasformare un aggiornamento ordinario in un incidente su più sistemi.

Cosa è successo a LiteLLM

LiteLLM ha confermato che le versioni 1.82.7 e 1.82.8 pubblicate su PyPI erano compromesse. Furono disponibili il 24 marzo 2026 dalle 10:39 UTC per circa 40 minuti, prima della quarantena da parte di PyPI. Il progetto collega l’origine dell’incidente alla compromissione di Trivy, usato nel workflow di sicurezza CI/CD.

La catena è importante. Trivy è uno scanner di vulnerabilità: uno strumento a cui una pipeline concede accesso proprio perché deve leggere immagini, dipendenze e configurazioni. L’advisory GitHub sul caso Trivy descrive un attacco che ha sottratto credenziali e alterato release, tag e immagini. Quelle credenziali hanno poi aperto una strada verso altri progetti.

Le due versioni LiteLLM non si comportavano allo stesso modo:

  • 1.82.7 conteneva il payload nel file proxy_server.py;
  • 1.82.8 aggiungeva anche litellm_init.pth, un file elaborato automaticamente all’avvio dell’interprete Python.

La seconda variante è la più insidiosa. Non era necessario avviare esplicitamente il proxy LiteLLM: l’esecuzione poteva partire con un normale processo Python nell’ambiente interessato. Il codice cercava variabili d’ambiente, chiavi SSH, credenziali cloud, token Kubernetes e password di database, poi tentava di inviarli a un dominio non appartenente al progetto.

Ad agosto, CloudSEK ha stimato una possibile esposizione di oltre 2.500 organizzazioni e 434.000 pipeline CI/CD. Sono numeri forniti dalla società di sicurezza sulla base dei dati analizzati, non un censimento indipendente di compromissioni riuscite. Non vanno trasformati in certezze. La conferma tecnica delle versioni, della finestra e delle classi di segreti raccolte arriva invece dal progetto LiteLLM e dagli advisory pubblici.

Perché una pipeline AI concentra troppo potere

Un’applicazione web tradizionale può avere accesso al database e a pochi servizi. Una pipeline AI moderna spesso vede molto di più: chiavi OpenAI o Anthropic, storage, repository GitHub, registry Docker, account cloud, strumenti MCP, code di messaggi e database applicativi. Se il team usa WordPress come front-end, può esserci anche una Application Password o una chiave per distribuire contenuti e media.

Questa concentrazione nasce per comodità. Una sola build deve testare, creare l’immagine, distribuire il servizio e verificare l’ambiente. Il risultato è che il runner diventa un punto di passaggio per credenziali appartenenti a sistemi diversi. Il malware non deve conoscere in anticipo l’architettura: legge ciò che trova e lascia che siano i token a descrivere il perimetro.

La mia take è netta: il problema non è “usare AI”. È trattare il processo che usa l’AI come se fosse una normale dipendenza applicativa, mentre in realtà opera come un account privilegiato di automazione. Se può leggere produzione, pubblicare pacchetti e aggiornare WordPress, va progettato e monitorato come un’identità di servizio critica.

Prima verifica: capire se sei stato esposto

Non partire dalla rotazione indiscriminata di tutto. Prima costruisci una lista dei sistemi che possono aver installato LiteLLM nella finestra interessata. Cerca nei lockfile, nei log di build, nella cache dei package, nelle immagini container e negli ambienti virtuali conservati.

Il controllo minimo su un ambiente ancora disponibile è:

python -m pip show litellm
python -c "import site; print('\n'.join(site.getsitepackages()))"
find /percorso/site-packages -name 'litellm_init.pth' -print

La versione installata oggi non dimostra quale versione fosse presente il 24 marzo. Un aggiornamento successivo può aver cancellato l’evidenza più visibile. Per questo servono anche cronologia delle build, digest delle immagini, cache del registry e log del gestore di pacchetti.

Considera potenzialmente esposto un sistema se ricorre almeno una di queste condizioni:

  • ha installato litellm==1.82.7 o litellm==1.82.8 da PyPI;
  • ha eseguito un’installazione non pinning durante la finestra indicata;
  • ha costruito un’immagine con pip install litellm senza versione bloccata;
  • ha ricevuto LiteLLM come dipendenza transitiva non bloccata;
  • contiene litellm_init.pth o connessioni verso models.litellm.cloud.

Secondo LiteLLM, il servizio cloud, il repository sorgente e l’immagine Docker ufficiale ghcr.io/berriai/litellm non furono colpiti da queste due release PyPI. L’immagine ufficiale usava dipendenze fissate. È un buon esempio di come il percorso di distribuzione cambi il rischio, anche quando il nome del prodotto è lo stesso.

Contenimento: non distruggere subito le prove

Se trovi un indicatore, scollega il sistema dai percorsi sensibili e impedisci nuove esecuzioni. Evita però una pulizia affrettata. Cancellare l’ambiente virtuale o ricostruire immediatamente il server può rimuovere file, timestamp e log utili a capire quali credenziali erano raggiungibili.

Per una piccola azienda senza un team forense interno, la sequenza ragionevole è questa:

  1. isolare il runner, il server o il portatile dalla rete e bloccare i job collegati;
  2. salvare inventario dei processi, connessioni, pacchetti, file sospetti e log;
  3. revocare dai sistemi puliti le credenziali con maggiore impatto;
  4. ricostruire l’host da una base verificata, invece di fidarsi della sola disinstallazione;
  5. monitorare gli accessi effettuati con le vecchie credenziali.

La distinzione tra “rimuovere il malware” e “chiudere l’incidente” è decisiva. Una chiave già copiata resta valida anche dopo aver cancellato il pacchetto. Se quella chiave permette di creare un nuovo token o aggiungere un utente, ruotare solo la chiave iniziale potrebbe non rimuovere la persistenza.

Ruotare i segreti in un ordine utile

La rotazione deve seguire il potere delle credenziali e le loro dipendenze, non l’ordine alfabetico dei servizi. Inizia dalle identità capaci di generare altre identità o cambiare autorizzazioni:

  1. account cloud, ruoli IAM e token del sistema CI/CD;
  2. token GitHub/GitLab con permessi di scrittura e credenziali dei registry;
  3. chiavi Kubernetes, secret manager e accessi ai database di produzione;
  4. chiavi dei provider AI e strumenti collegati, inclusi MCP server;
  5. credenziali applicative, WordPress e servizi di invio.

Revoca prima, genera dopo. Se crei una nuova chiave mentre il runner compromesso è ancora attivo, il malware può raccogliere anche quella. Esegui la rotazione da un dispositivo pulito, limita temporaneamente i privilegi e verifica nei log chi ha usato i vecchi token dopo il 24 marzo.

Per WordPress controlla Application Password, utenti amministratori, plugin installati e modifiche ai file. Una chiave WordPress non concede automaticamente accesso al cloud, ma può permettere pubblicazione, upload di media o modifica dei contenuti. Se l’automazione collega WordPress a Meta, email o CRM, verifica ogni connettore separatamente.

Come ridurre il prossimo blast radius

Il pinning esatto è utile, ma non basta. Bloccare una versione malevola la rende riproducibile: evita aggiornamenti inattesi, non certifica che l’artefatto sia sano. Serve un insieme di controlli che spezzi la catena in più punti.

Usa credenziali brevi e legate al job

Dove possibile, sostituisci token persistenti con identità federate OIDC e credenziali emesse per una singola esecuzione. Se una build legge un token valido per mesi, un furto di pochi secondi crea un problema di mesi. Una credenziale con vita di minuti riduce il tempo utile per l’attaccante.

Separa build, test e deploy

Il job che installa dipendenze non dovrebbe avere anche i permessi per pubblicare in produzione. Fai produrre un artefatto al job di build, validalo in un ambiente senza segreti di deploy e usa un secondo job, con dipendenze minime, per la distribuzione. Nel blog applico lo stesso principio con un confine di fiducia esplicito per la supply chain AI: leggere e preparare non equivale ad avere autorità di pubblicare.

Verifica artefatto e provenienza

Conserva lockfile, hash e digest delle immagini. Per GitHub Actions, preferisci commit SHA completi ai tag modificabili. Per container e release firmate, verifica firma e provenienza prima del deploy. Confronta inoltre la release del registry con il repository: nel caso LiteLLM, le versioni malevole furono pubblicate su PyPI senza passare dalla release GitHub prevista.

Controlla l’uscita di rete

Molti runner possono contattare qualsiasi dominio. È comodo, ma rende invisibile la differenza tra scaricare una dipendenza e inviare un archivio di segreti. Registra le destinazioni e, per i job sensibili, usa una allowlist. Un nuovo dominio contattato durante una build deve generare almeno un alert.

Un piano da applicare questa settimana

Una PMI non deve costruire un SOC per migliorare molto la propria posizione. Può iniziare con un inventario piccolo e verificabile:

  • elenca pipeline, runner e automazioni che possono leggere segreti;
  • associa a ciascuna identità proprietario, scopo, durata e procedura di revoca;
  • blocca le dipendenze dirette e conserva gli artefatti delle build;
  • separa installazione delle dipendenze e deploy;
  • attiva log di audit su cloud, repository, registry, WordPress e provider AI;
  • prova una rotazione completa su una credenziale non critica.

La metrica utile non è il numero di scanner installati. È il tempo necessario per rispondere a tre domande: quale versione è stata eseguita, quali segreti poteva leggere e quanto serve per revocarli. Se non riesci a rispondere in un’ora, la priorità è migliorare inventario e separazione dei privilegi, non aggiungere un altro tool.

La lezione per chi adotta AI

LiteLLM è un caso di sicurezza della supply chain, non una prova che l’AI sia intrinsecamente insicura. Mostra però un rischio specifico dello stack AI: molti strumenti nascono come librerie per sviluppatori e finiscono presto in ambienti con accesso a modelli, dati e infrastruttura.

Tratta ogni gateway, agente e orchestratore come codice con capacità operative. Dagli solo i segreti necessari, per il tempo necessario. Se una dipendenza viene compromessa, il danno non dovrebbe dipendere dalla buona sorte o dalla brevità della finestra su PyPI.

Fonti