Il ricercatore rivela la stessa vulnerabilità MCP in Google, JPMorgan e due governi

Il ricercatore indipendente di sicurezza Syed Anas Mohiuddin ha divulgato in un aggiornamento di ricerca di ottobre 2026 che lo stesso errore di server-side request forgery nei server Model Context Protocol è stato confermato e corretto dai team di sicurezza di cinque organizzazioni non correlate: Google, JPMorgan Chase, Weaviate, la direzione digitale interministeriale della Francia e il governo della città di Tangerang in Indonesia.

L’aggiornamento, intitolato “Protocol Pivoting, four months later”, verifica una previsione fatta da Mohiuddin a maggio 2026: se la vulnerabilità fosse strutturale anziché il risultato di una singola implementazione negligente, lo stesso bug si manifesterebbe nei server scritti da team che non condividono codice, settore, paese o proprietario. Egli riferisce che ciascuna delle cinque organizzazioni ha confermato il caso tramite il proprio team di sicurezza e che il fornitore di sicurezza Rapid7 ha pubblicato separatamente una CVE per un bug diverso ma correlato. L’aggiornamento conta cinque organizzazioni che hanno corretto lo stesso SSRF, due hanno pubblicato CVE e cinque rilevamenti nei server MCP federali statunitensi rimangono aperti.

Mohiuddin descrive due modalità di errore alla base del modello. La prima è il server-side request forgery: un server MCP genera una richiesta in uscita a partire da un URL, percorso o endpoint fornito da un agente senza verificare dove venga risolto, così l’agente decide effettivamente a cosa si connetta l’identità di rete del server. La seconda è la gestione non sicura dei dati a monte, più visibilmente la scrittura delle risposte complete delle API a monte nei log centralizzati senza redazione, errore che può essere scatenato da normali fault. Egli ricade su un’unica supposizione, che i dati che attraversano il confine MCP siano considerati attendibili perché provengono dall’interno del sistema, ipotesi che, a suo avviso, non regga in una pipeline agentica.

CVE-2026-14540 nel MCP Toolbox di Google

Secondo la GitHub voce del Database Advisory per CVE-2026-14540, pubblicata dal National Vulnerability Database, esiste una vulnerabilità SSRF nei componenti generici di origine HTTP e degli strumenti di Google mcp-toolbox dalle versioni 0.3.0 a 1.4.0. Poiché il client HTTP non disponeva di una politica restrittiva di redirect e non validava mai gli indirizzi IP di destinazione, un parametro di percorso manipolato poteva reindirizzare le richieste in uscita del toolbox verso endpoint interni o esterni arbitrari. L’advisory classifica la vulnerabilità come di gravità Alta con un punteggio CVSS di 8.0; è stata pubblicata il 31 luglio 2026 e aggiornata l’8 agosto 2026. Mohiuddin dichiara che la CVE è stata riservata il 3 luglio 2026 e che il record lo accredita come scopritore.

Google ha integrato la correzione, pull request #3448 nel repository googleapis/mcp-toolbox, il 18 giugno 2026, e l’ha rilasciata in mcp-toolbox v1.5.0. La pull request implementa un SSRFGuard per prevenire attacchi di DNS-rebinding nella finestra tra il controllo dell’indirizzo e la connessione, aggiunge le proprietà configurabili allowPrivateNetworks, allowedIpRanges e customBlockedIpRanges, valida il BaseURL configurato all’inizializzazione anziché alla prima richiesta, e avvisa esplicitamente del rischio di man‑in‑the‑middle quando la verifica SSL è disabilitata. Il PR accredita Mohiuddin come segnalatore, e Mohiuddin descrive la rimedio di Google come un’implementazione di riferimento di un vero guard SSRF.

Altri quattro casi confermati

