Exponiert by Design: Ein Live-Audit von 414 internetzugänglichen MCP-Servern fand 68 Schwachstellen

Am 31. Juli 2026veröffentlichte Nicolás Padilla Exposed by Design (arXiv:2608.00150), ein 13-seitiges Preprint, in dem er beschreibt, was er als die erste dynamische verhaltensbasierte Sicherheitsbewertung von aus dem Internet erreichbaren Model Context Protocol Servern bezeichnet. Vier Messläufe in jenem Monat bestätigten 640 aktive Produktivserver, von denen 414 aktiv getestet wurden; die Tests ergaben 68 berichtenswerte Schwachstellen, die alle bei den Maintainern als GitHub Security Advisories eingereicht wurden. 380 der 414 – 91,8 % – hatten keine OAuth-Authentifizierung, und 687 Tool-Instanzen boten Shell-Ausführung ohne Zugriffskontrollen an. Padilla berichtet keine Hinweise darauf, dass irgendetwas davon ausgenutzt wurde: Die Tests blieben auf Proof-of-Concept-Niveau, es wurden keine Zugangsdaten erlangt und keine Daten exfiltriert. Die vollständige Quellenliste, die Schweregrad-Einstufung und die Vertrauensbewertung des Eintrags befinden sich in dem KI-Vorfallarchiv, zusammen mit den weiteren MCP- und Infrastrukturbefunden, die im selben Kontext eingereicht wurden.

Was das Audit tatsächlich getan hat

Das Model Context Protocol ist die Schnittstelle, über die ein KI-Agent Tools aufrufen kann, die anderswo gehostet werden – eine Dokumentsuche, eine Datenbankabfrage, ein Shell-Hilfsprogramm. Ein Server, der es über HTTP spricht und aus dem Internet erreichbar ist, ist praktisch eine Werkzeugoberfläche, die jeder ansprechen kann. Padillas Aufsatz argumentiert, dass die Grundgesamtheit solcher Server noch nie richtig erfasst wurde und dass es genau darauf ankommt, sie zu erfassen: Die Entdeckung ist der schwierige Teil, und jede frühere Erhebung betrachtete einen anderen Ausschnitt.

Seine Discovery-Phase vereinte elf Quellen — crt.sh, Hugging Face, GitHub, npm, Smithery, PyPI, Censys, FOFA, Shodan, glama.ai und pulsemcp.com — mit der Begründung, dass keine einzelne davon die Grundgesamtheit erfasst. Die aktive Phase verwendete Corvus, ein Framework, das Padilla für die Studie entwickelte: 34 Testmodule, die 10 MCP-spezifische Schwachstellenklassen abdecken, aufgeteilt in 13 statische und 21 dynamische. Es ist auf GitHub unter der CobaltoSec-Organisation und auf PyPI als cobaltosec-corvus, und die eigene Statistikdatei des Repositorys verzeichnet dieselbe Anzahl von 34 Modulen.

Die vier Durchläufe fanden am 15., 18., 21. und 24. Juli 2026 statt. Frühere Durchläufe lieferten nur Bestätigungsnummern; die letzten drei scannten 3.485, 3.948 und 4.110 Kandidaten und bestätigten jeweils 140, 464 und 296 aktive Server. Die Deduplizierung von 972 Rohbeobachtungen mit 332 wiederholten Vorkommen ergab 640 eindeutige bestätigte Server, von denen 414 – 64,7 % – vollständiges dynamisches Testen zuließen. Padilla betrachtet 640 als Untergrenze. Censys, eine der Entdeckungsquellen, hatte im Mai 2026 weltweit mehr als 21.000 MCP-bezogene Endpunkte geschätzt, und er verwendet diese Zahl als Schätzung des Umfangs statt als Zählung dessen, was er getestet hat.

Als Trichter gelesen, sind die Zahlen das eigentliche Argument des Papers: Ein breiter, billiger Durchlauf findet Kandidaten schneller, als ein sorgfältiger Durchlauf sie testen kann. Nur 414 der 640 bestätigten Server wurden vollständig geprüft, und Padilla behauptet nicht, dass die getestete Teilmenge dem ungetesteten Rest ähnelt.

Was es fand

