Il ricercatore indipendente di sicurezza Syed Anas Mohiuddin ha documentato la presenza dello stesso errore di Server-Side Request Forgery, o SSRF, in implementazioni Model Context Protocol sviluppate indipendentemente da cinque organizzazioni: Google, JPMorgan Chase, Weaviate, la Direction interministérielle du numérique francese e l’amministrazione della città di Tangerang, in Indonesia. I cinque casi sono stati confermati dai rispettivi team di sicurezza e corretti, rafforzando l’ipotesi formulata dallo stesso Mohiuddin nel maggio 2026 secondo cui il problema non fosse riconducibile a una singola implementazione difettosa, ma a una debolezza strutturale ricorrente nel modo in cui i server MCP gestiscono input provenienti dagli agenti. Le organizzazioni coinvolte non condividono codice, settore industriale, paese o proprietà, ma sono arrivate a introdurre indipendentemente lo stesso tipo di vulnerabilità. Il quadro complessivo comprende cinque organizzazioni che hanno corretto la stessa classe di SSRF, due CVE pubblicate e altre cinque segnalazioni relative a server MCP del governo federale statunitense che risultano ancora aperte. Il problema principale si verifica quando un server MCP costruisce una richiesta HTTP in uscita utilizzando URL, percorsi o endpoint controllabili dall’agente senza verificare in modo adeguato l’indirizzo al quale questi valori vengono effettivamente risolti: in questa situazione è di fatto l’agente a poter determinare con quali sistemi comunica l’identità di rete del server. Mohiuddin individua anche un secondo schema ricorrente, relativo alla gestione non sicura delle risposte provenienti dai servizi upstream, per esempio quando interi corpi delle risposte API vengono registrati nei log centralizzati senza essere preventivamente ripuliti da informazioni sensibili. Alla base di entrambi i comportamenti vi sarebbe la stessa assunzione progettuale: considerare affidabile un dato semplicemente perché attraversa un confine interno del sistema, un presupposto che diventa particolarmente problematico nelle pipeline agentiche in cui input e output vengono propagati automaticamente tra strumenti, server e altri agenti.
Uno dei casi più significativi riguarda Google MCP Toolbox e la vulnerabilità CVE-2026-14540, classificata High con un punteggio CVSS pari a 8,0 e presente nelle versioni di mcp-toolbox dalla 0.3.0 alla 1.4.0. I componenti generici HTTP source e HTTP tool utilizzavano infatti un client privo di una politica restrittiva sui redirect e senza una validazione degli indirizzi IP di destinazione, consentendo a un parametro path opportunamente costruito di deviare le richieste in uscita verso endpoint interni oppure verso destinazioni esterne arbitrarie. La vulnerabilità è stata corretta nella versione 1.5.0 dopo il merge, il 18 giugno 2026, della pull request 3448 nel repository googleapis/mcp-toolbox; la CVE è stata riservata il 3 luglio e successivamente pubblicata il 31 luglio, con aggiornamento dell’advisory l’8 agosto. La correzione implementata da Google introduce un SSRFGuard progettato anche per contrastare gli attacchi di DNS rebinding nella finestra temporale tra la verifica dell’indirizzo e l’effettiva connessione, oltre a proprietà configurabili come allowPrivateNetworks, allowedIpRanges e customBlockedIpRanges. La BaseURL configurata viene inoltre verificata già in fase di inizializzazione anziché soltanto al momento della prima richiesta, mentre viene segnalato esplicitamente il rischio di attacchi man-in-the-middle qualora venga disabilitata la verifica SSL. Mohiuddin, indicato come autore della segnalazione, considera questa implementazione un esempio di riferimento di come dovrebbe essere costruita una protezione SSRF effettiva, perché non si limita al controllo sintattico dell’URL ma considera la destinazione reale della connessione e i cambiamenti che possono verificarsi tra risoluzione DNS e apertura del collegamento.
Un comportamento analogo è stato individuato nel repository open source jpmorgan-payments/ai di JPMorgan Chase. Il server MCP dedicato alla ricerca della documentazione disponeva di uno strumento read_documentation che applicava correttamente un’allowlist dei domini prima di effettuare la richiesta, mentre il tool correlato related() accettava un URL fornito dal chiamante e lo recuperava lato server senza applicare la stessa restrizione. Il componente derivava da un progetto AWS nel quale, tuttavia, l’URL ricevuto dal chiamante non veniva originariamente dereferenziato, e quindi la modifica del comportamento aveva introdotto una nuova superficie di attacco. Il Responsible Disclosure team di JPMorgan Chase ha confermato la validità della segnalazione e ha distribuito una correzione; Mohiuddin compare inoltre nella pagina pubblica dell’istituto dedicata ai ricercatori riconosciuti per le segnalazioni responsabili. In questo caso la vulnerabilità è stata valutata di severità media, anche perché la richiesta falsificata non trasportava credenziali. Weaviate ha invece corretto il proprio caso limitando i parametri apiEndpoint, region e location del modulo Google agli host API appartenenti a Google e ha inserito Mohiuddin nella propria Security Hall of Fame il 25 agosto 2026. Anche il progetto datagouv/datagouv-mcp, server MCP ufficiale della piattaforma nazionale francese dei dati aperti e mantenuto dalla DINUM, ha ricevuto una correzione specifica con la pull request 126, unita il 4 settembre con l’obiettivo dichiarato di rafforzare la protezione SSRF sulle API esterne. In quel caso un campo machineDocumentationUrl, impostabile da qualsiasi produttore registrato su data.gouv.fr, veniva recuperato direttamente dal server e poteva indicare indirizzi loopback, reti private o endpoint dei servizi metadata dei cloud provider; inoltre il DNS rebinding poteva sostituire la destinazione dopo il controllo iniziale e un redirect HTTP 302 poteva condurre la richiesta verso un host interno. La correzione verifica ora l’IP al momento della connessione, ripete il controllo per ogni hop di redirect e rifiuta l’utilizzo di proxy.
Un ulteriore caso ha interessato INFOKOM-KI/Wazuh-MCP-Server, mantenuto dall’amministrazione della città indonesiana di Tangerang. La protezione SSRF dichiarata dal tool blueteamcheckwebshell respingeva soltanto gli indirizzi IP scritti direttamente nell’URL, ma non effettuava la risoluzione dei nomi host prima di decidere se la destinazione fosse consentita. Di conseguenza era sufficiente utilizzare un nome DNS che risolvesse verso un indirizzo privato, loopback o link-local, compresi gli endpoint metadata delle istanze cloud, per aggirare la protezione. La vulnerabilità, classificata High in un GitHub Security Advisory pubblicato il 3 settembre 2026, contraddiceva quindi la garanzia documentata secondo cui gli indirizzi privati o riservati presenti nell’host di un URL sarebbero stati rifiutati. La falla è stata corretta nel commit 2bbfe12 e l’advisory attribuisce la segnalazione a Mohiuddin, che riferisce di averla comunicata il 2 settembre e di aver ricevuto la risposta dei maintainer da un indirizzo tangerangkota.go.id. Separatamente, Rapid7 ha pubblicato CVE-2026-97228 per una vulnerabilità differente ma correlata alla stessa superficie di strumenti MCP: nelle versioni da 0.2.5 a 0.6.1 di Rapid7 Bulk Export MCP, l’argomento exportid fornito a un tool veniva interpolato direttamente all’interno di una query GraphQL senza adeguata parametrizzazione, rendendo possibile una GraphQL query injection. Rapid7 l’ha classificata Low, con CVSS 3.1 pari a 2,7, perché le query iniettate vengono comunque eseguite entro i privilegi API dell’operatore e non possono attraversare il confine tra tenant; il problema è stato risolto nella versione 0.6.2 trasformando exportid in una variabile parametrizzata.
Il lavoro di Mohiuddin si estende nel frattempo ben oltre questi cinque casi. Alla data dell’aggiornamento risultano 16 GitHub Security Advisory pubblicati direttamente dai manutentori di diversi progetti che lo indicano come reporter, relativi non soltanto a SSRF ma anche a command injection, assenza di autenticazione, session hijacking, esposizione di credenziali e bypass di correzioni precedenti. Correzioni derivate dalle sue segnalazioni sono state integrate anche in progetti come github-mcp-server, mongodb-mcp-server e salesforce-mcp-server. Restano invece irrisolte cinque segnalazioni inviate il 2 settembre 2026 sotto forma di GitHub Security Advisory private riguardanti server MCP gestiti dalla Technology Transformation Services della General Services Administration statunitense: un server per le richieste di benefit del Department of Veterans Affairs, un server CMS Blue Button, un server regulations.gov, un server USASpending e un server CDC PLACES. Secondo Mohiuddin le cinque segnalazioni sono ancora in triage e non devono quindi essere considerate vulnerabilità definitivamente confermate. Nel caso del server VA, senza divulgare dettagli implementativi che potrebbero facilitarne lo sfruttamento prima della correzione, il problema riguarda la registrazione integrale nei log di livello ERROR dei corpi delle risposte restituite dall’API dei benefit: tali risposte possono contenere dati personali come nome del veterano, Social Security number, data di nascita e indirizzo, e normali errori di validazione sarebbero sufficienti ad attivarne la registrazione durante l’uso ordinario del servizio. Mohiuddin ha inoltre comunicato a JPCERT il 1° settembre che il progetto jgrants-mcp-server della Digital Agency giapponese non disponeva di autenticazione e il 7 settembre ha aperto una pull request pubblica che richiede un opt-in esplicito per consentire al server di effettuare il binding su indirizzi diversi dal loopback e introduce un limite alla dimensione degli allegati scrivibili; la modifica non è stata ancora integrata e anche questo caso non viene presentato come un esito confermato.
Questi risultati si collegano direttamente al concetto di “Protocol Pivoting” formalizzato da Mohiuddin nel lavoro pubblicato il 24 maggio 2026. Con questa espressione viene descritto un attacco multistadio nel quale un aggressore entra attraverso un protocollo, sfrutta le relazioni di fiducia implicite esistenti tra protocolli diversi e arriva così a utilizzare capacità disponibili soltanto attraverso un altro protocollo. Un esempio consiste nell’inserire all’interno dell’output di un tool MCP del testo strutturato in modo da sembrare un’istruzione A2A: l’agente orchestratore può interpretarlo come normale materiale di delega e inoltrarlo a un subagente, che a sua volta tende a fidarsi delle istruzioni provenienti dall’orchestratore ed esegue l’azione. Il preprint “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems” analizza tre scenari principali: escalation di privilegi da MCP ad A2A attraverso delega implicita della fiducia, capability injection da A2A a MCP mediante impersonificazione di un agente malevolo e catene di prompt injection distribuite tra protocolli differenti. Il lavoro esamina inoltre perché le difese esistenti non riescano a intercettare efficacemente questa classe di attacchi e propone un modello unificato dei confini di fiducia accompagnato da tre mitigazioni indipendenti dallo specifico protocollo utilizzato. La ricerca era iniziata analizzando playwright-mcp di Microsoft, il cui strumento browser_navigate accettava qualsiasi URL fornito dall’agente senza una protezione SSRF, permettendo teoricamente a un agente opportunamente indirizzato di tentare l’accesso al servizio metadata di un’istanza AWS all’indirizzo 169.254.169.254 e alle relative credenziali. In questo caso Mohiuddin aveva aperto pubblicamente un’issue su GitHub, ma non esistono una CVE né una conferma del vendor e la valutazione della gravità rimane quella formulata dal ricercatore stesso.
La difficoltà nel rilevare questa categoria di problemi deriva anche dal fatto che gli strumenti tradizionali di Software Composition Analysis e gli scanner delle dipendenze tendono a fermare la propria ricostruzione del call graph al confine del trasporto MCP. L’input pericoloso non necessariamente proviene da una dipendenza vulnerabile o da una funzione evidentemente esposta nel codice, ma può arrivare come argomento di un tool descritto nel manifest MCP e attraversare l’interfaccia di protocollo prima di essere utilizzato per costruire richieste, comandi o altre operazioni privilegiate. Per analizzare direttamente questa superficie Mohiuddin ha sviluppato mcp-safeguard, uno scanner open source che interagisce con i server MCP attraverso i tool che essi espongono, senza richiedere l’accesso al codice sorgente, e cerca sei categorie di problemi: SSRF, privilegi eccessivi, superfici sfruttabili mediante prompt injection, information leakage, assenza di autenticazione e lifecycle bypass. Lo stesso ricercatore sottolinea tuttavia che anche gli strumenti basati sul pattern matching, compreso il proprio, possono non individuare una quota significativa di queste vulnerabilità. Il modello ricorrente emerso nelle implementazioni di Google, JPMorgan, Weaviate e delle organizzazioni governative mostra infatti che il punto critico non è soltanto la presenza di una determinata funzione vulnerabile, ma il modo in cui viene definita la fiducia tra agenti, tool, server MCP, servizi upstream e altri protocolli agentici. Mohiuddin presenterà il modello cross-vendor il 23 ottobre 2026 durante MCPCon North America a San Jose, includendo i risultati che saranno stati corretti entro quella data, mentre i dettagli relativi alle segnalazioni federali ancora aperte resteranno privati fino alla distribuzione delle rispettive patch.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)