La compromissione di Trivy sarebbe all’origine dell’attacco che ha esposto oltre 2.500 organizzazioni

LiteLLM sarebbe stata solo la fase più visibile

La compromissione della supply chain di LiteLLM non sarebbe iniziata nel progetto stesso. Secondo una ricostruzione di SOCRadar, la maggior parte delle oltre 2.500 organizzazioni associate all’incidente era stata esposta in precedenza attraverso Trivy, strumento di Aqua Security.

LiteLLM rappresenterebbe quindi l’ultimo passaggio di una campagna più ampia, attribuita al gruppo TeamPCP. L’attore è già stato collegato ad attacchi contro progetti open source e al worm Shai-Hulud.

La notizia è stata rilevata il 14 agosto 2026. La stima iniziale di oltre 2.500 organizzazioni, diffusa anche da CloudSEK e HudsonRock, non equivale però a un censimento di compromissioni confermate. SOCRadar ha potuto ricostruire con identificativi attribuibili 2.188 entità.

La differenza dipende dalla disponibilità di dati utili a collegare ogni record a una specifica organizzazione. Nel campione analizzato, il 56% dei record è classificato ad alta confidenza, il 39% a confidenza media e il 6% a bassa confidenza.

Le corrispondenze più solide derivano dall’identità degli host CI e dai domini legittimi dei committer. Anche in questi casi, tuttavia, l’esposizione di una credenziale non dimostra automaticamente che sia stata utilizzata dall’attaccante.

Il passaggio da Trivy ai registri software

La campagna ha seguito uno schema con caratteristiche worm-like. Il codice malevolo veniva eseguito quando il pacchetto compromesso era scaricato e utilizzato, quindi cercava credenziali, token, chiavi API e altri segreti presenti nell’ambiente.

I dati raccolti potevano consentire all’attore di accedere a ulteriori repository o registri. Le credenziali degli sviluppatori venivano quindi riutilizzate per modificare pacchetti alla portata dell’attaccante e pubblicare versioni alterate.

Il primo punto osservato nella catena è una build malevola di Trivy. La prima raccolta di dati è stata registrata il 19 marzo alle 18:05 UTC, appena 18 minuti dopo la pubblicazione della build compromessa.

L’attività è cresciuta il 22 e il 23 marzo, quando immagini Trivy malevole risultavano disponibili su Docker Hub. In questa fase il malware avrebbe raggiunto numerosi ambienti di sviluppo e integrazione continua, raccogliendo informazioni dai sistemi utilizzati per costruire e distribuire software.

Il 24 marzo sono state pubblicate due versioni malevole di LiteLLM. I numeri di versione esatti non sono stati resi noti. I pacchetti sono rimasti disponibili su PyPI per circa 40 minuti, prima della quarantena.

Quell’intervallo non rappresenta l’intera durata dell’esposizione. Per SOCRadar, è soltanto l’ultima fase di una campagna iniziata con la compromissione di Trivy. L’ultima attività rilevata risale al 24 marzo alle 20:09 UTC.

Per 2.085 organizzazioni, pari al 95% delle entità analizzate, la raccolta dei dati era già terminata prima della pubblicazione dei pacchetti LiteLLM. Questo elemento rafforza l’ipotesi che LiteLLM sia stato utilizzato come passaggio finale o più evidente, non come origine dell’operazione.

Perché il payload .pth ha aggirato alcune difese

I pacchetti LiteLLM alterati contenevano un file con estensione .pth. Python può caricare ed eseguire automaticamente questo tipo di file all’avvio dell’interprete, anche quando l’applicazione non importa direttamente LiteLLM.

Il comportamento amplia significativamente la superficie d’attacco. Un’organizzazione poteva installare o avviare l’ambiente compromesso senza richiamare esplicitamente il componente malevolo nel proprio codice.

Il meccanismo consentiva inoltre di eludere le protezioni basate sull’opzione ignore-scripts. Questa impostazione può impedire l’esecuzione di script durante l’installazione dei pacchetti, ma non blocca necessariamente il caricamento automatico di un file .pth da parte dell’interprete Python.

La persistenza sui sistemi già infettati è un ulteriore elemento di rischio. Anche dopo la rimozione del pacchetto originario, il payload poteva continuare a operare nell’ambiente compromesso.

