Forscher deckt dieselbe MCP-Lücke bei Google, JPMorgan und zwei Regierungen auf

Der unabhängige Sicherheitforscher Syed Anas Mohiuddin gab in einem Forschungsupdate vom Oktober 2026 bekannt, dass derselbe Server‑Side‑Request‑Forgery‑Fehler in Model Context Protocol-Servern von Sicherheitsteams von fünf unabhängigen Organisationen bestätigt und behoben wurde: Google, JPMorgan Chase, Weaviate, die interministerielle Digitaldirektion Frankreichs und die Stadtregierung von Tangerang in Indonesien.

Das Update mit dem Titel “Protocol Pivoting, four months later” prüft eine Vorhersage, die Mohiuddin im Mai 2026 gemacht hatte: Wenn die Schwäche strukturell und nicht nur eine einzelne nachlässige Implementierung wäre, würde derselbe Fehler in Servern auftreten, die von Teams geschrieben wurden, die keinen gemeinsamen Code, keine gemeinsame Branche, kein gemeinsames Land oder keinen gemeinsamen Eigentümer haben. Er berichtet, dass jede der fünf Organisationen ihren Fall durch das eigene Sicherheitsteam bestätigt hat und dass der Sicherheitsanbieter Rapid7 separat einen CVE für einen anderen, aber verwandten Fehler veröffentlicht hat. Das Update zählt fünf Organisationen, die dieselbe SSRF behoben haben, zwei veröffentlichte CVEs und fünf Befunde in US‑Bundes‑MCP‑Servern, die noch offen sind.

Mohiuddin beschreibt zwei Fehlermodi hinter dem Muster. Der erste ist Server‑Side‑Request‑Forgery: Ein MCP‑Server erstellt eine ausgehende Anfrage aus einer URL, einem Pfad oder Endpunkt, der von einem Agenten bereitgestellt wird, ohne zu prüfen, wohin sie aufgelöst wird, sodass der Agent im Wesentlichen bestimmt, mit wem die Netzwerkidentität des Servers kommuniziert. Der zweite ist der unsichere Umgang mit vorgeladenen Daten, am deutlichsten sichtbar, wenn vollständige API‑Antworten aus vorgeladenen Diensten ohne Redaktion in zentrale Protokolle geschrieben werden, wobei gewöhnliche Fehler ausreichen, um dies auszulösen. Er führt beide auf die Annahme zurück, dass Daten, die die MCP‑Grenze überschreiten, als vertrauenswürdig gelten, weil sie aus dem Inneren des Systems stammen, was er argumentiert, in einer agentischen Pipeline nicht zutrifft.

CVE-2026-14540 im MCP‑Toolbox von Google

Gemäß dem GitHub Advisory Database‑Eintrag für CVE‑2026‑14540, veröffentlicht von der National Vulnerability Database, besteht eine SSRF‑Schwachstelle in den generischen HTTP‑Quell‑ und Werkzeugkomponenten von Googles mcp-toolbox Versionen 0.3.0 bis 1.4.0. Da der HTTP‑Client keine restriktive Weiterleitungsrichtlinie hatte und Ziel‑IP‑Adressen nie prüfte, konnte ein manipulierter Pfadparameter die ausgehenden Anfragen des Toolboxes zu internen oder beliebigen externen Endpunkten umleiten. Die Advisory stuft den Fehler als hochgradig ein mit einem CVSS‑Score von 8,0; sie wurde am 31. Juli 2026 veröffentlicht und zuletzt am 8. August 2026 aktualisiert. Mohiuddin gibt an, dass der CVE am 3. Juli 2026 reserviert wurde und dass der Eintrag ihn als Entdecker ausweist.

Google integrierte die Korrektur, Pull‑Request #3448 im googleapis/mcp-toolbox‑Repository, am 18. Juni 2026, und sie wurde in mcp-toolbox v1.5.0 ausgeliefert. Der Pull‑Request implementiert einen SSRFGuard, um DNS‑Rebinding‑Angriffe im Zeitraum zwischen Adressprüfung und Verbindung zu verhindern, fügt konfigurierbare Eigenschaften allowPrivateNetworks, allowedIpRanges und customBlockedIpRanges hinzu, prüft die konfigurierte BaseURL beim Initialisieren statt bei der ersten Anfrage und warnt ausdrücklich vor Man‑in‑the‑Middle‑Risiken, wenn die SSL‑Verifizierung deaktiviert ist. Der PR weist Mohiuddin als Meldenden aus, und Mohiuddin beschreibt Googles Behebung als Referenzimplementierung eines echten SSRF‑Guards.

Vier weitere bestätigte Fälle

