Supply chain software sotto pressione: pacchetti compromessi, disclosure interrotta e aggiornamenti d'emergenza

Un comando banale, pip install, ha attivato un ladro di credenziali dentro LiteLLM 1.107.0. Il pacchetto su PyPI e le immagini Docker contenevano anche un remote access trojan capace di eseguire codice arbitrario. PyPI ha messo in quarantena la release, Docker Hub e GHCR hanno rimosso litellm/litellm:1.107.0. La versione sicura indicata è v1.106.2⁴. Tesi: la supply chain software oggi cede su due fronti collegati. Da un lato, esecuzione di codice non richiesto già in fase di installazione. Dall’altro, disclosure e patch costrette da fughe e tempi compressi, anche per l’uso di modelli AI nella ricerca di falle.

Cosa è accaduto: tre casi che toccano la supply chain

LiteLLM 1.107.0 è uscita compromessa. Il malware ha mirato a credenziali cloud e di servizi AI. Un componente di comando e controllo ha fornito esecuzione remota. I mantenitori di registri hanno reagito rimuovendo pacchetto e immagini. L’indicazione è netta: evitare qualsiasi esecuzione della 1.107.0 e trattare i segreti come compromessi se la release è girata. I tag latest, main-latest e main-stable potevano puntare alla build malevola, altro rischio operativo. Versione consigliata: v1.106.2⁴.

In PHP, due identificativi CVE sono comparsi alle 15:00 UTC di martedì con dettagli errati. I maintainer parlano di “fuga e divulgazione interrotta” e indicano Chainguard come causa del disallineamento. Hanno rilasciato patch d’emergenza poche ore dopo. Nel resoconto tecnico citano i ricercatori di Calif, OpenAI e Wiz. Le tre aziende affermano di aver usato modelli di intelligenza artificiale nelle attività tra agosto e settembre. I due CVE, ribattezzati PHP2shell, consentono esecuzione di codice da remoto senza autenticazione su server che eseguono PHP. L’impatto è ampio, dato l’uso diffuso di PHP sul web pubblico².

Python ha pubblicato release di sicurezza 3.15.1, 3.14.9 e 3.13.17. Tutte aggiornano l’installer pip alla 26.2.2 con il pacchetto certifi 2026.10.19, per gestire l’incidente sui certificati della CA eMudhra, emSign. Il team definisce 3.15 e 3.14 “expedited security releases” e indica lo stesso intervento su tutti i rami. Per 3.13 arriva una “special security release” che include pip, eccezione rispetto alla prassi. C’è un’istruzione operativa: aggiornare pip e uv all’ultima versione in tutti i virtualenv presenti sul sistema³.

Vettori tecnici e punto di rottura nelle pipeline

I pacchetti Python possono eseguire codice prima di ogni import. Accade durante la build della source distribution, quando setup.py gira. Accade anche all’avvio dell’interprete, se un file .pth in site-packages contiene un import. Questi meccanismi scattano con un semplice python -c "print(1)". Esiste poi la via indiretta: una dipendenza aggiornata trascina dentro il pacchetto compromesso. Questi canali colpiscono Dockerfile con pip install -U e requirements.txt senza versioni bloccate¹.

LiteLLM aggiunge indicatori concreti. File che iniziano con /tmp/.pc_once_ attestano l’esfiltrazione. La presenza di /tmp/remote_code_loader.lock indica che il componente di comando e controllo ha girato o sta ancora girando. La compromissione può quindi persistere nei container e negli ambienti in cui la release è passata. Anche l’uso di tag generici come latest aumenta la superficie, perché un tag può puntare a una build malevola senza che chi esegue se ne accorga⁴.

Sul fronte delle disclosure, il punto di rottura è temporale e comunicativo. L’emersione anticipata degli identificativi CVE, con dettagli non corretti, ha forzato patch d’emergenza su PHP e ha rotto il coordinamento con ricercatori e vendor. Qui l’accelerazione della ricerca con AI convive con la fragilità del calendario di rilascio e delle finestre di mitigazione².

Impatto operativo: da sviluppatori a produzione

La superficie d’attacco entra nelle pratiche quotidiane. Un’unica build può attivare il payload. Se qualcuno prende il controllo del pacchetto pubblicato o ne modifica la distribuzione, ottiene esecuzione di codice su laptop degli sviluppatori, runner CI e container di produzione. Non serve importare il modulo. Basta la fase di installazione o l’avvio dell’interprete¹.

Nel caso LiteLLM, l’effetto a catena tocca gestione dei segreti e continuità dei servizi. La raccomandazione è di trattare come compromessi i segreti presenti nei sistemi che hanno eseguito la 1.107.0. Gli indicatori su /tmp aiutano a scegliere dove indagare per primi. Ma l’effetto operativo è più ampio: ripristini di ambienti, revisione di immagini base e pipeline CI che hanno usato tag ampi come latest⁴.

Le release di sicurezza di Python hanno un obiettivo definito: aggiornare pip e il bundle dei certificati per gestire l’incidente legato a eMudhra, emSign. Il team parla di “expedited security releases” per 3.15 e 3.14, e di una “special security release” per 3.13. Chiede di aggiornare pip e uv in tutti i virtualenv esistenti³.

La disclosure di PHP2shell mette pressione in senso opposto. La fuga alle 15:00 UTC ha anticipato il dibattito pubblico rispetto alle patch, ha introdotto informazioni errate e ha rotto il coordinamento. I maintainer hanno spinto patch d’emergenza, mentre i ricercatori citati segnalano l’uso di modelli di intelligenza artificiale nella fase di scoperta. La velocità della ricerca non elimina la necessità di finestre protette di correzione e di comunicazione accurata².

Misure pratiche e priorità per mantenitori e team operativi

Due priorità, una tecnica e una di processo.

Sul piano tecnico:

• Evitare qualsiasi esecuzione di LiteLLM 1.107.0. Usare v1.106.2 indicata come sicura⁴.
• Bloccare le versioni nelle dipendenze. Evitare -U in Dockerfile e tag generici come latest, main-latest, main-stable. Così si riduce il rischio di importare build malevole per via indiretta^1,4.
• Cercare indicatori nei sistemi esposti: file in /tmp con prefisso .pc_once_ e il lock /tmp/remote_code_loader.lock. Trattare le macchine che li espongono come compromesse⁴.
• Applicare le security release Python. Portare pip alla 26.2.2 e certifi 2026.10.19. Aggiornare pip e uv in tutti i virtualenv come richiesto dal team³.

Sul piano del processo:

• Rafforzare la disclosure coordinata. Il caso PHP2shell mostra come identificativi CVE con dettagli errati e diffusi in anticipo possano forzare patch non pianificate e complicare le mitigazioni sul campo. Serve allineare relazioni tra progetto, ricercatori e soggetti che comunicano al pubblico².
• Mappare dove l’esecuzione automatica può scattare. Build di source distribution.pth caricati all’avvio, dipendenze aggiornate senza pin. Questi punti sono criticità note che vanno presidiate con controlli, policy di pubblicazione e revisione delle pipeline¹.

Questi tre incidenti mostrano due snodi comuni: il confine poroso tra installazione e esecuzione, e l’effetto domino di informazioni premature o strumenti in fase di correzione. Se la filiera resta così tesa, l’unico margine è ridurre l’autonomia delle dipendenze e aumentare quella dei processi di disclosure, prima che il prossimo pip install diventi di nuovo un punto di ingresso^1,2,3,4.