La risposta in breve
Il MCP Gateway ContextForge di IBM ha una falla di esecuzione di codice da remoto di gravità massima — CVE-2026-53710, CVSS 10.0 — che consente a un attaccante non autenticato di evadere dalla sua sandbox Python ed eseguire comandi OS. Il python_sandbox_server del gateway esegue codice Python non fidato in RestrictedPython ma non protegge l'accesso agli attributi; abusando del builtin getattr, un attaccante risale da oggetti consentiti a oggetti pericolosi come subprocess.Popen ed esegue comandi shell sull'host. Ogni versione precedente alla 1.0.2 è interessata, e la correzione è nella 1.0.2. Poiché un gateway MCP media l'accesso di un modello linguistico a strumenti, dati e credenziali, l'esecuzione di codice lì è un punto d'appoggio verso tutto ciò che si trova a valle. Se gestisci questo gateway — ed è parte della tua infrastruttura di agenti IA —, aggiorna ora.
Nessun exploit pubblico è stato segnalato alla data di divulgazione, il 15 settembre 2026. È al tempo stesso la buona notizia e la scadenza: un bug remoto, pre-autenticazione, con esecuzione completa di comandi è esattamente ciò che viene trasformato rapidamente in arma non appena una proof of concept circola. Applica la patch alla 1.0.2 come modifica d'emergenza, isola il gateway dalle reti non fidate e ruota tutte le credenziali che custodisce per gli strumenti a valle.
Che cos'è la CVE-2026-53710?
Il Model Context Protocol (MCP) è diventato il cablaggio comune degli agenti IA: standardizza il modo in cui un modello linguistico scopre e richiama strumenti, fonti dati e API esterne. Un gateway MCP è il middleware che si colloca davanti a queste connessioni — instrada le richieste, applica le policy e custodisce le credenziali di cui ogni strumento ha bisogno. Il ContextForge MCP Gateway di IBM è un'implementazione open source ampiamente utilizzata, pubblicata come pacchetto mcp-contextforge-gateway e sviluppata nel progetto pubblico IBM/mcp-context-forge.
Il 15 settembre 2026, in quel gateway è stata divulgata una vulnerabilità di gravità massima con la sigla CVE-2026-53710, valutata CVSS 10.0. Risiede nel python_sandbox_server del gateway — un componente che esegue codice Python fornito dall'utente o dal modello in una sandbox RestrictedPython, il cui intero scopo è far girare codice potenzialmente non fidato senza toccare l'host. Il difetto è che la sandbox non applica i controlli necessari sull'accesso agli attributi. Un attaccante può usare il builtin getattr per raggiungere oggetti e metodi che la sandbox avrebbe dovuto tenere off-limits — in ultima analisi subprocess.Popen — e da lì eseguire comandi arbitrari del sistema operativo. Non è richiesto alcun login, e il risultato è il controllo completo dell'host del gateway. Chiunque gestisca questo componente dovrebbe trattarne l'hardening come lavoro centrale di infrastruttura di agenti IA.
Ogni versione del ContextForge MCP Gateway precedente alla 1.0.2 è interessata; la correzione è arrivata nella 1.0.2, che ripristina le restrizioni sull'accesso agli attributi mancanti. Alla data di divulgazione non esiste alcun exploit proof-of-concept pubblico né sfruttamento confermato in the wild — ma con un percorso remoto e non autenticato che porta direttamente all'esecuzione di comandi, quel divario è un conto alla rovescia, non una consolazione.
Come funziona l'evasione dalla sandbox
Le sandbox a livello di linguaggio come RestrictedPython funzionano compilando il codice rispetto a un insieme limitato di builtin consentiti e bloccando le operazioni palesemente pericolose — import, accesso diretto agli attributi dunder e simili. La sicurezza dipende dal controllo, da parte della sandbox, di ogni percorso attraverso cui il codice può raggiungere un oggetto potente. L'accesso agli attributi è uno di questi percorsi, ed è notoriamente difficile da blindare completamente, perché Python consente di recuperare gli attributi in modo dinamico.
È questa la crepa sfruttata dalla CVE-2026-53710. Il builtin getattr risolve un attributo per nome a runtime, così che anche se la sintassi letterale per raggiungere un attributo pericoloso è bloccata, getattr(obj, "name") può recuperarlo come una ricerca su stringa che la sandbox non intercetta. Concatenando queste ricerche, un attaccante si sposta da un oggetto di partenza innocuo alle interne dei moduli e infine a subprocess.Popen, che avvia un vero processo OS. Poiché il python_sandbox_server espone tutto ciò sulla rete senza autenticazione, l'intera sequenza parte da una singola richiesta non autenticata — e viene eseguita con i privilegi del processo del gateway.
Ciò che ne fa una CVSS 10.0 anziché un bug soltanto serio è la combinazione e la collocazione. È remoto, non richiede credenziali e non richiede interazione utente, quindi è banale da automatizzare su larga scala. E colpisce proprio il componente il cui compito è eseguire in sicurezza codice non fidato: quando una sandbox si rompe, crolla l'assunto che rendeva accettabile l'esecuzione di quel codice — «è contenuto». Un gateway non è nemmeno un nodo foglia: custodisce le chiavi e le connessioni verso tutto ciò per cui l'agente è stato cablato.
Cosa significa per i team software in Italia
Togliete il numero di CVE e restano tre lezioni durature. Primo, il vostro gateway MCP è infrastruttura di produzione, non codice di collegamento. I team ne avviano uno durante un proof-of-concept di agenti, ci collegano una dozzina di strumenti con le relative credenziali e non gli assegnano mai il threat model che darebbero a un'API pubblica. Eppure si colloca tra il modello e i vostri sistemi e custodisce le credenziali di entrambi. Merita la stessa urgenza di patch, segmentazione di rete e autenticazione del vostro perimetro.
Secondo, una sandbox di linguaggio non è un confine di sicurezza su cui appoggiarsi da solo. RestrictedPython e i suoi simili sono utili, ma la loro storia è un gocciolio costante di evasioni esattamente come questa — trucchi sull'accesso agli attributi, riderivazione dei builtin, traversamento dei dunder. Se dovete eseguire codice non fidato o generato da un modello, avvolgete la sandbox di linguaggio in un vero isolamento a livello OS: un container blindato, filtri seccomp, gVisor o una microVM, senza rete o credenziali ambientali. La difesa in profondità significa che un singolo bug della sandbox non diventa una compromissione dell'host.
Cosa significa per il mercato italiano. In Italia l'adozione di agenti IA in produzione è cresciuta di pari passo con i progetti di transizione digitale della PA e delle imprese, spesso con team snelli. Il punto cieco ricorrente è lo stesso: il gateway MCP nato per un POC resta in servizio senza il trattamento riservato a un asset di produzione, pur concentrando credenziali e accessi di rete.
Terzo, l'infrastruttura di agenti concentra il raggio d'impatto, perciò il privilegio minimo è il controllo che ripaga. L'esecuzione di codice su un gateway è pericolosa in proporzione a ciò che il gateway può raggiungere. Se gira con credenziali ampie e accesso di rete piatto verso i vostri database e le API interne, un bug è una violazione di tutto; se ogni connettore di strumento ha credenziali dal perimetro stretto e rotabili e il gateway è segmentato, lo stesso bug è contenuto. Per i team in Italia, una RCE non autenticata su un sistema che media l'accesso a dati personali o finanziari chiama in causa il GDPR (sotto la vigilanza del Garante per la protezione dei dati personali), la direttiva NIS2 come recepita in Italia con il D.lgs. 138/2024 (con l'ACN, l'Agenzia per la Cybersicurezza Nazionale, quale autorità competente) e, per i soggetti finanziari, le aspettative di DORA su rimedio rapido e rischio della catena di fornitura ICT. Applicare la patch in poche ore — ed essere in grado di dimostrarlo — è l'investimento a più alta leva.
Cosa fare ora
- Aggiornare subito alla 1.0.2. Portate qualsiasi ContextForge MCP Gateway su una versione precedente alla 1.0.2 alla 1.0.2 o successiva — sia auto-ospitato dai sorgenti sia installato tramite il pacchetto
mcp-contextforge-gateway. Trattatelo come una modifica d'emergenza, non come manutenzione di routine. - Isolare il gateway se non potete applicare subito la patch. Limitate l'accesso di rete affinché solo chiamanti fidati possano raggiungerlo, e disabilitate la funzione di esecuzione di codice del
python_sandbox_serverse non ne fate uso. Rimuovere la raggiungibilità non fidata neutralizza il percorso remoto. - Ruotare le credenziali che media. Il gateway custodisce i segreti degli strumenti e delle API a valle che i vostri agenti richiamano. Se era raggiungibile da reti non fidate, presumete l'esposizione e ruotate quelle credenziali di strumenti, token e chiavi — applicare la patch non annulla ciò che potrebbe essere già trapelato.
- Aggiungere un isolamento a livello OS attorno al codice non fidato. Non lasciate che una sandbox di linguaggio sia l'unica cosa tra il codice generato dal modello e il vostro host. Eseguite il server della sandbox in un container blindato o una microVM con seccomp, capability rimosse e senza credenziali o rete ambientali.
- Includere l'infrastruttura di agenti e MCP nel perimetro dei test. Gateway, connettori di strumenti e le credenziali sottostanti sono regolarmente lasciati fuori dalle revisioni di sicurezza. Includeteli nel vostro prossimo penetration test e audit di sicurezza, e censite quali sistemi interni ciascun connettore può realmente raggiungere.
Domande frequenti
Che cos'è la CVE-2026-53710 nel gateway MCP di IBM?
È una vulnerabilità di gravità massima (CVSS 10.0) nel MCP Gateway ContextForge di IBM, il gateway Model Context Protocol open source distribuito come mcp-contextforge-gateway. Il suo python_sandbox_server esegue codice in una sandbox RestrictedPython ma non protegge l'accesso agli attributi. Abusando del builtin getattr, un attaccante raggiunge funzioni come subprocess.Popen ed esegue comandi OS senza autenticazione, ottenendo il controllo completo dell'host del gateway.
Quali versioni sono interessate e qual è la correzione?
Tutte le versioni precedenti alla 1.0.2 sono interessate; la correzione è nella 1.0.2, che ripristina le restrizioni sull'accesso agli attributi mancanti. Aggiornate qualsiasi gateway — auto-ospitato o installato tramite il pacchetto pip — alla 1.0.2 o successiva immediatamente. Se non potete aggiornare subito, disabilitate o isolate a livello di rete la funzione python_sandbox_server e limitate chi può raggiungere il gateway.
È sfruttata in the wild?
Alla data di divulgazione, il 15 settembre 2026, non è stato segnalato alcun exploit pubblico né sfruttamento confermato in the wild. Dato il profilo — remoto, non autenticato, esecuzione completa di comandi — non è un motivo per attendere. Bug come questo vengono trasformati rapidamente in arma non appena compare una proof of concept, quindi applicate la patch in modo preventivo.
Perché un bypass della sandbox in un gateway è così grave?
Un gateway MCP media l'accesso di un modello a strumenti, dati e API interne, e custodisce le credenziali di questi sistemi. L'esecuzione di codice sul gateway è quindi un punto d'appoggio verso tutto ciò che può raggiungere — non una compromissione isolata dell'host. La sandbox esisteva per contenere in sicurezza codice non fidato generato dal modello; quando cede, quella garanzia di contenimento svanisce.
Come mettere in sicurezza l'infrastruttura MCP e degli agenti nel lungo periodo?
Trattate il gateway come infrastruttura di produzione: applicate le patch in fretta, mettetelo dietro autenticazione, tenetelo fuori dalle reti non fidate ed eseguitelo con credenziali a privilegio minimo, rotabili per ogni strumento. Non affidatevi a una sandbox di linguaggio da sola — aggiungete un isolamento a livello OS come container, seccomp o microVM attorno al codice non fidato. E includete il gateway e i suoi connettori nei test di sicurezza regolari, poiché spesso sono fuori perimetro.
Fonti
GitHub Advisory Database — GHSA-xm98-3vcf-fph7: RestrictedPython sandbox bypass via getattr in python_sandbox_server (CVE-2026-53710)
NVD — CVE-2026-53710
IBM — ContextForge MCP Gateway security advisories