Ars Technica riporta una vasta fuga di credenziali LiteLLM dopo un attacco alla supply chain

Ars Technica riferisce che credenziali collegate a oltre 2.500 organizzazioni sono comparse in dati sottratti tramite un pacchetto AI compromesso. La portata riportata trasforma l'incidente LiteLLM di marzo da un guasto circoscritto del pacchetto in una crisi delle credenziali potenzialmente duratura.

Gli attaccanti hanno compromesso due release ufficiali di LiteLLM e le hanno distribuite tramite il Python Package Index, noto come PyPI. Il codice malevolo cercava nei sistemi infetti chiavi cloud, token di repository, credenziali SSH, password di database e segreti usati dai servizi AI.

L'attacco non è iniziato con LiteLLM. Faceva parte di una campagna che si è mossa attraverso strumenti di sicurezza affidabili, flussi di lavoro degli sviluppatori e account di pubblicazione dei pacchetti. Secondo quanto riportato, ogni anello compromesso ha fornito credenziali che hanno aiutato gli attaccanti a raggiungere un'altra parte della supply chain software.

I dati appena riportati offrono un quadro più chiaro, ma ancora incompleto, delle conseguenze. I ricercatori hanno collegato centinaia di migliaia di file o record di pipeline a oltre 2.500 organizzazioni. Tuttavia, la presenza di un dominio nei dati sottratti non dimostra che ogni organizzazione elencata abbia subito un accesso non autorizzato.

Questa distinzione conta. La compromissione confermata del pacchetto è avvenuta a marzo 2026, mentre i ricercatori hanno divulgato il dataset più ampio mesi dopo. I team di sicurezza devono ora stabilire se le credenziali raccolte durante l'attacco siano rimaste valide, siano state abusate o siano state ruotate prima che gli attaccanti potessero utilizzarle.

Cosa afferma Ars Technica che rivelino i dati trapelati

L'ultimo sviluppo non è un altro pacchetto avvelenato, bensì una prova che suggerisce come l'intrusione originaria sia andata ben oltre le prime stime.

Secondo il report sull'esposizione delle credenziali, i ricercatori di sicurezza hanno esaminato una vasta raccolta attribuita agli attaccanti. Il materiale conteneva, secondo quanto riportato, segreti associati a oltre 2.500 organizzazioni.

La raccolta includeva chiavi di accesso cloud, token dei repository di codice sorgente, chiavi SSH, segreti Kubernetes, variabili d'ambiente, credenziali per la pubblicazione di pacchetti e chiavi di provider AI. Si tratta di credenziali operative, non di semplici nomi di account raccolti da una directory pubblica.

Una chiave cloud esposta può garantire l'accesso a infrastrutture ospitate. Un token di repository può rivelare codice sorgente privato o consentire modifiche non autorizzate. Una credenziale di pubblicazione di pacchetti può permettere a un attaccante di distribuire software malevolo a nome di un progetto affidabile.

I segreti Kubernetes creano un'altra via di accesso. Kubernetes è un sistema per gestire applicazioni containerizzate e i suoi account di servizio possono disporre di ampi permessi sull'infrastruttura. Un token sottratto con diritti eccessivi può aiutare un attaccante a passare da un singolo carico di lavoro a un intero cluster.

I ricercatori hanno inoltre associato i dati a circa 434.000 record di integrazione e distribuzione continua. Le pipeline CI/CD automatizzano il testing, la compilazione e il deployment del software, spesso caricando temporaneamente le credenziali in memoria.

Quel numero non dovrebbe essere interpretato come 434.000 violazioni confermate. Un'organizzazione può gestire molti job, runner, repository ed esecuzioni ripetute delle pipeline. I record duplicati possono inoltre gonfiare i conteggi nei dati sottratti durante diverse fasi della campagna.

Il dataset riportato era collegato a una raccolta di file pari a circa 195 TB. Sarebbe fuorviante descrivere ogni byte come una credenziale unica. Tali raccolte possono includere file di sistema duplicati, alberi dei sorgenti, log, archivi e acquisizioni della memoria insieme ai segreti.

