OpenCode e LiteLLM, agenti AI a rischio tra RCE e token GitHub

🛡️ Executive Summary

• OpenCode presenta una vulnerabilità RCE nel processo di autenticazione OAuth dei server MCP remoti su Windows e WSL. La falla, valutata CVSS 9,8 dai ricercatori, è corretta dalla versione 1.18.33 ma non dispone di una CVE.
• LiteLLM conferma la compromissione della release 1.107.0 distribuita attraverso PyPI e Docker il 21 ottobre 2026. Gli aggressori hanno utilizzato tre account GitHub di sviluppatori per modificare la pipeline e pubblicare malware.
• Il progetto LiteLLM sospetta che i token GitHub siano stati sottratti dai log di un gateway AI esposto su Internet. L’ipotesi coinvolge risposte generate tramite Claude Code, ma il vettore iniziale non è ancora confermato.

OpenCode e LiteLLM finiscono al centro di due gravi incidenti di sicurezza che mostrano come gli strumenti di sviluppo basati sull’intelligenza artificiale possano trasformarsi in punti d’ingresso per l’esecuzione di codice malevolo e il furto di credenziali. Nel primo caso, Pillar Security ha scoperto una vulnerabilità che permette a un server Model Context Protocol (MCP) controllato da un aggressore di eseguire comandi sui computer Windows e WSL durante l’autenticazione OAuth di OpenCode. Nel secondo, LiteLLM ha confermato che il 21 ottobre 2026 un attaccante ha manipolato il processo ufficiale di rilascio del progetto, distribuendo su PyPI e Docker una versione contenente uno stealer di credenziali e una backdoor. Le indagini sulla fuga dei token GitHub utilizzati per compromettere la pipeline aprono inoltre un problema specifico: le risposte e i log degli agenti AI possono diventare contenitori di segreti sufficienti a superare i controlli di sicurezza della supply chain.

OpenCode, una falsa autenticazione MCP esegue comandi PowerShell su Windows

La vulnerabilità individuata da Pillar Security interessa le versioni OpenCode dalla 1.0.137 alla 1.18.32 eseguite su Windows e Windows Subsystem for Linux (WSL). Il problema nasce dalla gestione del processo di autenticazione OAuth quando un agente di coding deve collegarsi a un server MCP remoto. Durante questa operazione il server restituisce un documento contenente l’indirizzo authorization_endpoint, utilizzato dal client per aprire la pagina web nella quale l’utente dovrebbe autorizzare la connessione. Il campo può essere controllato dal server remoto e OpenCode, nelle versioni vulnerabili, lo trasmetteva al pacchetto Node.js open, incaricato di avviare il browser. Su Windows, la versione 10.1.2 della dipendenza costruiva un comando PowerShell incorporando l’URL senza neutralizzare correttamente i caratteri speciali. Un indirizzo HTTPS appositamente costruito poteva quindi contenere un’espressione PowerShell eseguita prima ancora che il browser venisse aperto.

Nello studio originale di Pillar Security pubblicato il 19 ottobre i ricercatori dimostrano che la semplice validazione dello schema HTTPS non impediva l’attacco, perché il payload poteva essere contenuto in un URL formalmente valido. Per raggiungere il percorso vulnerabile era necessario che lo sviluppatore avviasse l’autenticazione verso un server MCP malevolo o successivamente compromesso; la sola presenza del server nella configurazione non equivaleva all’esecuzione automatica del codice. Il problema è diverso dalla vulnerabilità di Bifrost AI Gateway che permetteva l’esecuzione di comandi attraverso richieste MCP non autenticate, ma conferma quanto sia delicato il confine tra i servizi remoti e le funzioni locali concesse agli agenti.

Leggi anche: OpenCode Console violata: coinvolto l’1,4% degli utenti con provider esterni

OpenCode corregge la RCE senza CVE: il rischio rimane invisibile agli scanner

