Supply chain software: cosa insegna l’attacco LiteLLM

Alle 10:39 UTC del 24 marzo 2026, qualcuno ha caricato su PyPI una versione di LiteLLM che non avrebbe dovuto esistere. Non c’era nessun tag corrispondente su GitHub, nessun commit nel repository ufficiale, nessuna release note. Solo un pacchetto Python, apparentemente identico a quello che milioni di sviluppatori scaricano ogni giorno, con qualcosa di nascosto dentro.

Nel giro di tredici minuti ne è arrivata un’altra, ancora più sofisticata. Le due versioni malevole sono rimaste disponibili per meno di tre ore. È bastato.

Supply chain software: come nasce un attacco alla fiducia nell’ecosistema open source

LiteLLM non è un pacchetto qualsiasi: è il gateway che permette alle applicazioni AI di parlare con oltre 100 provider di modelli linguistici, da OpenAI ad Anthropic, da AWS Bedrock a Google Vertex. Chi lo installa gli affida, spesso senza pensarci, le chiavi di accesso a quasi tutto. Ed è esattamente per questo che il gruppo criminale TeamPCP lo ha scelto come bersaglio nella fase 09 di una campagna che aveva già compromesso Trivy e Checkmarx nelle settimane precedenti.

La vicenda, documentata dalla stessa BerriAI, da Snyk, Arctic Wolf, Trend Micro e altri, è molto più di un incident report. È una radiografia del modo in cui l’ecosistema software moderno si fida dei propri strumenti, e di quanto quella fiducia possa essere sfruttata. Come ha già riportato ICT Security Magazine, si tratta di uno degli attacchi alla supply chain AI più consequenziali e meglio documentati degli ultimi anni, e le lezioni che offre riguardano chiunque sviluppi, distribuisca o utilizzi software che dipende da pacchetti open source.

Un attacco a cascata: da Trivy a LiteLLM

L’incidente LiteLLM non è nato isolato. Il 19 marzo 2026, alle 17:43 UTC, gli attaccanti di TeamPCP hanno riscritto i tag Git nel repository GitHub Action di trivy-action per puntare a una release malevola (v0.69.4) contenente lo stesso payload di credential harvesting e la stessa infrastruttura di esfiltrazione poi usata nelle operazioni successive.

L’attacco ha seguito lo stesso schema utilizzato per compromettere lo scanner di sicurezza Trivy di Aqua e le relative GitHub Actions il 19 marzo, e le estensioni VS Code e GitHub Actions di Checkmarx il 23 marzo. Aqua ha confermato che la compromissione è avvenuta a causa di un contenimento e remediation incompleto di un precedente attacco alla supply chain: la rotazione delle credenziali non è stata atomica e l’attaccante ha potuto utilizzare un token valido per esfiltrare i segreti appena ruotati durante la finestra di rotazione, durata alcuni giorni.

Il meccanismo è un attacco transitivo a cascata. La pipeline CI/CD di LiteLLM eseguiva Trivy come parte del proprio processo di build, scaricandolo da apt senza una versione fissata. L’action compromessa ha esfiltrato il token PYPI_PUBLISH dall’ambiente del runner GitHub Actions.

Come ha sintetizzato Jacob Krell di Suzu Labs nella sua analisi per ReversingLabs, TeamPCP non aveva bisogno di attaccare LiteLLM direttamente: aveva compromesso Trivy, uno scanner di vulnerabilità in esecuzione nella pipeline CI di LiteLLM senza version pinning. Quella singola dipendenza non gestita ha consegnato le credenziali di pubblicazione su PyPI, permettendo di inserire una backdoor in una libreria con 95 milioni di download al mese, una dipendenza, una reazione a catena, cinque ecosistemi compromessi in meno di un mese.

La timeline esatta dell’attacco

La fonte primaria ufficiale di LiteLLM e la ricerca di Snyk permettono di ricostruire con precisione ogni fase.