La conclusione più difendibile riguarda la portata, non il numero di credenziali. Gli attaccanti sembrano aver raccolto dati da numerosi ambienti di sviluppo in cui erano presenti credenziali di valore. La dimensione del materiale complica inoltre la verifica e la notifica alle vittime.

CloudSEK ha creato un servizio di verifica ricercabile che consente alle organizzazioni di controllare se i loro domini compaiono nel materiale analizzato. Una corrispondenza dovrebbe avviare un'indagine, ma non è una prova conclusiva che un attaccante sia entrato nella rete dell'organizzazione.

Allo stesso modo, nessuna corrispondenza dovrebbe offrire scarsa rassicurazione se un'organizzazione ha installato un pacchetto interessato. I dataset possono essere incompleti, i domini possono non comparire negli artefatti delle macchine e l'infrastruttura degli attaccanti può guastarsi prima di registrare una vittima.

Il resoconto cambia quindi l'urgenza dell'incidente senza risolvere ogni interrogativo. Le organizzazioni necessitano di registri locali delle installazioni, telemetria di rete, log di audit cloud e cronologie delle credenziali per stabilire la loro effettiva esposizione.

Un pacchetto AI affidabile è diventato il meccanismo di distribuzione

Compromettere LiteLLM era pericoloso perché opera abitualmente accanto alle stesse credenziali che gli attaccanti vogliono sottrarre.

LiteLLM fornisce un'interfaccia comune per le applicazioni che chiamano diversi servizi di modelli linguistici di grandi dimensioni. Invece di mantenere integrazioni separate, gli sviluppatori possono instradare le richieste attraverso un proxy o una libreria Python.

Questa comodità colloca LiteLLM vicino alle chiavi API di OpenAI, Anthropic, modelli ospitati nel cloud e altri provider. Le distribuzioni in produzione possono inoltre accedere a database, piattaforme di osservabilità, archiviazione cloud e servizi interni.

Gli attaccanti hanno pubblicato le versioni malevole 1.82.7 e 1.82.8 di LiteLLM nel vero progetto PyPI il 24 marzo 2026. Non erano pacchetti imitativi con nomi scritti in modo errato. Sono arrivati attraverso il canale di distribuzione di cui gli utenti già si fidavano.

Wiz ha riferito che le versioni sono apparse intorno alle 8:30 UTC e che PyPI ha messo il progetto in quarantena alle 11:25 UTC. La sua analisi del pacchetto malevolo ha inoltre rilevato LiteLLM nel 36 percento degli ambienti cloud osservati da Wiz.

La versione 1.82.7 attivava il proprio payload quando il software importava il codice proxy di LiteLLM o avviava il proxy. La versione 1.82.8 aggiungeva un file di avvio Python chiamato litellm_init.pth.

Python elabora i file .pth durante l'inizializzazione dell'ambiente site-package. Di conseguenza, il codice malevolo poteva essere eseguito ogni volta che Python si avviava, anche se un'applicazione non importava mai LiteLLM durante quella sessione.

Questo meccanismo ha minato un'assunzione comune sull'esposizione alle dipendenze. Uno sviluppatore non doveva necessariamente avviare un comando palesemente compromesso. L'installazione della versione poteva inserire un hook di esecuzione automatica nell'ambiente.

Il malware cercava poi nella memoria, nelle variabili d'ambiente, nelle directory di configurazione, nella cronologia della shell e nelle comuni posizioni delle credenziali. Cifrava il materiale raccolto prima di inviarlo a un'infrastruttura controllata dagli attaccanti che imitava il dominio legittimo di LiteLLM.

Gli obiettivi dei dati includevano, secondo quanto riportato, credenziali AWS, Google Cloud e Microsoft Azure. Il ladro di dati cercava inoltre token Kubernetes, configurazioni Docker, password di database, wallet di criptovalute, chiavi private e segreti CI/CD.

