LiteLLM: master key esposta su GitHub ha innescato l'attacco supply chain
Testo scritto con l’intelligenza artificiale a partire da una fonte citata, senza revisione umana prima della pubblicazione.
Una chiave commitata pubblicamente il 27 maggio è stata usata il 10 ottobre per pubblicare su PyPI la release trojanizzata 1.107.0, scaricata circa 49.000 volte in meno di due ore.
Una master key finita per errore su GitHub il 27 maggio ha aperto la strada all’attacco supply chain contro LiteLLM: “mercoledì” scorso è comparsa su PyPI la release 1.107.0 avvelenata1.
LiteLLM attribuisce l’incidente a quella singola credenziale non revocata. La chiave stava in un file di configurazione committato nel repository pubblico LiteLLM-Labs/lite-harness. Gli sviluppatori hanno rimosso presto il commit, ma non hanno invalidato la chiave1.
Il pacchetto 1.107.0 portava due componenti malevoli: un infostealer e un trojan di accesso remoto, capaci di eseguire codice arbitrario sulle macchine che installavano la libreria. La pubblicazione è avvenuta su PyPI e nei registri di container. PyPI ha messo in quarantena la versione compromessa in meno di due ore. In quel tempo i download hanno raggiunto circa 49.000, stima di Wiz1.
La timeline, ricostruita da LiteLLM, è compatta. 27 maggio: comparsa della master key nel repository pubblico. Rimozione rapida del commit, senza revoca della chiave. 10 ottobre: uso della chiave per ottenere accesso alla LiteLLM Agent Platform. “Mercoledì” seguente: caricamento su PyPI e nei registri di container della release 1.107.0 trojanizzata, poi quarantena entro due ore e circa 49.000 download nel frattempo1.
LiteLLM collega l’intera catena a quella chiave. Specifica che apparteneva a uno strumento open source usato internamente per orchestrare agenti di AI. Da quell’accesso l’attore ha potuto spingere la versione 1.107.0 compromessa nei canali di distribuzione pubblici1.
Il nodo tecnico è chiaro: una credenziale rimasta valida ha permesso l’accesso alla piattaforma e la pubblicazione della release avvelenata. Il rischio pratico discende dai due payload, infostealer e RAT, e dalla possibilità di esecuzione di codice sui sistemi che hanno installato la libreria nel breve intervallo prima della quarantena1.
Restano zone d’ombra che la nota non copre. La comunicazione pubblica non indica l’identità dell’attore, non dettaglia quali registri di container siano coinvolti né quanti ambienti abbiano caricato l’immagine compromessa. Non chiarisce l’impatto sui clienti e i passi successivi oltre alla quarantena su PyPI. La ricostruzione mette però a fuoco un punto: una chiave esposta e non invalidata può trasformarsi, anche mesi dopo, in un vettore per l’avvelenamento della supply chain software1.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Fedeltà alle fonti. Un secondo passaggio toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9/10.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 8,0/10 dopo 1 revisione.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Il filo della storia
- LiteLLM 1.107.0 distribuita con malware che ruba credenziali
- Questo articolo
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.