LiteLLM, attacco alla supply chain su PyPI: due versioni-trappola rubano segreti in pochi minuti

Bastano due release “avvelenate” per trasformare una libreria molto usata in un aspirapolvere di credenziali. È quello che è successo aLiteLLM, pacchetto Python diffusissimo tra i team che lavorano con l’IA perché fa da “ponte” tra applicazioni e diversi modelli di linguaggio attraverso un’unica API.

Il risultato è un classico incubo dasupply chain: quando cade una dipendenza centrale, non si espone solo il portatile di uno sviluppatore. Rischiano di finire nel mirino anche server, immagini Docker e pipelineCI/CD(le catene automatiche che compilano, testano e distribuiscono software), spesso piene di permessi e segreti operativi.

L’operazione viene attribuita aTeamPCP, gruppo già collegato ad altre compromissioni recenti. Le versioni considerate malevole sono state pubblicate su PyPI e poi rimosse; al momento, la versione indicata come “pulita” è1.82.6.

Le versioni compromesse: LiteLLM 1.82.7 e 1.82.8 pubblicate e rimosse in fretta

Le release finite sotto accusa sono1.82.7e1.82.8. Il punto non è solo “cosa” contenevano, ma “quanto” velocemente possono fare danni: una volta ottenuto l’accesso, pubblicare una versione truccata richiede minuti, e le installazioni arrivano a cascata.

In molte aziende e team, l’aggiornamento è un gesto automatico: unpip install -Ulanciato per abitudine può bastare a far entrare la payload. E quando una libreria è al centro di strumenti interni e servizi cloud, l’effetto domino è immediato.

I primi numeri pubblici rendono l’idea: in una finestra brevissima, le versioni malevole sarebbero state scaricate circa47.000 volte in 46 minuti. Non significa 47.000 macchine infette (un download può finire su un server condiviso o in un’immagine replicata), ma fotografa la velocità con cui un repository di dipendenze può distribuire un problema su larga scala.

Il malware, secondo Endor Labs: furto di segreti, esfiltrazione cifrata e persistenza

Le analisi dei ricercatori descrivono uninfostealerorganizzato in tre fasi. Prima la raccolta silenziosa di tutto ciò che può aprire porte:chiavi SSH, password, credenziali cloud, token di accesso aKubernetes, contenuti di file.enve perfino frasi di recupero di wallet crypto.

Seconda fase: l’esfiltrazione. I dati vengono impacchettati e inviati verso infrastrutture controllate dagli attaccanti sotto forma di archivi cifrati. In ambienti di sviluppo e build, questo traffico può confondersi con il “rumore” normale: download di dipendenze, chiamate API, push di artefatti.

Terza fase: lapersistenza. Il codice installerebbe una backdoor mascherata da servizio di sistema con un nome studiato per non insospettire:System Telemetry Service. Un’etichetta che ricorda strumenti di monitoraggio e osservabilità: se nessuno fa inventario dei servizi sui runner o sulle macchine di build, può restare lì a lungo e ricevere comandi da remoto.

C’è poi un dettaglio tecnico che rende la faccenda ancora più insidiosa: nella1.82.8l’aggiunta di un file.pthpermetterebbe di attivare la payload a ogni avvio di Python, anche se LiteLLM non viene usato direttamente. Tradotto: lo installi “solo per provare” e intanto il codice può continuare a girare.

Il punto debole: Trivy nel pipeline e versioni non “pinnate”

La catena ricostruita segue uno schema già visto in altri incidenti: LiteLLM avrebbe usatoTrivy(strumento noto per la scansione di vulnerabilità) nel proprio pipeline senza fissare una versione specifica. Quando una dipendenza non è “pinnata”, un aggiornamento inatteso o una compromissione a monte può contaminare proprio gli strumenti che servono a costruire e pubblicare software.