Il 23 marzo 2026 viene registrato il dominio models.litellm.cloud, il server di esfiltrazione, il giorno prima dell’attacco vero e proprio. Il 24 marzo alle 10:39 UTC viene pubblicata su PyPI la versione malevola 1.82.7, contenente il payload iniettato direttamente nel file proxy_server.py. Tredici minuti dopo, alle 10:52 UTC, viene pubblicata la versione 1.82.8, che introduce un meccanismo di delivery escalato tramite il file.pth. Alle 11:48 UTC, Callum McMahon di FutureSearch apre la issue GitHub numero 24512 con la dicitura: “CRITICO: LiteLLM_init.pth malevolo nel pacchetto PyPI LiteLLM 1.82.8, credential stealer.” Alle circa 13:38 UTC PyPI mette in quarantena il pacchetto. Alle 15:27 UTC i pacchetti compromessi vengono definitivamente eliminati e il pacchetto viene tolto dalla quarantena.

BerriAI ha confermato ufficialmente che le versioni coinvolte sono esclusivamente la v1.82.7 e la v1.82.8, che i clienti che utilizzavano l’immagine Docker ufficiale LiteLLM Proxy (ghcr.io/berriai/litellm) non sono stati colpiti grazie al version pinning rigoroso in requirements.txt, e che gli utenti di LiteLLM Cloud erano parimenti al sicuro. Le versioni v1.82.6 e precedenti sono confermate pulite.

L’anatomia del payload: tre stadi

Le versioni compromesse includevano un credential stealer progettato per raccogliere variabili d’ambiente, chiavi SSH, credenziali cloud (AWS, GCP, Azure), token Kubernetes e password di database, per poi cifrare ed esfiltrare i dati tramite una POST request verso models.litellm.cloud, un dominio che non appartiene all’infrastruttura ufficiale di BerriAI/LiteLLM.

Il payload era strutturato in tre fasi distinte, come documentato da FutureSearch. I dati raccolti venivano cifrati con una chiave pubblica RSA a 4096 bit usando AES-256-CBC (chiave di sessione casuale, cifrata con la chiave RSA), impacchettati in un archivio tar e inviati via POST al dominio di esfiltrazione. In presenza di un token di service account Kubernetes, il malware leggeva tutti i segreti del cluster su tutti i namespace e tentava di creare un pod privilegiato basato su alpine:latest in ogni nodo del kube-system, montando il filesystem dell’host e installando una backdoor persistente tramite un servizio systemd. FutureSearch

Il malware sfruttava un file.pth che si eseguiva automaticamente all’avvio dell’interprete Python. Questo significa che il payload si attivava nella maggior parte dei processi Python senza che il pacchetto venisse esplicitamente importato: era sufficiente avere LiteLLM installato nell’ambiente per innescare l’esecuzione, aumentando significativamente la superficie d’attacco.

Le tecniche MITRE ATT&CK mappate sull’incidente sono: T1546.018 (Python Startup Hooks), T1003 (Credential Dumping) e T1610 (Deploy Container).

Come è stato scoperto: un errore dell’attaccante

La scoperta dell’attacco deve molto a una circostanza fortuita. Un bug nel payload malevolo, un fork bomb che generava processi incontrollati, è stato ciò che ha innescato l’analisi. Senza di esso, il credential stealer avrebbe potuto operare silenziosamente per giorni o settimane prima del rilevamento. L’errore di programmazione dell’attaccante è diventato l’anello debole dell’intera kill chain.

Quando i membri della comunità hanno iniziato a segnalare la compromissione nella issue numero 24512, gli attaccanti hanno pubblicato 88 commenti bot da 73 account unici in una finestra di 102 secondi, tra le 12:44 e le 12:46 UTC, utilizzando account di sviluppatori precedentemente compromessi e non profili appositamente creati. Usando l’account del maintainer compromesso krrishdholakia, gli attaccanti hanno chiuso la issue come “not planned” e effettuato commit su repository non correlati con il messaggio “teampcp update”. La comunità ha aperto una issue di tracciamento parallela e il thread su Hacker News ha raggiunto 324 punti.

