Il 24 marzo 2026 il pacchetto Python LiteLLM, proxy API per modelli linguistici con circa 3,4 milioni di download giornalieri, ha distribuito due versioni malevole direttamente dal repository ufficiale PyPI. Le versioni 1.82.7 e 1.82.8 contenevano un credential stealer attivato dal meccanismo .pth dell'interprete Python, che esegue codice senza richiedere un import esplicito. La compromissione è avvenuta tramite un security scanner, Trivy, usato nella pipeline CI/CD del progetto: il tool progettato per trovare vulnerabilità è diventato il vettore di attacco.
- Le versioni 1.82.7 (10:39 UTC) e 1.82.8 (10:52 UTC) sono state pubblicate con credenziali PyPI valide esfiltrate da un Trivy GitHub Action compromesso (v0.69.4)
- Il payload usava il file
litellm_init.pth(34.628 byte, doppio base64-encoded) per eseguire all'avvio dell'interprete Python, mappato alla tecnica MITRE ATT&CK T1546.018 - Il malware raccoglieva credenziali da oltre 50 categorie, cifrava con AES-256-CBC e chiave RSA-4096, e inviava a
models.litellm.cloud, dominio registrato il 23 marzo 2026 - La scoperta è stata causata da una fork bomb involontaria nel payload, rilevata da Callum McMahon di FutureSearch
- La chiave RSA pubblica è identica a quella di payload Trivy e KICS compromessi, confermata da Wiz, costituendo il principale elemento di attribution per la campagna TeamPCP
Come il canale di pubblicazione è diventato il bersaglio
LiteLLM è un proxy API open source che standardizza l'accesso a decine di provider di modelli linguistici. Non è un'applicazione end-user: è infrastruttura nascosta, spesso dipendenza transitiva di framework AI più ampi. Secondo la dichiarazione ufficiale del progetto, il 24 marzo 2026 le versioni 1.82.7 e 1.82.8 sono state pubblicate su PyPI da un account con credenziali valide, non tramite typosquatting o pacchetto contraffatto.
L'origine della compromissione è stata identificata nel token PYPI_PUBLISH esfiltrato dalla pipeline CI/CD. Il vettore: una GitHub Action di Trivy, scanner di vulnerabilità container, in versione compromessa (v0.69.4). Trivy non aveva version pinning nella configurazione di LiteLLM. Il tool, progettato per proteggere la supply chain, ha concentrato i privilegi necessari a violarla.
Le due versioni malevole mostrano un'iterazione operativa rapida: 13 minuti tra la pubblicazione della prima e della seconda. La 1.82.7 conteneva il payload in proxy_server.py; la 1.82.8 ha aggiunto il meccanismo .pth, più stealth. I pacchetti sono rimasti disponibili su PyPI fino alle 15:27 UTC: una finestra di circa tre ore secondo Snyk, o circa 40 minuti secondo la timeline ufficiale di LiteLLM, che indica una quarantena anticipata.
Il meccanismo .pth e l'invisibilità del payload
La tecnica centrale del secondo stadio è il file litellm_init.pth, collocato in site-packages. I file .pth sono gestiti dall'interprete Python all'avvio: contengono path di ricerca, ma possono anche eseguire codice arbitrario se contengono istruzioni import. Questo significa che il payload si attivava con ogni avvio di Python, indipendentemente dal modulo importato dall'utente.
Snyk descrive il file come doppio base64-encoded, 34.628 byte, progettato per eludere analisi statiche superficiali. Trend Micro conferma che il meccanismo richiede "nessun import" esplicito da parte della vittima. Il payload, una volta attivo, operava in tre fasi: raccolta credenziali da oltre 50 categorie (cloud, wallet crypto, variabili d'ambiente, configurazioni CI/CD), cifratura con AES-256-CBC usando chiave RSA-4096, esfiltrazione via POST HTTPS al dominio models.litellm.cloud.
La persistenza era garantita da un servizio systemd denominato sysmon.service, nome che imita strumenti di monitoraggio legittimi. Il malware implementava anche movimento laterale in ambienti Kubernetes. Il dominio C2 era stato registrato il 23 marzo 2026, un giorno prima della pubblicazione, e non appartiene a BerriAI, società dietro LiteLLM.
La fork bomb che ha smascherato l'attacco
Il rilevamento non è avvenuto per analisi proattiva del pacchetto, ma per un errore dell'attaccante. Il payload conteneva una ricorsione processi non intenzionale, una fork bomb, che ha causato il consumo esaustivo delle risorse sui sistemi infetti. Callum McMahon di FutureSearch ha identificato l'anomalia e ha aperto l'issue #24512 su GitHub.
L'account del maintainer Krrish Dholakia, co-fondatore e CEO di BerriAI, era già compromesso. ReversingLabs documenta che l'attaccante ha usato questo accesso per chiudere l'issue #24512 con un commit denominato "teampcp update", tentando di sopprimere la disclosure. ICT Security Magazine riporta 88 commenti bot da 73 account in 102 secondi, un'operazione di spam coordinata per occultare la segnalazione. La discussione ha raggiunto 324 punti su Hacker News, forzando la visibilità pubblica.
"TeamPCP did not need to attack LiteLLM directly. They compromised Trivy, a vulnerability scanner running inside LiteLLM's CI pipeline without version pinning. That single unmanaged dependency handed over the PyPI publishing credentials, and from there the attacker backdoored a library that serves 95 million downloads per month." — Jacob Krell, senior director Suzu Labs, via ReversingLabs
L'attribution e la campagna estesa
L'elemento di attribution più solido è la chiave RSA pubblica identica tra i payload di LiteLLM, Trivy e KICS. Wiz ha confermato questa corrispondenza attraverso tutte e tre le operazioni. ReversingLabs descrive la chiave come "well known RSA public key seen across multiple payloads", indicando una campagna coordinata sotto l'etichetta TeamPCP.
TeamPCP ha rivendicato pubblicamente, tramite ICT Security Magazine, che "many of your favourite security tools and open-source projects will be targeted in the months to come". La dichiarazione identifica esplicitamente gli strumenti di sicurezza come target privilegiati: concentrano accesso, credenziali e fiducia implicita nelle pipeline.
Il brief non specifica se il dominio models.litellm.cloud sia stato successivamente sinkholed o se rimanga attivo. Non emergono sovrapposizioni infrastrutturali che colleghino TeamPCP ad altri gruppi di threat actor allo stato attuale.
Perche e importante
Il brief non documenta misure correttive specifiche oltre alla certificazione della versione 1.82.6 come safe e al rilascio della pipeline CI/CD v2 con la versione 1.83.0. Il dossier non specifica se LiteLLM abbia implementato version pinning per Trivy o altre GitHub Action successive all'incidente. Non è dichiarato se Snyk o altri vendor abbiano rilasciato regole di rilevamento dedicate al hash del payload .pth.
L'immagine Docker ufficiale ghcr.io/berriai/litellm è risultata non impattata, grazie a un version pinning preesistente in requirements.txt. Questo dettaglio evidenzia una discontinuità: la pratica era applicata al container ma non alla pipeline CI/CD che generava il pacchetto PyPI.
Il dossier non quantifica il numero esatto di installazioni delle versioni compromesse durante la finestra di esposizione. Non specifica l'entità completa dei dati effettivamente esfiltrati dal dominio C2, né lo stato di eventuali indagini legali sull'identità dei membri di TeamPCP.
Il paradosso del security tool come attack vector
L'incidente inverte la logica della supply chain security. Gli strumenti che auditano dipendenze e container sono bersagli preferenziali: girano con privilegi elevati, accedono a segreti di pubblicazione, e godono di fiducia implicita. La loro compromissione non genera allarmi: fanno esattamente ciò che è previsto che facciano.
Il meccanismo .pth aggira un'assunzione fondamentale dei controlli tradizionali: che il codice malevolo richieda un import esplicito. Gli strumenti di Software Composition Analysis (SCA) tracciano le chiamate di import; il payload di LiteLLM non ne aveva bisogno. La tecnica è nota da tempo, ma la sua applicazione a un pacchetto PyPI di questa visibilità ne dimostra l'efficacia pratica contro difese standard.
Il volume di download — circa 3,4 milioni al giorno secondo Trend Micro e Snyk, oppure 95 milioni al mese secondo una stima alternativa riportata da ICT Security Magazine e ReversingLabs — colloca LiteLLM in una categoria di rischio sistemico. Non è una dipendenza dichiarata: è spesso transitiva, nascosta sotto strati di astrazione framework AI. La stima cumulativa di 480 milioni di download totali, da ReversingLabs, indica una superficie di esposizione estesa nel tempo.
La citazione di Trend Micro sintetizza il problema strutturale: "Your CI/CD security tooling has the same access as your deployment tooling. If it's compromised, everything downstream is exposed." La sicurezza della supply chain non può affidarsi alla fiducia implicita in tool che essa stessa è chiamata a verificare.
Domande frequenti
Perché la fork bomb ha smascherato l'attacco?
La fork bomb era un bug, non una contromisura difensiva. L'attaccante ha commesso un errore di programmazione nella logica ricorsiva del payload .pth, causando proliferazione incontrollata di processi. Questo ha reso visibile un malware altrimenti progettato per operare silenziosamente.
Perche il meccanismo .pth è particolarmente insidioso?
Perché si attiva all'avvio dell'interprete Python, prima di qualsiasi import da parte dell'utente. Controlli di sicurezza basati su analisi delle dipendenze dichiarate o su behavioral monitoring dell'applicazione principale non lo intercettano. Richiede ispezione esplicita dei file .pth in site-packages.
Che differenza c'è tra la finestra di 40 minuti e quella di 3 ore?
La dichiarazione ufficiale di LiteLLM indica una quarantena rapida del pacchetto, circa 40 minuti dopo la pubblicazione iniziale. Snyk riporta una finestra più lunga fino alla rimozione definitiva da PyPI alle 15:27 UTC. La discrepanza riflette probabilmente diverse metriche: tempo alla quarantena interna versus tempo alla rimozione pubblica.
Le informazioni sono basate sull advisory citata e aggiornate al momento della pubblicazione.
Fonti
- https://www.ictsecuritymagazine.com/articoli/supply-chain-software-litellm/
- https://www.aiutocomputerhelp.it/litellm-compromessa-un-brutto-guaio/
- https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html
- https://docs.litellm.ai/blog/security-update-march-2026
- https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/
- https://www.ictsecuritymagazine.com/notizie/litellm-supply-chain/
- https://www.reversinglabs.com/blog/teampcp-supply-chain-attack-spreads
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.