La compromissione di LiteLLM 1.107.0 ha diffuso malware per il furto di credenziali
LiteLLM 1.107.0 è stato pubblicato con malware per il furto di credenziali dopo che un autore dell’attacco sconosciuto ha sfruttato una master key precedentemente esposta per assumere il controllo dei repository GitHub del progetto e del suo processo di release. Il package Python compromesso è arrivato sul Python Package Index (PyPI), un servizio usato per distribuire software Python, nonché su Docker Hub e GitHub Container Registry (GHCR) il 21 ottobre 2026.
L’incidente è iniziato il 27 maggio 2026, quando un file di configurazione inserito tramite commit nel repository pubblico LiteLLM-Labs/lite-harness ha esposto la master key di un deployment di LiteLLM Agent Platform. Agent Platform è uno strumento open source utilizzato dal progetto per coordinare agent software. LiteLLM ha dichiarato che l’errore è stato notato rapidamente e che il commit pubblico è stato sovrascritto con un force push. Le credenziali esposte sono state individuate per la revoca, ma la master key stessa non è stata revocata.
Il 10 ottobre, un autore dell’attacco sconosciuto, connesso dall’indirizzo 69.48.229[.]143, ha usato quella key per accedere ad Agent Platform. Da lì, ha ottenuto un OAuth token dell’interfaccia a riga di comando di GitHub, una credenziale digitale che consente a un’applicazione di agire tramite un account GitHub. Il servizio utilizzava questo token per permettere agli agent self-hosted nel cloud di inviare pull request. LiteLLM ha dichiarato che il token non era stato limitato a un insieme ristretto di autorizzazioni e apparteneva a un owner della sua organizzazione GitHub, fornendo all’autore dell’attacco un accesso di livello owner a tutti i suoi repository.
Tra le 22:11 e le 22:12 UTC di quel giorno, l’autore dell’attacco ha creato branch temporanei in BerriAI/litellm e BerriAI/litellm-auto. Alcuni workflow GitHub dannosi, cioè attività automatizzate eseguite all’interno di un repository, sono stati usati per ottenere OAuth token appartenenti a due tecnici con accesso da maintainer. Le credenziali sono state inviate a un indirizzo webhook[.]site controllato dall’autore dell’attacco e le esecuzioni dei workflow sono state eliminate pochi minuti dopo.
Socket ha successivamente recuperato due commit dannosi che collocavano un file nel percorso .github/workflows/cache.yml. Uno è stato creato alle 22:11:45 UTC del 10 ottobre e un altro è seguito il 12 ottobre. Ciascuno utilizzava un branch di breve durata basato su un commit legittimo recente, aggiungeva il workflow con l’oggetto apparentemente innocuo “ci: bump cache config”, veniva eseguito ogni volta che venivano effettuati il push di codice o di un tag e poi eliminava il branch. I nomi dei branch erano ci-tmp-a351cc e ci-tmp-4d8517, lasciando poche tracce visibili nella normale cronologia dei repository.
I workflow hanno raccolto credenziali GitHub, l’identificatore e la signing key di una GitHub App, nonché dati di accesso per Linear, per il deployment di LiteLLM e per Together AI. La versione del 12 ottobre ha esteso la raccolta alle credenziali delle application programming interface (API) di Anthropic, OpenAI, AWS Bedrock, Tavily e GitGuardian. Ha inoltre preso di mira i dati delle sessioni del browser Playwright, i dettagli di connessione del database open source e indirizzi, porte e password di Redis. Socket ha osservato che una sessione Playwright valida poteva fornire accesso all’account Linear associato senza inserire una password né completare l’autenticazione a più fattori. Una credenziale GitGuardian poteva esporre gli avvisi del servizio di scansione dei segreti e, potenzialmente, consentire di controllarli. Le due destinazioni erano webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37 e webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1.
Il 21 ottobre, tra le 10:08 e le 11:08 UTC, l’autore dell’attacco ha aggirato la branch protection, ossia i controlli di GitHub destinati a limitare le modifiche al codice sensibile, e ha modificato la pipeline di release affinché utilizzasse il repository imitazione Berri-AI/litellm anziché BerriAI/litellm. LiteLLM ha dichiarato che, normalmente, le release dovevano essere avviate da un tecnico autorizzato e approvate da un account speciale associato a un dispositivo fisico presente nel suo ufficio. All’inizio di quella settimana, la regola era stata temporaneamente allentata per consentire a due tecnici qualsiasi di avviare e approvare le release. L’autore dell’attacco ha usato un token rubato per avviare la release e un altro per approvarla. Poiché il token di un owner dell’organizzazione era già compromesso, LiteLLM ha affermato che l’autore dell’attacco avrebbe probabilmente potuto rimuovere del tutto la restrizione, ma potrebbe aver evitato di farlo per ridurre il rischio di essere scoperto.
LiteLLM 1.107.0 è stato pubblicato su PyPI tra le 11:39 e le 11:40 UTC. Le immagini di Docker Hub e GHCR sono seguite alle 11:46, mentre i record delle esecuzioni di produzione e staging sono stati eliminati tra le 11:53 e le 11:54. Upwind ha segnalato la supply-chain attack alle 12:06 e PyPI ha messo in quarantena la versione interessata alle 13:23. La timeline di LiteLLM indica che i tag Docker Hub v1.107.0, latest, main-latest e main-stable sono stati rimossi o reindirizzati a immagini verificate come pulite alle 14:20 UTC, sebbene quella riga riporti il 21 ottobre 2025, diversamente dagli eventi circostanti datati 2026.
Diverse indagini hanno rilevato che i file dannosi potevano essere eseguiti ogni volta che Python veniva avviato, anche se un’applicazione non importava mai LiteLLM. Un componente raccoglieva credenziali da strumenti per sviluppatori, servizi di AI, ambienti cloud e browser web. Raccoglieva inoltre dettagli di sistema, file SSH, credenziali Git e GitLab, variabili d’ambiente e token associati a npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems e Cargo. I dati rubati venivano compressi e inviati tramite una richiesta HTTP POST a litellm[.]dev/healthcheck, un dominio registrato il 13 ottobre 2026.
Un secondo componente installava una backdoor destinata ai sistemi Unix, cioè un metodo nascosto per eseguire comandi da remoto, sotto forma di processo in background. Ogni ora contattava l’infrastruttura dell’autore dell’attacco per recuperare ed eseguire codice arbitrario. Microsoft Security Research ha avvertito che file di avvio Python dannosi erano stati collocati al di fuori della directory dell’applicazione LiteLLM, pertanto eliminare soltanto l’applicazione poteva lasciare quei componenti nel sistema.
LiteLLM ha dichiarato di essere impegnata a revocare i token collegati ai suoi sistemi interni e alle piattaforme dei fornitori. La sua indagine ha inoltre escluso una precedente teoria secondo cui gli OAuth token fossero stati prelevati dai log interni di deployment. Per i gestori di siti web e i team IT, il caso dimostra perché, quando si interviene in seguito alla compromissione di un package, sia necessario considerare le dipendenze software, gli account usati per le build e le credenziali dei servizi archiviate. Per le organizzazioni che stanno esaminando questa esposizione più ampia, AEU-I offre servizi IT, infrastrutture e consulenza con la sicurezza come priorità.