Mohiuddin riferisce che il repository open‑source jpmorgan-payments/ai di JPMorgan Chase include un server MCP di ricerca documentazione il cui strumento read_documentation applica una whitelist di domini prima del recupero, mentre lo strumento correlato related() recupera un URL fornito dal chiamante lato server senza alcuna restrizione. Egli afferma che il componente è stato forkato da un progetto AWS il cui originale non dereferenziava mai l’URL del chiamante, che il team di Responsible Disclosure della banca ha confermato la vulnerabilità come valida, e che è stata distribuita una correzione. È elencato per nome nella pagina pubblica di riconoscimento del responsible‑disclosure di JPMorgan Chase e valuta la vulnerabilità come di gravità media, osservando che nessuna credenziale viaggia con la richiesta falsificata.

Weaviate, secondo il suo rapporto, ha integrato una pull request che limita le impostazioni apiEndpoint, region e location del modulo Google agli host delle API Google, e lo elenca per nome nella sua voce pubblica della Security Hall of Fame datata 25 agosto 2026.

Il progetto datagouv/datagouv-mcp ha integrato pull request #126, “feat: harden SSRF on external APIs”, il 4 settembre 2026, e la pull request inizia accreditando Mohiuddin come segnalatore. Secondo la PR, un campo machinedocumentazioneurl fornito da qualsiasi produttore registrato su data.gouv.fr veniva recuperato lato server e poteva puntare a indirizzi di loopback, rete privata o metadati cloud, con il DNS‑rebinding in grado di scambiare il target tra il controllo e la connessione e un redirect 302 capace di atterrare su un host interno. La correzione valida l’IP di destinazione al momento della connessione, ricontrolla ogni salto di redirect e rifiuta i proxy. Mohiuddin identifica il progetto come il server MCP ufficiale per la piattaforma nazionale di open‑data della Francia, mantenuto da DINUM, la direzione digitale interministeriale del governo.

Un Avviso di sicurezza GitHub pubblicato 3 settembre 2026 dai manutentori di INFOKOM-KI/Wazuh-MCP-Server, classificato Alto, registra che lo strumento blueteamcheckwebshell, la cui protezione SSRF pubblicizzata rifiutava solo indirizzi IP letterali e non risolveva mai i nomi host, consentiva il bypass a qualsiasi nome DNS che puntasse a un indirizzo privato, di loopback o link‑local, inclusi i metadati di istanze cloud. L’avviso osserva che la garanzia documentata dello strumento, “SSRF Protection: Private/reserved IPs in the URL host are rejected”, non valeva per gli URL basati su nomi host. La vulnerabilità è stata corretta nel commit 2bbfe12 e l’avviso accredita Mohiuddin come segnalatore. Mohiuddin dichiara di averla segnalata il 2 settembre 2026, che i manutentori hanno risposto da un indirizzo tangerangkota.go.id e che il progetto è gestito dal governo della città di Tangerang in Indonesia.

Rapid7’s voce del database delle vulnerabilità per CVE-2026-97228 registra un’iniezione di query GraphQL nelle versioni 0.2.5‑0.6.1 di Rapid7 Bulk Export MCP, in cui un exportargomento id dello strumento MCP di esportazione non convalidato viene interpolato direttamente in una query GraphQL. Rapid7 le assegna un punteggio 2.7, Basso, sulla scala CVSS 3.1, ha pubblicato la voce il 25 settembre 2026 e osserva che le query iniettate vengono eseguite all’interno dell’ambito API dell’operatore e non possono attraversare il confine di un tenant; la versione 0.6.2 risolve il problema passando exportid come variabile parametrizzata. Mohiuddin afferma che Rapid7 lo ha accreditato come scopritore.

Oltre a questi casi, Mohiuddin riferisce che, a partire dall’aggiornamento, 16 avvisi di sicurezza GitHub pubblicati dai manutentori dei progetti lo accreditano come segnalatore, coprendo SSRF così come injection di comandi, lacune di autenticazione, dirottamento di sessione, perdite di credenziali e aggirati di correzioni precedenti, e che ha avuto correzioni integrate in progetti tra cui github-mcp-server, mongodb-mcp-server e salesforce-mcp-server.

Rilevazioni governative non risolte