L'indagine sulla campagna di Datadog raccomanda di trattare qualsiasi sistema che abbia installato le versioni interessate come un'esposizione completa delle credenziali. Questa posizione riflette il comportamento di raccolta del malware, non dimostra che ogni segreto individuato sia giunto a un attaccante.

I manutentori di LiteLLM hanno dichiarato che le versioni compromesse sono state rimosse e le credenziali dei manutentori sono state ruotate. Hanno inoltre affermato che gli utenti delle immagini Docker del proxy non sono stati coinvolti poiché le loro dipendenze erano bloccate a versioni specifiche.

I manutentori hanno coinvolto Mandiant e sospeso le release durante la revisione di repository e sistemi di build. La loro risposta pubblica ha collegato la compromissione della pubblicazione a credenziali esposte durante il precedente incidente Trivy.

Queste misure di contenimento hanno ridotto le nuove infezioni. Non potevano recuperare i dati già trasmessi né invalidare automaticamente ogni credenziale sottratta. La bonifica doveva quindi estendersi ben oltre la disinstallazione del pacchetto.

Il vero avversario è l'automazione affidabile contro l'accesso limitato

Questo incidente contrappone la velocità della distribuzione software automatizzata al principio di sicurezza secondo cui nessuna dipendenza dovrebbe ereditare credenziali senza restrizioni.

Le moderne pipeline di build scaricano codice, strumenti, container e azioni da numerosi progetti esterni. L'automazione rende le release ripetibili, ma ogni dipendenza diventa parte dell'effettivo perimetro di sicurezza dell'organizzazione.

Trivy illustra il problema. È uno scanner di sicurezza usato per trovare vulnerabilità in container e artefatti software. I team spesso concedono agli scanner ampia visibilità perché l'ispezione richiede accesso al codice sorgente, ai registri e agli output di build.

Il 19 marzo, gli attaccanti hanno compromesso parti dell'ecosistema delle release e delle GitHub Actions di Trivy. Datadog ha riferito che componenti malevoli analizzavano la memoria dei runner ospitati da GitHub e cercavano nelle comuni posizioni delle credenziali.

Gli attaccanti sembrano poi aver riutilizzato l'accesso sottratto in altri progetti e sistemi di pacchetti. La campagna ha raggiunto azioni ed estensioni legate a Checkmarx prima che le release malevole di LiteLLM comparissero su PyPI.

Questa sequenza capovolge il consueto modello di sicurezza. Uno scanner concepito per rilevare software non sicuro è diventato una fonte upstream di accesso che ha contribuito a compromettere un altro pacchetto ampiamente utilizzato.

La campagna dimostra inoltre perché il nome firmato o ufficiale di un pacchetto non possa risolvere la questione della fiducia. La pubblicazione autentica nel registro conferma la provenienza di un artefatto. Non garantisce che l'account dell'editore o la pipeline di build siano rimasti sicuri.

Gli aggiornamenti automatici hanno aumentato la tensione. I team spesso consentono alle patch release di essere distribuite rapidamente perché si aspettano che le versioni minori contengano correzioni compatibili. Gli attaccanti hanno sfruttato questa aspettativa pubblicando versioni malevole attraverso un progetto legittimo.

Il blocco delle versioni può rallentare questo percorso, ma non è una difesa completa. Un team può approvare deliberatamente una versione avvelenata, soprattutto quando l'identità del registro e il numero della release sembrano normali.

La verifica degli hash crittografici offre un controllo più forte perché controlla l'artefatto esatto. Tuttavia, qualcuno deve stabilire quale hash sia affidabile prima dell'installazione. Copiare un hash malevolo dallo stesso canale compromesso non fa che preservare l'attacco.

I mirror privati dei pacchetti aggiungono revisione e ritardo prima che gli artefatti esterni raggiungano la produzione. Creano inoltre un altro servizio sensibile che deve essere protetto, monitorato e mantenuto aggiornato.

Il controllo più profondo è l'isolamento delle credenziali. Una dipendenza eseguita in un job di build dovrebbe ricevere solo i permessi necessari per quell'attività specifica. Le credenziali di breve durata dovrebbero scadere prima che le copie sottratte possano fornire un accesso duraturo.

