Pacchetto LiteLLM su PyPI contenente codice che ruba credenziali

Una versione di LiteLLM su PyPI ha incluso codice malevolo che, in fase di installazione, può rubare credenziali e aprire una backdoor. Basta un pip install per innescarlo¹.

Il meccanismo non aspetta l’import. Può scattare durante la build della source distribution: eseguire setup.py avviene prima di qualsiasi utilizzo del pacchetto. Può scattare all’avvio dell’interprete: un file .pth in site-packages con una riga di import viene caricato a ogni esecuzione di Python, anche con un semplice python -c "print(1)". Può scattare per via indiretta: una dipendenza aggiornata trascina dentro il pacchetto compromesso senza che tu lo installi in modo esplicito¹.

Questi canali colpiscono proprio dove molte pipeline sono più fragili. Esempi comuni: pip install -U litellm dentro un Dockerfile, o requirements.txt senza versioni bloccate. Se qualcuno prende il controllo dell’account che pubblica su PyPI, ottiene esecuzione di codice sui laptop degli sviluppatori, nei runner CI, nei container di produzione. Una sola build può attivare lo script inserito nel pacchetto¹.

La segnalazione su LiteLLM ha acceso un confronto su Hacker News: il rischio è concreto perché l’innesco avviene prima di ogni import e si propaga via dipendenze transitive. Non servono manovre sofisticate sul lato vittima: l’installazione basta a esfiltrare segreti e a preparare accessi futuri. L’interprete Python carica i .pth automaticamente, quindi ogni esecuzione può diventare un punto di persistenza¹.

L’autore della segnalazione non si ferma alla diagnosi. Propone difese pratiche pensate per tagliare gli inneschi nei tre punti critici: build di sdist, esecuzioni all’avvio dell’interprete, aggiornamenti trascinati da altre librerie. L’obiettivo è ridurre la superficie d’attacco e rendere riproduibili gli ambienti di installazione. Le indicazioni arrivano con esempi operativi, comandi e script pronti per essere adottati nei flussi esistenti¹.

Il nodo organizzativo sta nelle abitudini che accettiamo per comodità. Aggiornare “all’ultima” in un Dockerfile senza fissare versioni. Lasciare a pip la scelta della catena di dipendenze. Delegare fiducia agli account PyPI dei maintainer e, per riflesso, a chi può comprometterli. Ogni volta che la pipeline pesca la versione più recente, cedi controllo su cosa gira nei tuoi ambienti e concedi al pacchetto la prima esecuzione di cui ha bisogno¹.

Una misura spesso trascurata è la sorveglianza degli entry point impliciti. Una singola riga in un .pth aggancia ogni processo Python, anche quelli lanciati per un controllo rapido. Capire dove e quando il codice può partire, prima dell’import, permette di posizionare controlli mirati, evitare build non necessarie e limitare le esecuzioni automatiche nei contesti più esposti¹.

Call to action: leggi la segnalazione e applica i check proposti alla tua pipeline. Parti dagli esempi in¹, verifica se buildi sdist, se carichi .pth all’avvio, se aggiorni dipendenze senza bloccarle. Agisci su questi tre punti prima del prossimo deploy¹.