26 marzo 2026 · 6 min lettura
Intelligenza ArtificialeOracle licenzia 18% del personale per finanziare $50 miliardi in AI. In Italia il tribunale di Roma legittima il licenziamento in contesto AI. Cosa significa per chi gestisce infrastruttura in autonomia.
Intelligenza Artificialeduck.ai promette chat AI senza tracciamento: nessun log, nessun IP, accordi con Anthropic e OpenAI. Ma DuckDuckGo ha già tradito questa fiducia una volta.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
La cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe. Il homelab risponde.
Il 24 marzo 2026, due versioni di LiteLLM pubblicate su PyPI contenevano un infostealer a tre stadi. Novantacinque milioni di download mensili, tre ore di esposizione, credenziali cloud e chiavi SSH nel mirino. Il LiteLLM supply chain attack non è l’ennesima storia di maintainer distratto: è la dimostrazione che lo stack AI ha una superficie d’attacco che la maggior parte dei team non ha ancora misurato.
Il 19 marzo, il gruppo TeamPCP — tracciato anche come DeadCatx3, PCPcat e CipherForce — compromette la pipeline CI/CD di Trivy, lo scanner di vulnerabilità open source di Aqua Security. Il bottino è il token PYPI_PUBLISH associato al progetto LiteLLM.
Quattro giorni dopo, Checkmarx individua attività sospetta. Ma è tardi: il 24 marzo alle 10:39 UTC appare litellm 1.82.7 su PyPI. Tredici minuti dopo, 1.82.8. PyPI mette in quarantena entrambe le versioni circa tre ore più tardi. In quella finestra, chiunque abbia eseguito pip install litellm — o aggiornato un progetto con dipendenza non pinnata — ha scaricato il malware.
La scoperta concreta arriva da FutureSearch: un plugin MCP in Cursor scarica litellm come dipendenza transitiva, la macchina esaurisce la RAM per una fork bomb. Qualcuno nota, scava, trova.
Le due versioni usano approcci distinti. La 1.82.7 incorpora il payload dentro proxy_server.py (doppio base64), attivo solo quando viene importato il modulo proxy. La 1.82.8 è più aggressiva: installa litellm_init.pth nella directory site-packages/. I file .pth vengono eseguiti da Python ad ogni avvio dell’interprete, prima di qualsiasi script utente, indipendentemente da qualsiasi import.
Installare il pacchetto era sufficiente per attivare il malware, senza nemmeno eseguire import litellm. — Simon Willison
Cosa viene esfiltrato: credenziali AWS, GCP e Azure, chiavi SSH, wallet crypto (BTC, ETH, SOL, LTC), token API dei principali provider LLM, file .env. Tutto cifrato con AES-256-CBC e RSA 4096-bit prima dell’invio ai domini C2 models.litellm.cloud e checkmarx.zone.
In ambienti Kubernetes, il malware va oltre: deploya pod privilegiati in kube-system (immagine alpine:latest), monta il filesystem host e installa una backdoor persistente in /root/.config/sysmon/sysmon.py con un servizio systemd che contatta il C2 a intervalli di 5-50 minuti. La sicurezza dei pacchetti Python in questi scenari va ben oltre il dependency management. Qui si parla di perimetro.
Il dettaglio più scomodo di tutta la vicenda è che il vettore iniziale è uno strumento di sicurezza. Trivy — lo scanner che milioni di pipeline usano per trovare CVE nelle immagini container — aveva già subito una compromissione nella stessa settimana. Se ti sei perso quella storia, l’avevo analizzata qui: Trivy compromesso due volte in un mese, il guardiano era la vulnerabilità. Non è una coincidenza che TeamPCP abbia scelto proprio quella CI/CD come punto di ingresso.
Il token PYPI_PUBLISH aveva 2FA abilitato sull’account, ma il token stesso non richiedeva 2FA per pubblicare. Un dettaglio di configurazione che ha trasformato una misura di sicurezza in falsa rassicurazione.
Chi ha uno stack con Ollama, LiteLLM e Open WebUI ha esattamente il profilo di rischio più alto: chiavi SSH verso altri server della rete, file .env con API key OpenAI o Anthropic, token cloud da esperimenti, aggiornamenti automatici senza version pinning. Nessun monitoraggio di rete avanzato.
# 1. Controlla la versione installata
pip show litellm
# 2. Cerca la traccia del malware .pth
find / -name "litellm_init.pth" 2>/dev/null
# 3. Verifica la backdoor sysmon
ls ~/.config/sysmon/
# 4. Controlla il servizio di persistenza
systemctl --user list-units | grep sysmon
# 5. Se hai Kubernetes: cerca i pod iniettati
kubectl get pods -A | grep node-setup-
# 6. Versione sicura certificata
pip install "litellm==1.82.6"Se usi Docker ufficiale (ghcr.io/berriai/litellm) o LiteLLM Cloud, non sei colpito. Il vettore è esclusivamente l’installazione PyPI nelle versioni 1.82.7 e 1.82.8.
Wiz Research stima che LiteLLM sia presente nel 36% degli ambienti cloud. Oltre 600 progetti GitHub — tra cui DSPy, CrewAI, MLflow e Harbor — dipendono da LiteLLM senza version pinning. Il blast radius potenziale è significativo, anche se la finestra di tre ore riduce le installazioni umane reali a un sottoinsieme dell’universo CI/CD, bot e mirror che compongono i 95 milioni di download mensili.
Tre ore è un tempo di risposta buono — meglio di SolarWinds, che è rimasto in produzione per mesi. Ma tre ore su un pacchetto con quei numeri di distribuzione rimane una superficie enorme. Il problema strutturale è che secondo i dati PyPI, solo il 17% degli upload include attestazioni di provenance tramite Trusted Publishing o Sigstore. Il restante 83% pubblica senza che nessuno possa verificare autonomamente che il codice firmato corrisponda al repository sorgente.
Il framework SLSA (Supply-chain Levels for Software Artifacts) avrebbe reso questo attacco molto più difficile: con build reproducibili e attestazioni firmate nella CI/CD, un token rubato non sarebbe sufficiente per pubblicare un artefatto che supera la verifica. Non è fantascienza: è la direzione che la Linux Foundation sta finanziando con 12,5 milioni di dollari annunciati il 17 marzo 2026, esattamente una settimana prima dell’attacco.
Sul fronte regolatorio, l’EU Cyber Resilience Act fissa al 11 settembre 2026 la scadenza per il vulnerability reporting obbligatorio. Questo attacco dimostra esattamente il tipo di scenario che la normativa intende coprire: una dipendenza trasversale a migliaia di prodotti commerciali, sfruttata attraverso un vettore nella toolchain di sicurezza.
Chi lavora su tool AI e IDE dovrebbe leggere anche l’analisi delle 24 CVE negli AI IDE: la superficie d’attacco dello stack di sviluppo AI si allarga in più direzioni contemporaneamente, non solo nel runtime.
Il LiteLLM supply chain attack non è un’anomalia: è la conferma che l’infrastruttura AI open source eredita tutti i problemi di sicurezza del software tradizionale, con una scala di distribuzione molto più rapida e una cultura del pinning quasi inesistente. Trivy compromesso come vettore verso LiteLLM è il tipo di catena che nei prossimi mesi vedremo ripetersi.
La risposta non è smettere di usare open source. È smettere di usarlo in modo implicito.
Fonti: LiteLLM Security Update, Wiz Research, Snyk, FutureSearch, Sonatype, Simon Willison