L'identità del carico di lavoro sostituisce i segreti statici con credenziali temporanee collegate a un job o a un servizio. Questo approccio riduce il valore di file e variabili d'ambiente raccolti da un runner compromesso.

Le organizzazioni necessitano inoltre di fasi di build separate. Un job di scansione raramente ha bisogno dell'autorizzazione per pubblicare pacchetti, amministrare account cloud, accedere a database di produzione e modificare repository non correlati.

Molte pipeline combinano ancora questi privilegi per comodità. Quando un processo può raggiungere ogni servizio di deployment, una dipendenza avvelenata può trasformare un aggiornamento software in un incidente di identità che coinvolge l'intera organizzazione.

L'attacco LiteLLM non ha inventato questa debolezza. Ha mostrato quanto la debolezza cresca rapidamente quando il middleware AI si trova tra applicazioni, provider di modelli, cloud, database e sistemi di osservabilità.

Perché disinstallare LiteLLM non era sufficiente

La rimozione del pacchetto dannoso ha interrotto un percorso di esecuzione, ma non ha revocato i segreti copiati mentre quel codice era attivo.

Il furto di credenziali pone un problema di risposta diverso dalla normale bonifica del malware. Una macchina ricostruita può eliminare una backdoor, ma l'attaccante potrebbe comunque disporre di chiavi valide utilizzabili da un altro sistema.

Ogni ambiente interessato richiede un inventario delle credenziali. I team di sicurezza devono identificare quali segreti erano presenti in memoria, nei file, nelle variabili d'ambiente, nelle cronologie della shell e nelle directory montate degli account di servizio durante la finestra di esposizione.

La rotazione dovrebbe includere chiavi di accesso cloud, chiavi dei provider AI, password dei database, token dei repository, chiavi SSH, account di servizio Kubernetes, credenziali dei registri di pacchetti, segreti dei webhook e materiali di firma.

L'ordine è importante. I team dovrebbero prima limitare gli accessi sospetti, preservare le prove e creare identità sostitutive. Possono quindi aggiornare i servizi dipendenti prima di invalidare le credenziali esposte, evitando interruzioni incontrollate.

I log di audit cloud possono rivelare se le chiavi rubate sono state utilizzate da località insolite. Le cronologie dei repository possono mostrare clonazioni inattese, creazione di token, modifiche ai workflow, attività di rilascio o cambiamenti nei permessi.

I manutentori dei pacchetti hanno una responsabilità aggiuntiva. Se un token di pubblicazione era presente su un runner infetto, ogni pacchetto raggiungibile tramite quel token richiede una revisione. Gli attaccanti possono attendere prima di sfruttare l'accesso.

La tecnica di persistenza .pth implica inoltre che i team debbano ispezionare direttamente gli ambienti Python. Disinstallare LiteLLM potrebbe non rimuovere un file di avvio creato indipendentemente in site-packages.

La cronologia pubblica dell'incidente raccomanda di verificare la presenza di litellm_init.pth e di ruotare tutte le credenziali presenti sui sistemi interessati. Identifica inoltre l'endpoint controllato dall'attaccante models.litellm.cloud.

I difensori dovrebbero cercare nei log di rete connessioni verso infrastrutture di comando note. Dovrebbero inoltre esaminare i record dei processi, avvii Python insoliti, creazione di archivi e pod Kubernetes privilegiati inattesi.

Tuttavia, il trascorrere di diversi mesi crea lacune nella visibilità. Periodi di conservazione brevi possono cancellare i record degli endpoint e della rete prima che inizi un'indagine ritardata.

Questa lacuna spiega perché la divulgazione dei dati segnalata è rilevante ora. Un'organizzazione che a marzo non aveva rilevato intrusioni evidenti potrebbe ottenere un nuovo elemento investigativo se il suo dominio compare nel materiale recuperato.

Tuttavia, gli investigatori dovrebbero evitare di considerare lo strumento di ricerca di un ricercatore come l'autorità definitiva. Le corrispondenze di dominio possono derivare da configurazioni pubbliche, codice sorgente clonato, riferimenti a fornitori o elenchi di clienti.

