Pubblicata su PyPI la release malevola di LiteLLM, poi rimossa

Il 21 ottobre 2026 è comparsa su PyPI la versione malevola litellm==1.107.0. PyPI l’ha rimossa. La 1.106.2 è indicata come sicura¹.

LiteLLM può trovarsi nelle macchine degli sviluppatori anche senza installazione diretta. Molti agent e proxy lo usano per parlare con Claude, GPT e altri modelli tramite un’unica interfaccia¹. Questo amplia l’impatto potenziale di una singola release compromessa.

Il payload cercava credenziali di strumenti usati per il coding con l’AI. Nelle stringhe compaiono nomi come Claude, Cursor, Copilot, Gemini CLI e Codex CLI¹.

È la seconda compromissione del pacchetto nel 2026. Non è collegata all’incidente di marzo, secondo le informazioni disponibili¹. L’autore della sintesi in inglese indica l’analisi di GMO Flatt Security, in giapponese, come la più dettagliata tra quelle pubbliche e la usa come base del riepilogo¹.

Un dettaglio pratico è cruciale: il tag v1.107.0 su GitHub è pulito. I file malevoli compaiono solo nelle wheel caricate su PyPI. Leggere il sorgente non avrebbe aiutato a individuare la modifica¹.

La ricostruzione temporale citata nel post si appoggia all’analisi di Flatt Security e ai metadati delle release PyPI. I tempi sono in UTC¹. Il quadro collega la pubblicazione della versione compromessa e la successiva rimozione dal registro.

Il post aggiunge un’indicazione operativa: come configurare uv e pip per rifiutare release appena pubblicate. L’obiettivo è evitare l’adozione immediata di versioni compromesse e guadagnare tempo per le segnalazioni. L’autore parla di un’impostazione a riga singola che avrebbe fatto saltare l’installazione della 1.107.0¹.

L’effetto a catena nelle dipendenze è concreto. Se costruisci con LLM, è probabile che LiteLLM sia presente in qualche punto della toolchain, anche se non è elencato nei requisiti. Accade perché agent e proxy lo incorporano per uniformare le chiamate ai modelli¹. Una release malevola può quindi entrare in ambienti di sviluppo tramite aggiornamenti ordinari.

Il caso mostra un vettore chiaro: artefatti di distribuzione alterati rispetto al repository del codice. La differenza tra il tag GitHub e le wheel PyPI è il punto che emerge dalle analisi citate¹. In questo scenario, l’audit del sorgente non coincide con l’audit degli artefatti installati.

PyPI ha rimosso la 1.107.0. La 1.106.2 resta l’indicazione sicura per chi usa il pacchetto¹. L’analisi più approfondita, a cura di Flatt Security, è in giapponese. La sintesi in inglese riporta i punti chiave e integra la contromisura per i gestori di pacchetti, centrata sul rifiuto automatico delle versioni “brand-new”¹.

Dal titolo del post arriva una nota operativa sintetica: un controllo da cinque minuti per gli sviluppatori e una singola impostazione avrebbero evitato l’installazione della release compromessa. L’autore suggerisce di applicarla nei template di progetto e nelle configurazioni CI¹.