Anomaly, società responsabile di OpenCode, ha corretto la vulnerabilità il 28 settembre 2026 attraverso la versione 1.18.33, dopo una segnalazione privata trasmessa dai ricercatori il 29 agosto. La modifica ha aggiornato la dipendenza open alla versione 11.0.4, introducendo una gestione più sicura degli argomenti passati a PowerShell, insieme a controlli supplementari sugli URL utilizzati durante l’autenticazione. La correzione è stata distribuita come intervento di riorganizzazione del codice, senza un security advisory dedicato e senza richiedere un identificativo CVE. Pillar Security assegna alla falla un punteggio CVSS 3.1 proposto di 9,8, ma si tratta di una valutazione dei ricercatori e non di una classificazione associata a un identificativo ufficiale. L’assenza di CVE ha conseguenze pratiche perché gli strumenti di vulnerability management che si basano sui cataloghi pubblici potrebbero non segnalare le installazioni vulnerabili. Secondo Pillar, Anomaly ha considerato i server MCP malevoli esterni al proprio modello di minaccia, pur correggendo il problema. macOS e Linux nativo non risultano interessati da questo specifico percorso di sfruttamento, perché l’apertura del browser non attraversa lo stesso comando PowerShell. Il caso deve inoltre essere mantenuto distinto dalla violazione OpenCode Console comunicata il 17 ottobre, che riguardava chiavi API potenzialmente esposte nel servizio ospitato: non emergono prove di un collegamento tra i due incidenti. Le differenze tecniche richiamano i precedenti attacchi MCP nei quali strumenti e configurazioni potevano trasferire istruzioni o dati oltre i confini di fiducia previsti. La priorità per gli amministratori è quindi verificare direttamente la versione di OpenCode, senza attendere una segnalazione automatica del software di sicurezza.

LiteLLM 1.107.0 compromesso: tre account GitHub usati per pubblicare malware

Il secondo incidente presenta conseguenze più concrete perché la compromissione della supply chain LiteLLM è stata confermata. Il 21 ottobre 2026, gli aggressori hanno utilizzato credenziali associate a tre sviluppatori del progetto per intervenire sulla pipeline ufficiale di pubblicazione e distribuire la versione 1.107.0 contenente un malware. Secondo il rapporto ufficiale di LiteLLM, i pacchetti PyPI compromessi sono rimasti disponibili dalle 11:39 alle 13:23 UTC, mentre le immagini Docker identificate dai tag v1.107.0, latest, main-latest e main-stable sono risultate compromesse tra le 11:46 e le 14:20 UTC. La stessa operazione ha coinvolto immagini distribuite attraverso GitHub Container Registry, successivamente rese indisponibili. La ricostruzione pubblicata dai manutentori indica che un primo tentativo di modificare la pipeline era stato bloccato dalle protezioni del repository, ma uno degli account compromessi apparteneva a un proprietario dell’organizzazione GitHub e disponeva dei permessi necessari per aggirare quei controlli. Un secondo account è stato utilizzato per approvare il rilascio in produzione, mentre un terzo ha contribuito a eliminare le registrazioni delle esecuzioni. Il codice malevolo è stato costruito a partire da un repository controllato dagli attaccanti, Berri-AI/litellm, differente dal repository legittimo BerriAI/litellm per la presenza di un trattino. Il risultato è particolarmente insidioso perché il tag sorgente ufficiale non conteneva i file malevoli, mentre gli artefatti distribuiti attraverso i canali di rilascio autentici risultavano compromessi. Il precedente di marzo 2026, quando TeamPCP aveva introdotto una backdoor nelle release LiteLLM 1.82.7 e 1.82.8, dimostra che il progetto era già stato bersaglio di un attacco alla supply chain. Non esistono tuttavia prove sufficienti per attribuire i due episodi agli stessi responsabili.

Token GitHub nei log LiteLLM: il sospetto riguarda anche le risposte di Claude Code

L’aspetto più delicato riguarda la possibile origine delle credenziali GitHub sottratte. In un aggiornamento dell’indagine pubblicato dai manutentori su GitHub, LiteLLM sostiene di avere osservato situazioni nelle quali Claude Code può inserire il token OAuth di GitHub CLI nella risposta prodotta dall’agente. Quando un gateway conserva il contenuto delle risposte per finalità di diagnostica o monitoraggio, quei token possono quindi essere registrati nei log. Durante le verifiche, gli sviluppatori hanno individuato un account inatteso all’interno di una propria installazione LiteLLM esposta su Internet, avanzando l’ipotesi che l’aggressore abbia ottenuto accesso a quell’ambiente e recuperato dai log le credenziali successivamente utilizzate per manipolare il processo di rilascio. La sequenza rimane un’ipotesi investigativa, perché non è stato ancora dimostrato come l’attaccante sia entrato nel gateway né se l’accesso sia stato ottenuto sfruttando una vulnerabilità recentemente corretta. La comunicazione del progetto non equivale inoltre a una conferma indipendente di Anthropic sulla responsabilità di Claude Code nell’incidente. Rimane però un problema tecnico rilevante: i sistemi di osservabilità delle applicazioni AI possono conservare involontariamente segreti che non dovrebbero comparire nei contenuti delle conversazioni o nelle risposte generate dai tool. Quando il gateway è accessibile da Internet o dispone di controlli insufficienti, i log diventano un deposito di credenziali potenzialmente utilizzabili per accedere a repository, infrastrutture cloud e ambienti di produzione. La questione approfondisce i rischi già evidenziati dall’indagine sui gateway LiteLLM esposti attraverso credenziali amministrative predefinite, ma non dimostra che quella specifica vulnerabilità sia stata sfruttata per compromettere il progetto. Il caso mostra quanto sia importante impedire che token e segreti attraversino indiscriminatamente le risposte degli agenti e i sistemi di logging.