Perché LiteLLM era un bersaglio ad alto valore

LiteLLM è utilizzato principalmente dagli sviluppatori come gateway per far sì che le applicazioni client possano chiamare qualsiasi numero di large language model da più di 100 provider, offrendo la possibilità di eseguire A/B testing tra modelli diversi, di costruire ridondanza in applicazioni agentiche e di rispondere a esigenze di auditing e controllo dei costi.

Il pacchetto registrava, secondo Arctic Wolf, circa 97 milioni di download mensili al momento dell’attacco. Gli ambienti che lo eseguono tipicamente archiviano chiavi API di provider multipli, come OpenAI, Anthropic e altri, in un unico punto, rendendolo un target ad alto valore per il credential harvesting.

Come rileva Sonatype, poiché LiteLLM si posiziona direttamente tra le applicazioni e molteplici provider di servizi AI, spesso ha accesso a API key, variabili d’ambiente e altri dati di configurazione sensibili: compromettere un pacchetto in questa posizione consente agli attaccanti di intercettare ed esfiltrare segreti preziosi senza dover violare direttamente i sistemi upstream. La vastità dei dati presi di mira evidenzia come gli ambienti di sviluppo moderni, tra macchine locali, pipeline CI/CD e infrastrutture cloud, siano profondamente interconnessi.

La risposta di LiteLLM e le versioni verificate

Il team BerriAI ha rimosso i pacchetti compromessi da PyPI, ruotato le credenziali dei maintainer stabilendo nuovi maintainer autorizzati, e ha coinvolto il team Mandiant di Google per l’analisi forense della pipeline di build e pubblicazione. Tutte le versioni dalla v1.78.0 alla v1.82.6 sono state verificate tramite calcolo del digest SHA-256, scansione degli indicatori di compromissione noti e confronto con i corrispondenti commit Git nel repository BerriAI/litellm: tutte sono risultate pulite. Sono stati pubblicati i checksum SHA-256 per ogni versione verificata.

Gli indicatori di compromissione (IoC) ufficiali includono la presenza del file litellm_init.pth nella directory site-packages, traffico in uscita verso models.litellm[.]cloud e verso checkmarx[.]zone, entrambi domini estranei all’infrastruttura legittima.

Le lezioni per CISOs e team di sicurezza

1. Il version pinning non è opzionale

I clienti che utilizzavano l’immagine Docker ufficiale LiteLLM Proxy non sono stati colpiti, grazie al version pinning rigoroso in requirements.txt. Chi ha eseguito pip install litellm senza specificare una versione durante la finestra 10:39–16:00 UTC del 24 marzo 2026 è potenzialmente esposto. Lo stesso vale per chi ha costruito immagini Docker in quella finestra, o per chi dipende da LiteLLM come dipendenza transitiva non fissata, ad esempio tramite framework di AI agent, server MCP o strumenti di orchestrazione LLM.

2. Gli strumenti di sicurezza sono essi stessi vettori di attacco

Uno scanner di sicurezza, lo strumento su cui i difensori si affidano per rilevare compromissioni della supply chain, è diventato il punto di ingresso per una compromissione della supply chain. La compromissione di Trivy in GitHub Actions ha dato all’attaccante le chiavi per pubblicare versioni arbitrarie di LiteLLM su PyPI. La lezione è scomoda ma critica: lo strumento di sicurezza CI/CD ha lo stesso accesso di quello di deployment e se viene compromesso, tutto il downstream è esposto.

3. Il problema strutturale della fiducia implicita