Der zentrale Befund ist die Authentifizierung – bzw. ihr Fehlen. Von den 414 getesteten Servern hatten 380 (91,8 %) kein OAuth. Laut dem Papier verwendeten die meisten der übrigen statische Bearer-Tokens oder API-Schlüssel, oft vorhersagbar oder leer – ein Server, der eine feste Zeichenfolge akzeptiert, ist ebenfalls nicht sinnvoll authentifiziert. Da das Audit nur Server testete, die ohne Anmeldedaten öffentlich erreichbar waren, beschreibt diese Zahl konstruktionsbedingt die exponierte Population; sie ist keine Schätzung für MCP-Server im Allgemeinen.

Die 68 berichtspflichtigen Befunde gliedern sich nach Klassen, wobei sich die Klassenanzahlen überschneiden, statt die Gesamtzahl zu partitionieren: 380 Authentifizierungsmängel, 52 Fälle von Akzeptanz von Protokoll-Fuzzing, 47 Tool-Poisoning, 38 Command Injection, 31 Schema-Bypass, 29 Server-Side Request Forgery, 24 Manipulation von Ressourcen-URIs, 22 Prompt-Injection, 18 Token-Exposure und 14 Lieferkettenindikatoren. Denial-of-Service-Module wurden geschrieben, aber bewusst nicht gegen Produktionsserver ausgeführt, was Padilla aus ethischen Gründen ausschließt. Die vier im Abstract genannten Schwachstellentypen – SQL-Injection, SSRF gegen Cloud-Metadatendienste, Prompt-Template-Injection und Path Traversal über Cursor-Manipulation – kommen jeweils in diesen Klassen vor.

Die Angabe zur Shell-Ausführung benötigt einen Vorbehalt, den der Artikel nicht auflöst. In seinem Ergebnisteil werden 687 Tool-Instanzen mit Shell-Ausführung und ohne Authentifizierung in dem bestätigten Pool von 640 Servern gezählt. In der Diskussion wird dieselbe Zahl mit den Worten „von den 414 dynamisch auditierten Servern“ eingeführt und anschließend auf die „breitere bestätigte Menge“ bezogen. Die beiden Formulierungen stimmen nicht überein, und der Artikel nennt nie eine Gesamtzahl der Tools für die getesteten Server, sodass 687 nicht in einen Prozentsatz umgerechnet werden kann.

Churn ist der Befund, der am stärksten verändert, wie die Zahlen gelesen werden sollten. Von den 464 am 21. Juli bestätigten Servern waren 193 – 41,6 % – verschwunden, als der vierte Lauf drei Tage später prüfte. Neun der 41 Server mit einem CRITICAL-Befund waren ebenfalls verschwunden. Padilla deutet dies als Bereitstellung ohne Prüfung; es bedeutet außerdem, dass ein am Montag bestätigter Befund bis Donnerstag möglicherweise keinen Verantwortlichen hat, der ihn patcht.

Die drei Fallstudien und was sich überprüfen lässt

Drei Befunde sind ausführlich dokumentiert, jeweils mit einer GitHub Security Advisory-ID. Eine SQL-Injection in lectorium-corpus-mcp (GHSA-m8qh-p8m5-8c48, als CRITICAL eingestuft) wurde mit der Nutzlast ' OR 1=1 -- und einem Unterschied bei der Antwortgröße bestätigt, wobei keine Dokumentinhalte gelesen oder gespeichert wurden. Eine SSRF-Schwachstelle in epwforge (GHSA-r9fx-qwmc-rvx3, HIGH) wurde durch Zeitmessung bestätigt: 11,9 Sekunden gegen eine interne Metadatenadresse im Vergleich zu einer Baseline von 0,3 Sekunden, wobei keine Inhalte der Metadatenantwort gespeichert wurden. Eine Prompt-Template-Injection in frootai (GHSA-5h8f-r9g8-5w5p, HIGH) vervollständigt die Liste.

Zwei der drei lassen sich direkt überprüfen. Am 30. Oktober 2026 lösten sich die ersten beiden Advisory-Seiten öffentlich in CobaltoSecs Advisory-Repository auf, beide veröffentlicht am 20. August 2026, beide weiterhin mit „Patched versions: None“ und ohne CVE aufgeführt. Das dritte, GHSA-5h8f-r9g8-5w5p, gab unter dieser Adresse „nicht gefunden“ zurück. CobaltoSecs Repository listete am selben Datum 46 veröffentlichte Advisories, die MCP-Server und angrenzendes KI-Tooling abdeckten; das Paper zählte 19 als öffentlich offengelegt und 49 als noch unter Embargo, als es verfasst wurde. Ein Scan-Artefakt für frootai vom 28. Juli 2026 liegt im Corvus-Repository, der Test fand also statt; nur das Advisory ist nicht sichtbar.

