L’analisi della vulnerabilità CVE-2025-61260 in OpenAI Codex CLI rivela un problema strutturale nella gestione della configurazione locale che consente iniezione comandi, esecuzione codice remoto e compromissione silenziosa dei flussi di sviluppo. La falla riguarda l’esecuzione automatica di voci MCP server definite all’interno dei file di progetto, incluse configurazioni come .env e .codex/config.toml, trattate dal tool come pienamente affidabili. Questo comportamento apre un vettore di attacco semplice ma altamente invasivo, soprattutto nei contesti collaborativi, dove un aggressore può introdurre modifiche malevole attraverso commit, merge o pull request. La ricerca di Check Point Research documenta come la fiducia implicita verso i file locali permetta di ottenere accesso persistente, movimenti laterali, esfiltrazione di credenziali e contaminazione della supply chain software. Il fix nella versione 0.23.0 del CLI introduce restrizioni, validazioni aggiuntive e il blocco dei reindirizzamenti silenziosi attraverso il parametro CODEX_HOME, mitigando un rischio che aveva ripercussioni significative sull’integrità dei sistemi di sviluppo. L’episodio conferma la necessità di trattare gli strumenti AI integrati nei workflow come componenti ad alta criticità, dove anche un singolo file locale può trasformarsi in un punto di compromissione globale.
Cosa leggere
Scoperta della vulnerabilità e dinamiche di fiducia del CLI
La vulnerabilità emerge durante test approfonditi condotti da ricercatori che analizzano il comportamento del CLI nel caricamento delle configurazioni di progetto. L’obiettivo iniziale consiste nel verificare se OpenAI Codex CLI gestisce in sicurezza override ambientali e voci MCP definite nei repository. L’indagine mostra che il tool carica automaticamente file come .env e .codex/config.toml, trattandoli come attendibili senza controlli aggiuntivi. Questa fiducia riguarda la posizione dei file, non il contenuto, generando una condizione pericolosa: tutto ciò che risiede nel repository viene interpretato come materiale autorizzato. Il CLI, all’avvio, risolve le configurazioni, carica i server MCP indicati e li invoca come parte di un flusso di esecuzione ordinario, senza avvisi o conferme. In questo modo un attaccante può introdurre payload in file apparentemente innocui e attivarli nel momento stesso in cui lo sviluppatore lancia il comando “codex”. L’uso di .env per reindirizzare CODEX_HOME alla cartella del repository rappresenta il cuore dell’exploit. Quando questo parametro punta alla directory locale, il CLI attinge alla configurazione malevola definita in config.toml, che contiene una o più voci MCP con comandi arbitrari. Il tool invoca automaticamente tali comandi, generando esecuzione immediata e invisibile. La ricerca evidenzia come l’attacco possa essere orchestrato anche dopo merge ritenuti legittimi, poiché il CLI non verifica cambiamenti né applica valutazioni dinamiche sulla sicurezza. La divulgazione responsabile avviene il 7 agosto 2025, accompagnata da documentazione tecnica utile alla riproduzione del problema, mentre la risposta del team Codex porta al rilascio del fix entro due settimane.
Meccanismo di iniezione comandi e vettore exploit
L’exploit sfrutta un meccanismo semplice ma potente: la risoluzione automatica delle voci mcp_servers definite nella configurazione locale. L’attaccante prepara un repository apparentemente innocuo, usa .env per indirizzare CODEX_HOME verso il path locale e inserisce nel file config.toml un MCP server che invoca comandi arbitrari. Quando lo sviluppatore utilizza il comando Codex, il CLI materializza le voci MCP e le esegue senza alcuna verifica aggiuntiva, permettendo l’attivazione del payload. Il meccanismo permette varie forme di attacco estremamente dannose: apertura di reverse shell, modifica di file locali, creazione di backdoor persistenti, furto di token cloud, sottrazione di chiavi SSH e possibilmente estensione del controllo al sistema operativo. Il problema è aggravato dal fatto che la maggior parte degli sviluppatori non si aspetta che un file di configurazione possa contenere un comando eseguibile automaticamente. La fiducia predefinita del CLI verso tali file diventa quindi un punto di rottura del modello di sicurezza. La semplicità dell’exploit favorisce inoltre la sua propagazione: basta condividere template, progetti open-source, o repository aziendali che includono la configurazione malevola per diffondere il codice dannoso in modo rapido e inconsapevole. La natura testuale dei file coinvolti rende questo vettore ancora più insidioso, poiché non richiede librerie binarie, installazioni o comportamenti sospetti.
Impatto sulla supply chain e sui flussi di sviluppo
L’impatto della vulnerabilità è ampio e coinvolge singoli sviluppatori e interi ecosistemi software. La possibilità di ottenere esecuzione remota silenziosa rende l’attacco difficile da rilevare, perché avviene all’interno di un processo autorizzato. Gli aggressori che ottengono accesso persistente possono esfiltrare dati sensibili, spostarsi lateralmente, compromettere pipeline CI e infettare servizi collegati. Pipeline che ricostruiscono automaticamente il progetto possono eseguire il payload senza intervento umano, amplificando la diffusione del malware. Gli ambienti open-source risultano particolarmente vulnerabili, poiché accettano contributi da un numero elevato di attori e integrano patch tramite procedure automatizzate. La contaminazione dei flussi di sviluppo si espande rapidamente attraverso fork, template condivisi e modelli aziendali riutilizzati. Le aziende che adottano Codex per aumentare produttività e automazione rischiano di vedere compromessi sistemi di sviluppo critici e di dover gestire perdite finanziarie, downtime e possibili data breach regolamentati. Il caso riflette un problema più ampio: la crescente dipendenza da strumenti AI integrati nei workflow aumenta la superficie d’attacco più velocemente dei meccanismi di difesa. La configurazione runtime diventa un vettore strategico e le pipeline CI diventano punti di propagazione automatica del payload. L’assenza di sandboxing dinamico e la fiducia implicita nei repository generano un terreno fertile per attacchi supply chain ad alto impatto.
Risposta di OpenAI e introduzione del fix nella versione 0.23.0
OpenAI riceve la segnalazione il 7 agosto 2025 e avvia immediatamente la revisione del comportamento del tool. Il 20 agosto 2025 viene pubblicata la versione 0.23.0, che introduce modifiche mirate a eliminare il comportamento vulnerabile. Il fix impedisce ai file .env di reindirizzare CODEX_HOME verso directory locali del progetto, interrompendo la catena di exploit. Vengono applicate validazioni aggiuntive sulle voci MCP e viene introdotto un set di default più restrittivi, in cui il caricamento delle configurazioni locali non può avvenire senza controlli appropriati. I test confermano che il fix blocca le principali modalità di attacco: i reindirizzamenti locali non vengono più applicati e i tentativi di manipolare la configurazione non generano esecuzioni automatiche. OpenAI aggiorna la documentazione per segnalare le nuove regole di gestione dei file locali e rafforza le raccomandazioni per l’audit dei progetti. La collaborazione con i ricercatori contribuisce a migliorare trasparenza ed efficacia della mitigazione, mantenendo la flessibilità del modello MCP ma imponendo controlli più robusti. Il caso CVE-2025-61260 rappresenta un passaggio significativo per la sicurezza dei tool AI nello sviluppo. L’episodio ribadisce l’importanza di trattare le configurazioni locali come superfici d’attacco e non come semplici comodità operative. L’evoluzione dell’ecosistema AI richiede che ogni interazione tra tool e repository venga valutata come potenziale vettore di compromissione, soprattutto quando un singolo file può attivare esecuzioni critiche.