L'errore opposto è altrettanto rischioso. Un'azienda non dovrebbe liquidare una corrispondenza solo perché non riesce a dimostrare immediatamente l'esfiltrazione. Log delle credenziali, record di installazione e file di lock delle dipendenze possono fornire prove più solide.

I team dovrebbero anche ispezionare le installazioni indirette. Uno sviluppatore potrebbe non ricordare di aver selezionato LiteLLM perché un altro framework, uno strumento interno o un ambiente di test ha introdotto il pacchetto.

Le distinte dei componenti software aiutano a tracciare queste relazioni. Una distinta dei componenti registra i componenti e le versioni inclusi in un'applicazione o in un artefatto di build.

Eppure, anche un elenco completo dei componenti non può rivelare quali credenziali fossero visibili durante l'esecuzione. Le prove sulle dipendenze devono essere combinate con record di identità e accesso in fase di esecuzione.

Per gli sviluppatori che devono conservare note investigative, cronologie delle credenziali e decisioni di remediation, una base di conoscenza tecnica ricercabile può ridurre la frammentazione delle prove. I segreti sensibili stessi non dovrebbero mai essere copiati nelle note generiche.

Cosa non dimostrano i numeri

La scala riportata è allarmante, ma le prove disponibili non stabiliscono 2.500 intrusioni di rete completate né 195 TB di credenziali uniche.

Ars Technica attribuisce la nuova portata all'analisi di ricercatori di sicurezza. La compromissione del pacchetto sottostante è supportata in modo indipendente da molteplici indagini tecniche e dalla risposta dei manutentori di LiteLLM.

Il successivo conteggio delle vittime dipende da come i ricercatori hanno associato gli artefatti rubati alle organizzazioni. Le informazioni pubbliche non forniscono ancora dettagli sufficienti per riprodurre ogni corrispondenza o distinguere clienti, fornitori, sviluppatori e terze parti menzionate.

Un dominio aziendale può comparire nel codice sorgente senza dimostrare che quel codice provenisse dal sistema del proprietario del dominio. Fixture di test, indirizzi email, metadati delle dipendenze e documentazione possono tutti contenere nomi esterni.

I ricercatori possono rafforzare l'attribuzione attraverso diversi segnali. Tra questi figurano hostname interni, percorsi di repository privati, identificatori di account cloud, token specifici dell'organizzazione, nomi dei runner e timestamp corrispondenti.

Anche in quel caso, “interessato” può descrivere diverse condizioni. Un'organizzazione potrebbe aver eseguito malware, un'altra potrebbe aver esposto una chiave revocata e una terza potrebbe comparire solo nella documentazione copiata.

Anche la cifra di 434.000 richiede contesto. Se rappresenta file, record o esecuzioni di pipeline, non dovrebbe essere presentata come un numero equivalente di pipeline distinte compromesse.

La raccolta segnalata di 195 TB merita analoga cautela. Un archivio grezzo di dati sottratti può contenere directory ripetute, grandi file binari, file di modelli, cache, repository sorgente e log.

Definire tutti i 195 TB “credenziali” comprime queste distinzioni in un titolo sensazionalistico. Le credenziali occupano poco spazio, mentre gli ambienti che le circondano possono essere enormi.

Il rischio pratico resta serio senza esasperare la formulazione. Un piccolo file di testo contenente una singola chiave attiva di amministratore cloud può contare più di terabyte di artefatti di build non sensibili.

Anche le organizzazioni nominate meritano un trattamento equo. La comparsa in un dataset di esposizione non dimostra negligenza, compromissione in corso o furto di dati dai loro sistemi di produzione.

Alcune organizzazioni elencate potrebbero aver ruotato le credenziali durante la risposta originaria. Altre potrebbero aver fornito nomi o domini comparsi nell'ambiente di un fornitore anziché nel proprio.