Mohiuddin berichtet, dass das Open‑Source‑Repository jpmorgan-payments/ai von JPMorgan Chase einen documentation‑search‑MCP‑Server enthält, dessen read_documentation‑Werkzeug vor dem Abrufen eine Domain‑Whitelist anwendet, während das zugehörige related()‑Werkzeug eine vom Aufrufer bereitgestellte URL serverseitig ohne Einschränkung abruft. Er gibt an, dass die Komponente von einem AWS‑Projekt geforkt wurde, dessen Original die Aufrufer‑URL nie dereferenzierte, dass das Responsible‑Disclosure‑Team der Bank den Befund als gültig bestätigte und dass ein Fix ausgerollt wurde. Er wird namentlich auf der öffentlichen Responsible‑Disclosure‑Anerkennungsseite von JPMorgan Chase aufgeführt und stuft den Befund als mittlere Schwere ein, wobei er anmerkt, dass keine Anmeldedaten mit der gefälschten Anfrage mitgesendet werden.

Er berichtet, dass Weaviate einen Pull‑Request zusammengeführt hat, der die apiEndpoint‑, region‑ und location‑Einstellungen des Google‑Moduls auf Google‑API‑Hosts beschränkt, und ihn namentlich in seinem öffentlichen Security Hall of Fame‑Eintrag vom 25. August 2026 aufführt.

Das Projekt datagouv/datagouv-mcp hat am 4. September 2026 Pull‑Request #126, „feat: harden SSRF on external APIs“ zusammengeführt, und der Pull‑Request beginnt mit der Nennung von Mohiuddin als Meldenden. Laut dem PR wurde ein machineDokumentationurl‑Feld, das von jedem registrierten data.gouv.fr‑Produzenten bereitgestellt wird, serverseitig abgerufen und konnte auf Loopback‑, Privat‑Netzwerk‑ oder Cloud‑Metadaten‑Adressen zeigen, wobei DNS‑Rebinding das Ziel zwischen Prüfung und Verbindung austauschen konnte und ein 302‑Redirect auf einen internen Host führen konnte. Der Fix prüft die Ziel‑IP zur Verbindungszeit, überprüft jeden Redirect‑Hop erneut und verweigert Proxies. Mohiuddin identifiziert das Projekt als den offiziellen MCP‑Server für die nationale Open‑Data‑Plattform Frankreichs, die von DINUM, der interministeriellen Digitaldirektion der Regierung, betrieben wird.

Ein GitHub Security Advisory veröffentlicht am 3. September 2026 der Maintainer von INFOKOM-KI/Wazuh-MCP-Server, mit hoher Einstufung, verzeichnet, dass das Tool blueteamcheckwebshells beworbener SSRF‑Schutz nur wörtliche IP‑Adressen ablehnt und niemals auf Hostnamen auflöst, sodass jeder DNS‑Name, der auf eine private, Loopback‑ oder Link‑Local‑Adresse zeigt, einschließlich Cloud‑Instanz‑Metadaten, diesen Schutz umgeht. Der Advisory stellt fest, dass die dokumentierte Garantie des Tools, „SSRF Protection: Private/reserved IPs in the URL host are rejected“, für URL‑Hostnamen nicht gilt. Die Schwachstelle wurde im Commit 2bbfe12 behoben, und der Advisory nennt Mohiuddin als Meldenden. Mohiuddin gibt an, er habe sie am 2. September 2026 gemeldet, die Maintainer hätten von einer tangerangkota.go.id‑Adresse geantwortet, und das Projekt werde von der Stadtregierung Tangerang in Indonesien betrieben.

Rapid7s Eintrag in der Schwachstellendatenbank zu CVE-2026-97228 verzeichnet eine GraphQL‑Abfrageinjektion in Rapid7 Bulk Export MCP‑Versionen 0.2.5 bis 0.6.1, bei der ein nicht validiertes exportid MCP‑Tool‑Argument direkt in eine GraphQL‑Abfrage interpoliert wird. Rapid7 bewertet sie mit 2,7 (niedrig) nach dem CVSS‑3.1‑Schema, veröffentlichte den Eintrag am 25. September 2026 und weist darauf hin, dass injizierte Abfragen im eigenen API‑Umfang des Operators ausgeführt werden und keine Mandanten‑Grenze überschreiten; Version 0.6.2 behebt das Problem, indem exportid als parametrisierte Variable übergeben wird. Mohiuddin gibt an, Rapid7 habe ihn als Entdecker genannt.

Über diese Fälle hinaus berichtet Mohiuddin, dass zum Zeitpunkt des Updates 16 GitHub‑Security‑Advisories, die von den jeweiligen Projekt‑Maintainer*innen veröffentlicht wurden, ihn als Meldenden ausweisen. Diese decken SSRF ebenso wie Befehlsinjektionen, Authentifizierungslücken, Session‑Hijacking, Credential‑Leaks und Umgehungen früherer Fixes ab, und er habe Fixes in Projekten wie github-mcp-server, mongodb-mcp-server und salesforce-mcp-server erhalten.

Ungeklärte Regierungsbefunde

