LiteLLM, attacco alla supply chain espone credenziali di migliaia di organizzazioni

Le versioni malevole pubblicate su PyPI

Un attacco alla supply chain di LiteLLM, gateway open source per applicazioni basate sull’intelligenza artificiale, avrebbe portato alla distribuzione del backdoor SANDCLOCK e all’esposizione di numerose credenziali operative.

L’operazione è attribuita al gruppo TeamPCP, che secondo le ricostruzioni avrebbe sottratto le credenziali degli amministratori del progetto. Gli aggressori avrebbero poi caricato su PyPI le versioni compromesse 1.82.7 e 1.82.8, pubblicate intorno a marzo 2026.

La finestra di esposizione potrebbe quindi essersi protratta per almeno alcuni mesi. Alcune organizzazioni potrebbero non avere ancora rilevato l’installazione del componente alterato o l’uso successivo delle credenziali sottratte.

LiteLLM viene utilizzato come libreria e livello di integrazione per indirizzare le richieste verso oltre cento fornitori di modelli linguistici. Tra gli ambienti collegabili figurano OpenAI, Anthropic, Google Gemini e i modelli locali gestiti tramite Ollama.

La compromissione di un componente installato in pipeline automatiche può ampliare notevolmente il perimetro dell’attacco. Non serve colpire direttamente ogni azienda: è sufficiente inserire codice malevolo in un elemento condiviso da molte applicazioni e processi di sviluppo.

SANDCLOCK e il possibile percorso delle credenziali

Il brief disponibile identifica SANDCLOCK come backdoor, ma non rende noto il suo funzionamento interno, né indica quali dati raccolga direttamente o verso quali infrastrutture li invii.

L’elemento più rilevante è il contesto d’esecuzione di LiteLLM. Il software può trovarsi in ambienti di sviluppo, sistemi di integrazione e distribuzione continua, strumenti di automazione e servizi che devono autenticarsi verso provider cloud o API di intelligenza artificiale.

In queste condizioni, un pacchetto alterato può entrare in contatto con variabili d’ambiente, file di configurazione e secret utilizzati dalle pipeline. Le credenziali potenzialmente esposte includono:

• chiavi per infrastrutture AWS, GCP e Firebase;
• token per registry come Amazon ECR e JFrog;
• token personali di accesso GitHub, o PAT;
• chiavi private delle GitHub App;
• credenziali SSH;
• secret di cluster Kubernetes;
• password di firma;
• chiavi API per servizi di IA, incluse quelle di OpenAI e Anthropic.

Un accesso di questo tipo può consentire di leggere o modificare repository, manipolare pipeline di build e deployment, raggiungere registri di immagini o pacchetti e intervenire su infrastrutture cloud. In presenza di permessi elevati, il rischio può estendersi ai cluster Kubernetes e ai servizi pubblicati da tali ambienti.

Non è noto se ogni credenziale raccolta sia stata utilizzata per attività successive. La semplice esposizione, tuttavia, richiede la revoca e la sostituzione dei segreti, perché non è sufficiente presumere che una chiave non sia stata sfruttata.

Le dimensioni dell’esposizione

Resecurity ha analizzato un archivio da 150 GB attribuito all’attività di TeamPCP. Al suo interno, i manifesti owners.txt e repos.txt riporterebbero 898 proprietari GitHub distinti, tra organizzazioni e account, distribuiti su 2.038 repository.

La compromissione è frammentata: 631 proprietari avrebbero un solo repository nell’elenco. Il soggetto con il maggior numero di repository coinvolti sarebbe Cencosud-Cencommerce, con 64.

Tra i nomi presenti figurano Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me e 1inch.

Resecurity ha censito 2.146 record sulla base dei nomi delle chiavi. I valori non sarebbero stati esaminati oltre il mascheramento strutturale; il numero indica quindi gli elementi individuati nell’archivio, non necessariamente credenziali ancora valide o utilizzate con successo.

Secondo la ricostruzione, l’incidente avrebbe interessato oltre 2.500 organizzazioni e centinaia di migliaia di ambienti CI/CD. La differenza tra il numero complessivo delle organizzazioni e quello dei proprietari GitHub elencati può dipendere dalla struttura dei dati analizzati e dai criteri di censimento.

Tecnologia, finanza e sanità tra i settori esposti

Il settore più rappresentato è quello della tecnologia e del software, dove l’uso di strumenti open source e pipeline automatizzate è particolarmente diffuso.

Seguono banche, finanza e assicurazioni, quindi sanità, farmaceutico e medtech. La presenza di organizzazioni regolamentate aumenta la rilevanza dell’incidente: una compromissione può avere conseguenze sulla continuità operativa, sulla protezione dei dati e sugli obblighi di gestione degli accessi.

Gli altri comparti identificati sono:

1. retail ed e-commerce;
2. media, gaming e adtech;
3. manifattura e industria;
4. servizi professionali;
5. cybersecurity;
6. criptovalute;
7. pubblica amministrazione.

Il rischio concreto varia in base ai privilegi assegnati a LiteLLM e alle pipeline in cui il pacchetto è stato installato. Un ambiente di test isolato non ha lo stesso impatto di un runner CI/CD autorizzato a pubblicare immagini, aggiornare infrastrutture o distribuire applicazioni in produzione.

L’attacco può inoltre aumentare il tempo necessario per individuare l’incidente. Il malware potrebbe essere stato eseguito in numerosi ambienti con configurazioni diverse, rendendo più complessa la correlazione degli eventi e aumentando sia il MTTD, il tempo medio di rilevamento, sia il MTTR, il tempo medio di risposta e ripristino.

Le verifiche da avviare subito

Le organizzazioni che hanno installato LiteLLM devono verificare la presenza delle versioni 1.82.7 e 1.82.8 nei progetti, nelle immagini container, nelle cache dei package manager e nei runner CI/CD. Occorre controllare anche eventuali installazioni indirette tramite dipendenze o immagini preconfigurate.

In caso di presenza o dubbio, la risposta dovrebbe comprendere:

• revoca e rigenerazione delle chiavi private delle GitHub App;
• sostituzione dei PAT e dei token GitHub;
• rotazione delle credenziali AWS, GCP e Firebase;
• revoca dei token ECR e JFrog;
• sostituzione delle chiavi SSH;
• cambio delle password di firma;
• rigenerazione delle chiavi API per i provider AI;
• invalidazione delle sessioni attive.

La rotazione va eseguita partendo dagli account con privilegi amministrativi e dai segreti usati nei processi di build e deployment. I nuovi valori non dovrebbero essere reinseriti in pipeline non ancora verificate.

La fase successiva consiste nell’analisi dei log GitHub, dei runner CI/CD, dei registry, dei provider cloud e dei cluster Kubernetes. È necessario cercare accessi anomali, creazioni di token, modifiche ai workflow, nuove chiavi SSH, pubblicazioni inattese di pacchetti o immagini e deployment non riconducibili ai normali operatori.

Non sono disponibili indicazioni su un inserimento dell’incidente nel catalogo KEV della CISA, né su una relativa scadenza per la mitigazione. Il materiale disponibile non indica inoltre un identificativo CVE associato.

Chi ha installato LiteLLM nel periodo interessato dovrebbe trattare le credenziali presenti nell’ambiente come potenzialmente esposte, anche in assenza di indicatori immediati di abuso. La compromissione di una dipendenza software può lasciare tracce nei sistemi a valle molto dopo la pubblicazione del pacchetto malevolo.