La supply chain del software è ancora costruita su troppa fiducia implicita e non abbastanza immutabilità o verifica. Le organizzazioni consentono routinariamente a GitHub Actions, pacchetti e artefatti di release di terze parti di entrare nelle pipeline di build perché provengono da vendor fidati o progetti popolari, ma questo incidente mostra quanto sia fragile quel modello quando un componente upstream viene compromesso.

Per un approfondimento su questo problema strutturale e le relative strategie di governance, si veda l’analisi pubblicata da ICT Security Magazine sugli approcci integrati per la sicurezza della supply chain ICT.

4. L’AI agent sprawl come rischio identitario

Come evidenzia il blog di Okta Threat Intelligence, in molte organizzazioni l’adozione di AI agent rimane decentralizzata e non ricade sotto la governance di un programma di sicurezza formale. Sviluppatori e amministratori connettono direttamente AI agent ad applicazioni e dati di produzione usando token API statici e credenziali di service account. In ambienti non gestiti, le risorse vengono spesso consultate tramite bearer token memorizzati in file di configurazione: il possesso dei token da solo garantisce l’accesso alla risorsa target, senza vincoli di IP o client specifici.

5. La semplice rimozione del pacchetto non è sufficiente

Le azioni immediate raccomandate da BerriAI includono: ruotare immediatamente tutte le credenziali presenti nei sistemi coinvolti tra cui API key, chiavi di accesso cloud, password di database, chiavi SSH, token Kubernetes e segreti in variabili d’ambiente; verificare la presenza del file litellm_init.pth nella directory site-packages e rimuoverlo immediatamente se presente conservando gli artefatti per l’analisi forense; e verificare la cronologia delle versioni installate in tutti gli ambienti locali, pipeline CI/CD, build Docker e log di deployment.

Il gruppo TeamPCP: profilo di un attore persistente

TeamPCP è attivo almeno da dicembre 2025, è noto anche come PCPcat, Persy_PCP, ShellForce e DeadCatx3 secondo il Wiz Threat Center, mantiene canali Telegram e incorpora la stringa “TeamPCP Cloud stealer” nei payload. Tutta l’infrastruttura è consistente tra tutte le operazioni: stessa coppia di chiavi RSA, stesso bundle tpcp.tar.gz e repository GitHub con prefisso tpcp-docs usati come staging C2. Il gruppo ha anche distribuito CanisterWorm, che utilizza l’Internet Computer Protocol (ICP) come canale C2 con il vantaggio che i canister ICP non possono essere rimossi da registrar o provider di hosting. La compromissione di LiteLLM rappresenta la fase 09 di questa campagna in corso.

Tutti e tre i domini utilizzati nell’operazione, ovvero scan.aquasecurtiy[.]org, checkmarx[.]zone e models.litellm[.]cloud, condividono lo stesso registrar (Spaceship, Inc.) e lo stesso provider di hosting (DEMENIN B.V.), dettaglio che conferma l’attribuzione a un singolo attore e fornisce un indicatore di rilevamento per operazioni future.

Conclusioni

L’attacco LiteLLM è la manifestazione più recente e documentata di una tendenza in rapida accelerazione: i pacchetti largamente fidati all’interno dell’ecosistema AI diventano bersagli ad altissimo valore nelle campagne di software supply chain attack, in quanto concentrano in un unico punto credenziali e accessi a sistemi critici distribuiti. La velocità con cui le organizzazioni adottano strumenti AI, spesso senza i controlli di governance applicati al software tradizionale, amplifica esponenzialmente il raggio d’esplosione di ogni singola compromissione.

La risposta richiede un approccio sistemico: version pinning rigoroso e fissato a commit SHA e non a tag mutabili, SBOM aggiornate, verifica crittografica degli artefatti tramite digest SHA-256, rotazione regolare delle credenziali, e soprattutto il riconoscimento che gli strumenti di sicurezza inseriti nelle pipeline CI/CD devono essere sottoposti agli stessi controlli di sicurezza che essi stessi applicano al codice che analizzano.