Per questo la quarantena dei pacchetti su PyPI ha interrotto l’attività osservata, ma non consente da sola di escludere la presenza di componenti già eseguiti o di credenziali già sottratte.

CI/CD, cloud e identità degli sviluppatori nel mirino

La campagna ha interessato sei piattaforme di integrazione e distribuzione continua:

• GitHub Actions;
• GitLab CI;
• Jenkins;
• Bitbucket;
• CircleCI;
• Buildkite.

Il coinvolgimento di questi ambienti è particolarmente delicato. Le pipeline CI/CD dispongono spesso di autorizzazioni per leggere il codice, creare artefatti, pubblicare pacchetti e accedere a infrastrutture cloud.

Le organizzazioni colpite erano distribuite a livello globale. Germania, Brasile e Francia risultano i Paesi maggiormente rappresentati nella ricostruzione.

Più di 1.000 organizzazioni avrebbero esposto token JWT e token di autenticazione. Tra gli altri dati individuati figurano chiavi private, chiavi AWS, token GitLab, chiavi API OpenAI, webhook Slack, token GitHub Actions e chiavi API Google.

In oltre 1.100 organizzazioni sarebbero stati inoltre raccolti gli indirizzi email dei committer. L’associazione tra identità degli sviluppatori e token utilizzabili da processi automatici può facilitare attacchi mirati, impersonificazione e ulteriore accesso ai sistemi di sviluppo.

Alcuni record mostrano una quantità eccezionale di segreti: il più consistente ne conterrebbe circa 3.477, mentre un altro ne conterrebbe circa 3.459 distribuiti in appena sei file. Le organizzazioni collegate a questi casi non sono state identificate.

I dati sarebbero già disponibili sul mercato criminale

I segreti sottratti non sarebbero rimasti soltanto nei sistemi dell’attaccante. Un soggetto sta promuovendo su Telegram una raccolta che includerebbe dati attribuiti a LiteLLM, Trivy e CanisterWorm.

Non è noto se tutto il materiale provenga dallo stesso momento della campagna. La raccolta potrebbe essere stata assemblata in fasi diverse, ma la sua disponibilità aumenta comunque il rischio operativo per le organizzazioni esposte.

Token CI/CD, chiavi cloud e credenziali degli sviluppatori possono essere utilizzati per accedere a repository, modificare pipeline, pubblicare nuovi pacchetti malevoli o raggiungere servizi esterni. Le chiavi API possono inoltre generare costi, consentire l’accesso a dati o essere sfruttate in attività automatizzate.

La combinazione tra propagazione automatica e riutilizzo delle credenziali spiega perché l’incidente non debba essere considerato limitato a LiteLLM. Un singolo pacchetto compromesso può diventare il punto d’ingresso verso una rete di progetti, pipeline e registri software.

Cosa devono verificare le organizzazioni esposte

L’unica misura di contenimento documentata è la quarantena dei pacchetti malevoli LiteLLM da parte di PyPI. Non sono state rese note patch specifiche, versioni corrette, procedure ufficiali di bonifica o un elenco completo di indicatori tecnici.

Le organizzazioni che hanno utilizzato Trivy o LiteLLM negli ambienti interessati dovrebbero verificare le pipeline CI/CD, i repository e la presenza di file .pth non attesi. Devono inoltre considerare potenzialmente compromessi i segreti individuati, fino a una validazione indipendente.

La semplice rimozione del pacchetto non è sufficiente a escludere la persistenza. Occorre controllare anche gli host sui quali il codice potrebbe essere stato eseguito e analizzare eventuali pubblicazioni, modifiche ai repository o accessi anomali successivi.

Il brief non riporta istruzioni ufficiali dei vendor per la remediation, né conferma se la vulnerabilità o la campagna siano state inserite nel catalogo KEV della CISA. Non sono quindi disponibili una data di ingresso nel catalogo o una scadenza CISA da rispettare.

La priorità operativa resta la revoca e sostituzione delle credenziali potenzialmente esposte, insieme alla revisione dei permessi delle pipeline. In assenza di una conferma completa sull’utilizzo dei segreti, la prudenza richiede di trattarli come compromessi.