Il possesso e l'uso del dataset da parte degli attaccanti restano questioni distinte. Secondo quanto riportato, i ricercatori hanno ottenuto o analizzato materiale collegato alla campagna, ma le prove pubbliche non mostrano quanto estesamente sia stata sfruttata ogni credenziale.

La validità delle credenziali cambia nel tempo. I token temporanei possono scadere in pochi minuti, mentre vecchie chiavi SSH e credenziali API statiche possono rimanere funzionanti per mesi o anni.

L'incertezza più rilevante riguarda i segreti di lunga durata. Se le organizzazioni esposte hanno ruotato solo le chiavi AI più evidenti, gli attaccanti potrebbero conservare l'accesso tramite token di deployment dimenticati o account di servizio.

La divulgazione dovrebbe quindi essere trattata come un elemento investigativo supportato da un evento malware confermato. Non dovrebbe diventare un verdetto finale di violazione per ogni dominio nel dataset.

Questa impostazione equilibrata evita due fallimenti. Impedisce che un conteggio delle vittime esagerato superi le prove e impedisce che l'incertezza diventi una scusa per l'inazione.

Tre segnali indicheranno se la crisi è contenuta

La prossima fase dipende dalla rotazione delle credenziali, da riscontri sulle vittime verificati indipendentemente e da cambiamenti misurabili nella sicurezza della pubblicazione dei pacchetti.

Il primo segnale è la prova di abuso delle credenziali dopo la finestra di contenimento di marzo. I provider cloud, i registri di pacchetti e le organizzazioni interessate dovrebbero comunicare se le identità rubate hanno consentito accessi successivi.

L'uso confermato di token di pubblicazione inattivi rafforzerebbe l'ipotesi che la campagna abbia creato una minaccia di lunga durata per la supply chain. L'assenza di utilizzi osservati ridurrebbe la preoccupazione immediata, ma solo laddove la copertura di audit sia adeguata.

Il secondo segnale è la validazione indipendente del dataset di esposizione. Più organizzazioni dovrebbero confrontare le corrispondenze dei ricercatori con log di installazione, identificatori cloud e telemetria di rete.

Conferme coerenti sosterrebbero la scala riportata. Corrispondenze false diffuse o record duplicati ridurrebbero l'impatto stimato senza modificare la compromissione confermata di LiteLLM.

Il terzo segnale è l'adozione di controlli più sicuri per la pubblicazione e l'esecuzione. Il modello di trusted publishing di PyPI utilizza token di identità a breve durata invece di credenziali di upload riutilizzabili.

La più ampia revisione della supply chain raccomanda trusted publishing, verifica degli hash degli artefatti, account di servizio con permessi limitati e monitoraggio dei file di avvio Python inattesi. Il documento identifica il middleware AI come un punto di concentrazione per le credenziali downstream.

Gli sviluppatori non dovrebbero attendere un elenco perfetto delle vittime. Chiunque abbia installato LiteLLM 1.82.7 o 1.82.8 dovrebbe trattare quell'ambiente come esposto e verificare che ogni credenziale accessibile sia stata modificata.

I team di sicurezza dovrebbero inoltre riesaminare l'esposizione relativa a Trivy dal 19 marzo in poi. La catena della campagna è iniziata prima della comparsa delle versioni dannose di LiteLLM e concentrarsi su un solo pacchetto può far perdere la compromissione a monte.

Le organizzazioni che non trovano versioni interessate dovrebbero comunque esaminare la propria policy sulle dipendenze. Il prossimo pacchetto avvelenato non utilizzerà necessariamente LiteLLM, Python o lo stesso meccanismo di persistenza.

La lezione centrale del rapporto di Ars Technica è più circoscritta e più attuabile di quanto suggeriscano i suoi numeri enormi. L'automazione affidabile ha collocato identità preziose accanto a codice di terze parti e una catena compromessa ha raggiunto molti sistemi.

Ponetevi oggi una domanda concreta: quale pacchetto esterno può leggere le vostre credenziali di build più privilegiate? Se la risposta non è chiara, mappate quell'accesso prima che il prossimo aggiornamento di routine trasformi una fiducia nascosta in un incidente.