Il paradosso è evidente: un tool di sicurezza, inserito per ridurre il rischio, diventa l’innesco. Secondo la ricostruzione, l’esecuzione della versione compromessa nel pipeline avrebbe esposto una chiave segreta utile a pubblicare pacchetti a nome di LiteLLM sul repository ufficiale. Con quella chiave in mano, gli attaccanti possono “parlare” con la voce del progetto.

Non è il classico bug nel codice: è una combinazione di pratiche pericolose, dipendenze non bloccate, segreti accessibili al pipeline, fiducia implicita in componenti terzi. Uno scenario che ricorda molte realtà anche italiane, dove la pressione sul rilascio rapido porta a pipeline permissivi, log troppo verbosi e token distribuiti più del necessario.

Gli attaccanti avrebbero registrato domini per ricevere i dati rubati, tra cuimodels.litellm.cloud, costruito per somigliare a un indirizzo legittimo. Questo tipo di “mimetismo” rende più difficile intercettare l’esfiltrazione con controlli basati su liste di domini attesi, se le destinazioni di rete non vengono validate in modo rigoroso.

Perché l’impatto può esplodere: download enormi e rischio CI/CD

LiteLLM non è una libreria di nicchia. I numeri citati sulla sua diffusione sono impressionanti: oltre3 milionidi download al giorno e circa95 milioninegli ultimi 30 giorni. Anche se le versioni compromesse sono “solo” due, la base installata e la frequenza degli aggiornamenti nel mondo IA amplificano l’esposizione.

Il rischio maggiore non è il singolo PC. Python gira ovunque: runner CI/CD, job di data engineering, notebook condivisi, container che vengono ricostruiti di continuo. Se una versione malevola entra in un’immagine Docker o in un pipeline, può replicarsi rapidamente e raggiungere ambienti con privilegi più ampi.

Ed è qui che i segreti rubati diventano un grimaldello: un token cloud può aprire servizi e storage, un token Kubernetes può dare accesso a un cluster, un file.env può contenere chiavi API di servizi IA a pagamento. Il danno è doppio: fuga di dati e compromissione dell’infrastruttura.

Alcuni report parlano di circa500.000eventi di esfiltrazione o dispositivi infetti, ma senza conferme indipendenti: un numero da trattare con cautela. Resta il punto sostanziale: anche se la tua azienda non ha installato quelle versioni, potrebbero averlo fatto fornitori, consulenti o componenti interni che poi si collegano ai tuoi sistemi.

La versione “pulita” è 1.82.6: cosa fare se si è esposti

Il riferimento indicato come sicuro, allo stato attuale, èLiteLLM 1.82.6. Se qualcuno ha installato1.82.7o1.82.8, non basta “tornare indietro” come fosse un normale downgrade: va trattato come unincidente di sicurezzacompleto.

La rimozione del pacchetto da PyPI non “disinfetta” le macchine già colpite. Le azioni operative suggerite dalle indicazioni pubbliche vanno nella direzione di: identificare tutti gli host e i runner che hanno installato le versioni incriminate, riportare l’ambiente a una versione sana, e assumere che i segreti possano essere stati sottratti.

In pratica: mappare le installazioni di1.82.7e1.82.8, aggiornare/riportare a1.82.6, poirevocare e rigenerarecredenziali e token (cloud, Kubernetes, chiavi SSH, token di pubblicazione e di deploy) e controllare i log di accesso nel periodo interessato. Nel mondo CI/CD, significa anche verificare i permessi: chi può pubblicare, chi può leggere segreti, quali job ne hanno davvero bisogno.

L’episodio riapre una discussione che molte organizzazioni rimandano: trattare PyPI come “negozio affidabile per default” è comodo, ma non realistico. Una compromissione del pipeline può bastare a pubblicare codice malevolo sotto un’identità legittima. La risposta, nel medio periodo, passa da pratiche più rigide: versioni bloccate, mirror interni, controlli d’integrità e monitoraggio delle connessioni in uscita dai runner. Meno glamour, ma decisivo per evitare che un semplice import Python diventi una fuga generalizzata.