Mohiuddin riferisce di aver presentato cinque segnalazioni come avvisi di sicurezza GitHub privati il 2 settembre 2026, riguardanti server MCP sotto i Technology Transformation Services della GSA: un server di richieste di benefici del Department of Veterans Affairs, un server CMS Blue Button, un server regulations.gov, un server USASpending e un server CDC PLACES. Dichiarando che tutti e cinque rimangono in fase di triage, non sono stati corretti e non sono presentati come risultati confermati.

Nel caso del VA, che descrive solo a livello di classe, il server registra l’intero corpo dell’errore dell’API dei benefici a livello ERROR senza redazione; tali corpi possono contenere il nome di un veterano, il numero di previdenza sociale, la data di nascita e l’indirizzo, e afferma che i normali fallimenti di validazione sono sufficienti a innescare la registrazione durante il normale funzionamento. Sta trattenendo i dettagli a livello di codice fino a quando i server non saranno corretti.

Riporta inoltre che il 1 settembre 2026 ha notificato a JPCERT che il jgrants-mcp-server dell’Agenzia Digitale del Giappone non aveva autenticazione, e il 7 settembre 2026 ha aperto una pull request pubblica che richiedeva un esplicito opt‑in per collegare il server a qualcosa di diverso dal loopback e limitare la dimensione di scrittura degli allegati. La pull request non è stata fusa e non la presenta come risultato confermato.

Protocol Pivoting e il talk MCPCon

Mohiuddin definisce il Protocol Pivoting come un attacco a più fasi in cui un avversario penetra attraverso un protocollo, sfrutta le assunzioni di fiducia che i protocolli hanno l’uno nell’altro e scala a capacità disponibili solo tramite un protocollo diverso. Il suo esempio concreto inserisce testo strutturato come un’istruzione di compito A2A nell’output dello strumento MCP; un agente orchestratore lo passa a un sotto‑agente come delega normale, e il sotto‑agente, fidandosi del suo orchestratore, lo esegue.

Il preprint formale, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” è stato pubblicato su Zenodo il 24 maggio 2026. Presenta tre scenari: escalation di privilegi da MCP a A2A tramite delega di fiducia implicita, iniezione di capacità da A2A a MCP mediante impersonazione di agente malevolo, e catene di iniezione di prompt cross‑protocollo. Analizza inoltre perché le difese esistenti falliscono contro questa classe e propone un quadro di sicurezza cross‑protocollo unificato con un modello formale di confine di fiducia e tre mitigazioni indipendenti dal protocollo.

Il lavoro di maggio è iniziato con il playwright-mcp di Microsoft, il cui strumento browser_navigate accettava qualsiasi URL fornito dall’agente senza protezione SSRF, consentendo a un agente di essere indirizzato al servizio di metadati dell’istanza AWS all’indirizzo 169.254.169.254 e alle relative credenziali. Mohiuddin osserva di aver segnalato ciò come issue pubblico su GitHub, che non esiste alcun CVE né conferma del fornitore, e che la valutazione di gravità è la sua stima personale.

Mohiuddin sostiene che le analisi di composizione del software e gli scanner di dipendenze non rilevano questa classe perché l’input pericoloso arriva tramite il trasporto come argomento di uno strumento descritto da un manifesto dello strumento che lo scanner non legge mai, così il grafo delle chiamate si interrompe al confine del trasporto. Afferma di aver sviluppato mcp-safeguard, uno scanner open‑source che testa i server MCP attraverso la loro superficie di strumenti esposta senza necessità di sorgente, alla ricerca di sei classi: SSRF, permessi eccessivi, superfici di iniezione di prompt, perdite di informazioni, lacune di autenticazione e bypass del ciclo di vita. Dichiarando inoltre che gli strumenti basati su pattern matching, incluso il suo, non individuano una larga parte di questa classe.

Mohiuddin dichiara che presenterà il modello cross‑vendor il 23 ottobre 2026 al MCPCon North America a San Jose, includendo le eventuali segnalazioni risolte entro quella data, e che le scoperte federali rimarranno private finché non saranno corrette.