Stealer e backdoor nella release LiteLLM: cosa devono verificare gli amministratori

L’analisi dei pacchetti LiteLLM compromessi ha individuato tre componenti particolarmente pericolosi: cook.pth, cook.py e sitecustomize.py. Il primo utilizza il comportamento standard dell’interprete Python, che elabora i file .pth presenti nelle directory di installazione, per avviare il malware anche quando l’applicazione non importa direttamente LiteLLM. Il secondo componente esegue uno stealer capace di raccogliere password dei browser, chiavi SSH, credenziali AWS, Azure e Google Cloud, token Kubernetes, informazioni CI/CD, variabili d’ambiente e configurazioni degli strumenti AI. Il file sitecustomize.py introduce invece un meccanismo di persistenza e caricamento remoto del codice che, sui sistemi Unix compatibili, può controllare periodicamente un repository GitHub utilizzato come punto di riferimento per individuare il server degli aggressori. Le informazioni sottratte vengono inviate verso un dominio che imita quello del progetto, litellm[.]dev, distinto dall’infrastruttura ufficiale. La rimozione del pacchetto dai repository non elimina automaticamente l’infezione nei sistemi che lo hanno già eseguito, né revoca le credenziali eventualmente copiate. LiteLLM invita pertanto a considerare compromessi gli ambienti nei quali la versione 1.107.0 sia stata eseguita, rimuovere i componenti malevoli prima di avviare nuovamente Python, ricostruire gli ambienti virtuali o i container e utilizzare temporaneamente la versione verificata 1.106.2. La rotazione deve comprendere chiavi dei provider AI, credenziali database, token GitHub, account cloud e segreti accessibili dal sistema coinvolto. Le installazioni enterprise private non risultano interessate secondo il progetto. L’incidente conferma le conseguenze già osservate negli attacchi supply chain che prendono di mira le configurazioni degli agenti AI, i token cloud e le credenziali CI/CD.

Continua con:

GitHub Actions riattiva Mini Shai-Hulud: i tag malevoli erano ancora lì

PixelLeak: agenti AI pubblicano screenshot interni su GitHub

La sicurezza degli agenti AI non dipende soltanto dal modello ma dai privilegi concessi

OpenCode e LiteLLM rappresentano due modalità differenti attraverso le quali la fiducia concessa agli strumenti AI può trasformarsi in un problema di sicurezza infrastrutturale. Nel primo caso, un server MCP esterno controllava un parametro dell’autenticazione OAuth che il client trasferiva impropriamente a una funzione locale capace di eseguire comandi. Nel secondo, credenziali GitHub sottratte hanno consentito di aggirare più livelli di protezione della pipeline, producendo pacchetti malevoli distribuiti da canali ufficiali. Il sospetto che alcuni token fossero stati conservati nei log di un gateway AI aggiunge una terza dimensione, ancora da confermare sul piano forense: l’osservabilità dei modelli e degli agenti può diventare essa stessa una superficie di esposizione dei segreti. Per le organizzazioni italiane che impiegano agenti di coding, server MCP e gateway di accesso ai modelli linguistici, le priorità comprendono la verifica delle versioni OpenCode, l’inventario degli MCP remoti, l’identificazione degli artefatti LiteLLM installati durante la finestra di compromissione e la separazione dei privilegi tra sviluppatori, repository e pipeline di pubblicazione. Altrettanto importante è impedire la registrazione di credenziali nelle risposte degli agenti e applicare controlli di accesso rigorosi ai sistemi di logging. La lezione dei due incidenti non è che gli agenti AI eseguano necessariamente operazioni malevole, ma che dispongono di accessi, credenziali e strumenti sufficientemente potenti da trasformare un errore di validazione o un token sottratto in una compromissione dell’intera infrastruttura software.