Der Offenlegungsprozess selbst wird eher in Umrissen als im Detail beschrieben. Alle 68 Befunde wurden den Maintainern über private GitHub Security Advisories im Rahmen einer 90-tägigen koordinierten Sperrfrist übermittelt; wo eine private Meldung nicht möglich war, eröffnete Padilla stattdessen ein öffentliches Repository-Issue. Die Arbeit berichtet anekdotisch, dass einige Maintainer innerhalb von 24 Stunden einen Patch bereitstellten, andere über Wochen nicht antworteten und einige Repositories aufgegeben wurden. Sie nennt keine Anzahl der kontaktierten Maintainer und enthält keine Tabelle mit Antwortquoten; diese würden zum Zeitpunkt der Einreichung vollständig berichtet.

Was die Arbeit nicht belegt

Exposed by Design ist ein Preprint mit einem einzigen Autor. arXiv führt Version 1 auf, eingereicht am 31. Juli 2026, ohne Journalreferenz und ohne Peer-Review-Erklärung. Das Archiv bewertet die Vertrauensstufe des Eintrags mit B – dokumentiert, aber aus einer einzigen Quelle – und diese Einstufung gilt für den gesamten Beitrag: Jede oben genannte Zahl stammt aus Padillas Paper oder aus von ihm veröffentlichten Artefakten, nicht aus einer unabhängigen Messung.

Keine unabhängige Nachrichtenredaktion scheint über die Studie berichtet zu haben. Es gibt zwar Berichterstattung – eine KI-verfasste Analyse auf forkast.news, Beiträge auf LinkedIn und Medium, einen chinesischsprachigen Sicherheitsblog, eine japanische Erläuterung –, doch sie paraphrasiert das Preprint, ohne den Autor zu interviewen, die Warnhinweise zu prüfen oder Daten hinzuzufügen. Abgeleitete Berichterstattung ist keine Bestätigung.

Padilla nennt die Grenzen selbst, und sie sind ungewöhnlich spezifisch. Getestet wurden nur HTTP-Transporte; stdio-Server, der übliche lokale Fall, liegen außerhalb des Umfangs. Die Ermittlung erfolgt nach bestem Bemühen, daher ist 640 eine Untergrenze. Die 226 bestätigten Server, die nicht vollständig getestet wurden, wurden wegen 403-Antworten, Verbindungsabbrüchen, nicht konformer JSON-RPC-Antworten oder einfach wegen Nicht-Erreichbarkeit ausgeschlossen, und das Papier sagt, dass die daraus resultierende Auswahlverzerrung nicht eingegrenzt werden kann. Die Erkennung stützt sich auf Heuristiken – Timing-Orakel, differenzielle Antworten, Schema-Inspektion – ohne gelabelten Benchmark und ohne veröffentlichte Precision oder Recall für die 34 Module. Die Fluktuation, die er dokumentiert, untergräbt die zeitliche Validität einzelner Befunde. Und ein einzelner Forscher, der die manuelle Verifizierung vornimmt, bringt ein Risiko der Bestätigungsverzerrung mit sich, das er benennt und nicht quantifiziert.

Was hat sich danach geändert

Das praktische Ergebnis sind bislang das Tool und der Advisory-Stream. Corvus lässt sich installieren und ist dokumentiert, und das Advisory-Repository von CobaltoSec enthielt am 30. Oktober 2026 insgesamt 46 veröffentlichte Einträge – gegenüber den 19 öffentlichen Offenlegungen, die das Paper Ende Juli gezählt hatte. Zwei der eigenen Fallstudien des Papers weisen noch keine gepatchte Version auf – für diese Server hat die Offenlegung zwar einen öffentlichen Eintrag hervorgebracht, aber noch keinen Fix.

Für Verteidiger ist der nützliche Teil der Studie ihre Methodik und nicht ihre Schlagzeile. Eine Zahl von 91,8 %, die nur aus Servern stammt, die ohne Zugangsdaten geantwortet haben, sagt etwas Enges und Reales aus: Das meiste von dem, was exponiert war, war nie abgesichert, und die Fluktuation über drei Tage legt nahe, dass vieles davon für eine Demo, einen Prototyp oder einen Test aufgesetzt und nie gehärtet wurde. Was die Arbeit nicht sagen kann, ist, ob dasselbe für die MCP-Server gilt, auf die Organisationen tatsächlich angewiesen sind, denn diese waren nie in der Stichprobe.