Mohiuddin berichtet, dass er am 2. September 2026 fünf Befunde als private GitHub‑Security‑Advisories eingereicht hat, die MCP‑Server im Rahmen des Technology Transformation Services des GSA betreffen: einen Benefits‑Claims‑Server des Department of Veterans Affairs, einen CMS Blue Button‑Server, einen regulations.gov‑Server, einen USASpending‑Server und einen CDC PLACES‑Server. Er gibt an, dass alle fünf sich noch in der Triagierung befinden, nicht behoben wurden und nicht als bestätigte Ergebnisse präsentiert werden.

Im VA‑Fall, den er nur auf Klassenebene beschreibt, protokolliert der Server den vollständigen Fehler‑Body der Upstream‑Benefits‑API auf ERROR‑Level ohne Redaktion; diese Bodies können den Namen eines Veteranen, die Sozialversicherungsnummer, das Geburtsdatum und die Adresse enthalten, und er stellt fest, dass routinemäßige Validierungsfehler ausreichen, um das Logging im normalen Betrieb auszulösen. Er hält Details auf Code‑Ebene zurück, bis die Server gepatcht sind.

Er berichtet außerdem, dass er am 1. September 2026 JPCERT darüber informierte, dass der jgrants-mcp-server der Japan Digital Agency keine Authentifizierung habe, und am 7. September 2026 einen öffentlichen Pull‑Request eröffnete, der ein explizites Opt‑In verlangt, um den Server an etwas anderes als Loopback zu binden und die Schreibgröße von Anhängen zu begrenzen. Der Pull‑Request wurde nicht gemergt und er präsentiert ihn nicht als bestätigtes Ergebnis.

Protocol Pivoting und der MCPCon‑Talk

Mohiuddin definiert Protocol Pivoting als mehrstufigen Angriff, bei dem ein Angreifer über ein Protokoll eindringt, die Vertrauensannahmen ausnutzt, die Protokolle gegenseitig aneinander knüpfen, und zu Fähigkeiten eskaliert, die nur über ein anderes Protokoll verfügbar sind. Sein konkretes Beispiel platziert textähnliche A2A‑Aufgabeninstruktionen in der Ausgabe eines MCP‑Tools; ein orchestrierender Agent übergibt sie einem Sub‑Agent als normale Delegation, und der Sub‑Agent, dem sein Orchestrator vertraut, führt sie aus.

Der der formelle Preprint, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” wurde am 24. Mai 2026 auf Zenodo veröffentlicht. Er stellt drei Szenarien vor: MCP‑zu‑A2A‑Privilegieneskalation via implizite Vertrauensdelegation, A2A‑zu‑MCP‑Fähigkeitseinspeisung via bösartiger Agenten‑Impersonation und cross‑protokollare Prompt‑Injection‑Ketten. Zudem analysiert er, warum bestehende Abwehrmechanismen gegen diese Klasse versagen, und schlägt ein einheitliches cross‑protokollares Sicherheitsframework mit einem formalen Trust‑Boundary‑Modell sowie drei protokoll‑agnostischen Gegenmaßnahmen vor.

Die Arbeit im Mai begann mit Microsofts playwright-mcp, dessen browser_navigate‑Tool jede vom Agenten bereitgestellte URL ohne SSRF‑Schutz akzeptierte, wodurch ein Agent zur AWS‑Instanz‑Metadaten‑Service‑Adresse 169.254.169.254 und deren Anmeldeinformationen gesteuert werden konnte. Mohiuddin weist darauf hin, dass er dies als öffentliches GitHub‑Issue gemeldet hat, dass es keine CVE und keine Herstellerbestätigung gibt und dass die Schweregrad‑Bewertung seine eigene Einschätzung ist.

Mohiuddin argumentiert, dass Software‑Composition‑Analysis‑ und Dependency‑Scanner diese Klasse übersehen, weil die gefährliche Eingabe über das Transport‑Layer als Tool‑Argument ankommt, das in einem Tool‑Manifest beschrieben wird, das der Scanner nie liest, sodass der Aufrufgraph an der Transportgrenze endet. Er gibt an, er habe mcp-safeguard entwickelt, einen Open‑Source‑Scanner, der MCP‑Server über deren exponierte Tool‑Oberfläche testet, ohne Quellcode zu benötigen, und nach sechs Klassen sucht: SSRF, übermäßige Berechtigungen, Prompt‑Injection‑Oberflächen, Informationslecks, Authentifizierungslücken und Lifecycle‑Umgehungen. Er stellt zudem fest, dass Mustererkennungs‑Tools, einschließlich seines eigenen, einen großen Teil dieser Klasse übersehen.

Mohiuddin erklärt, dass er das cross‑vendor‑Muster am 23. Oktober 2026 auf der MCPCon North America in San Jose vorstellen wird, einschließlich aller bis dahin behobenen Befunde, und dass die Bundes‑Befunde privat bleiben, bis sie gepatcht sind.