Eine Untersuchung öffentlich indexierter Model-Context-Protocol-Infrastrukturen hat Schwachstellen bei Governance, Hosting, Domaininhaberschaft und dem von externen Diensten ausgeführten Code aufgedeckt.
OX Security zufolge untersuchte das Unternehmen 15.465 MCP-Server-Einträge aus fünf Registries und fasste sie anschließend zu 5.095 eindeutigen Hostnamen zusammen. Die Ergebnisse beziehen sich nicht auf 15.465 verschiedene Betreiber oder betroffene Organisationen: Die höhere Zahl steht für indexierte Server-Einträge, die niedrigere für unterschiedliche Hostnamen.
Laut dem Bericht von OX Security über die Untersuchung waren einige aufgeführte Server möglicherweise in nicht genehmigten Rechtsräumen gehostet, über Consumer-Tunnel erreichbar oder mit Domains verknüpft, die inzwischen nicht mehr aufgelöst wurden.
Der Bericht dokumentiert keinen bestätigten Sicherheitsvorfall. OX identifizierte in der veröffentlichten Darstellung weder ein Opfer noch einen nachgewiesenen Datendiebstahl oder aktive Angriffe im Zusammenhang mit den untersuchten Servern. Stattdessen zeigt die Untersuchung, wie ein KI-Agent einer Infrastruktur vertrauen könnte, deren Eigentümer, Standort oder Verhalten sich später ändern.
Tausende Einträge verteilen sich auf 5.095 Hostnamen
MCP wurde 2024 als Standard eingeführt, um KI-Modelle, Software-Agenten und integrierte Entwicklungsumgebungen mit externen Tools und Datenquellen zu verbinden. Ein MCP-Server kann einem Agenten bestimmte Funktionen bereitstellen und so Teil sensibler Arbeitsabläufe werden.
OX analysierte fünf MCP-Registries. In der veröffentlichten Darstellung werden diese jedoch nicht genannt, und auch ihre jeweiligen Aufnahme- und Prüfverfahren bleiben unerwähnt. Deshalb lassen sich die Registries nur eingeschränkt miteinander vergleichen und ihre Kontrollen nicht daraufhin beurteilen, ob sie alle dieselben Anforderungen stellen.
Die Unterscheidung zwischen Einträgen und Infrastruktur ist wichtig: OX erfasste 15.465 öffentlich indexierte Server, durch die Bereinigung von Duplikaten blieben jedoch 5.095 eindeutige Hostnamen übrig. Mehrere Registry-Einträge können also auf denselben Hostnamen verweisen.
Die angegebenen Prozentwerte beziehen sich auf Hostnamen, nicht auf Personen. Sie sind nicht als Zahlen kompromittierter Systeme, Kunden oder Organisationen zu verstehen.
Anders als ein herkömmlicher Hinweis auf eine Schwachstelle benennt die Untersuchung weder eine fehlerhafte Produktversion noch eine CVE oder einen Schweregrad. Das Problem ist grundsätzlicher: Agenten könnten sich mit Diensten Dritter verbinden, ohne ausreichend sicher zu wissen, wer diese betreibt, wohin Anfragen übermittelt werden oder welcher Backend-Code sie verarbeitet.
Der Hosting-Standort kann zu einem nicht genehmigten Datenpfad führen
OX zufolge verwiesen 15,6 % der Hostnamen auf Infrastruktur außerhalb der USA. Im Bericht werden ausdrücklich 19 Hostnamen in China und 18 in Russland genannt; eine vollständige Aufschlüsselung nach Ländern gibt es jedoch nicht.
Der geografische Standort belegt nicht, dass ein Server böswillig ist. Er kann aber darüber entscheiden, welche Rechtsvorschriften und internen Anforderungen an die Datenresidenz gelten, wenn ein Agent Prompts, Quellcode, Zugangsdaten oder Geschäftsinformationen an den Dienst übermittelt.
Ein Unternehmen kann ein bestimmtes KI-Tool genehmigt haben, ohne jeden MCP-Endpunkt, den dieses Tool aufrufen kann, gesondert zu prüfen. In diesem Fall könnte die Verbindung eines Agenten einen Datenpfad außerhalb der von der Organisation zugelassenen Regionen schaffen.
OX beschreibt außerdem ein Szenario, in dem ein Betreiber einen Dienst zunächst auf einer IP-Adresse in den USA hostet und ihn später an einen anderen Standort umleitet. Die veröffentlichten Ergebnisse belegen nicht, dass OX einen solchen Wechsel bei den untersuchten Servern beobachtet hat. Es handelt sich um ein Bedrohungsszenario, das veranschaulicht, warum eine einmalige Standortprüfung keine dauerhafte Sicherheit bietet.
Entscheidend ist die kontinuierliche Überprüfung. Ein Hostname kann unverändert bleiben, obwohl sich die dahinterliegende Infrastruktur verlagert – und bestehende Agentenkonfigurationen weiterhin gültig sind.
Consumer-Tunnel erschweren die Einschätzung der Serverkontrolle
OX zufolge leiteten 0,45 % der untersuchten Hostnamen den Datenverkehr über Consumer-Tunneldienste, vor allem über ngrok-free.
Ein Tunnel kann eine lokal ausgeführte Anwendung erreichbar machen, ohne dass der Betreiber sie auf herkömmlicher Hosting-Infrastruktur bereitstellen muss. Für Demonstrationen und Entwicklungsarbeiten ist das praktisch, Unternehmen erhalten dadurch jedoch weniger Einblick in die Umgebung hinter dem öffentlichen Endpunkt.
OX beschreibt die aufgeführten Tunnel-Dienste als auf privaten Rechnern betrieben. Das Unternehmen geht zudem davon aus, dass diese wahrscheinlich über Heimnetzwerke angebunden sind. Diese Einschätzung zum Netzwerkstandort ist jedoch eine Schlussfolgerung und kein bestätigter Befund zu jedem einzelnen Endpunkt.
Das Problem betrifft die operative Kontrolle, nicht eine nachgewiesene Kompromittierung der Tunnel-Plattform. Ein öffentlich gelisteter MCP-Dienst könnte von einem privaten Rechner, einem informellen Bereitstellungsprozess oder einer Infrastruktur abhängen, die nicht den üblichen Überwachungs- und Änderungsmanagementsystemen einer Organisation unterliegt.
Das kann sich sowohl auf die Verfügbarkeit als auch auf die Sicherheit auswirken. Für den Agenten ist der Endpunkt erreichbar, doch sein Betreiber bietet möglicherweise nicht die Identitäts-, Lebenszyklus- und Lieferkettengarantien, die Unternehmen von einem Dienst erwarten.
Abgelaufene Domains könnten die Identität eines vertrauenswürdigen Servers übertragen
OX stellte fest, dass 2,3 % der Hostnamen nicht mehr aufgelöst wurden. Sechs davon waren demnach mit abgelaufenen Domains verknüpft, die schätzungsweise für 4–12 US-Dollar pro Jahr registriert werden konnten.
Dadurch entsteht ein mögliches Problem bei der Identitätsübertragung: Bleibt ein Agent so konfiguriert, dass er eine dieser Domains kontaktiert, könnte ein neuer Inhaber den Hostnamen wieder aktivieren und künftig Anfragen empfangen, die eigentlich an den früheren MCP-Betreiber gerichtet waren.
Die Domain kann zum Angriffsziel werden, weil das Vertrauen in Client-Konfigurationen möglicherweise fortbesteht, obwohl die Inhaberschaft erloschen ist. Nutzer erkennen den Servernamen womöglich weiterhin wieder, während automatisierte Agenten nicht zwischen dem früheren Betreiber und dem neuen Inhaber unterscheiden können.
OX berichtet nicht, dass eine der sechs Domains tatsächlich von einem Angreifer registriert wurde. Auch abgefangene Anfragen über diese Domains werden im Bericht nicht dokumentiert. Der Befund beschreibt einen möglichen Übernahmeweg, keine abgeschlossene Übernahme oder bestätigte Offenlegung.
Welche Folgen das hätte, hinge außerdem davon ab, wie der Agent den Endpunkt nutzt. Aus den veröffentlichten Zahlen geht nicht hervor, welche Tools, Berechtigungen oder Informationen für Clients verfügbar waren, die für die betroffenen Domains konfiguriert waren.
Ein öffentliches Repository belegt nicht, was ein externer Server ausführt
Die Untersuchung stellt auch eine verbreitete Annahme bei der Softwareprüfung infrage: dass die Prüfung eines öffentlichen Repositorys ausreicht, um das Verhalten eines externen MCP-Dienstes festzustellen.
Die Prüfung eines Repositorys kann helfen, Quellcode, Abhängigkeiten und angegebene Funktionen zu bewerten. Nutzer können jedoch nicht davon ausgehen, dass der externe Dienst denselben Code ausführt, wenn sie nicht überprüfen können, ob das bereitgestellte System tatsächlich diesem Code entspricht. Das Backend könnte eine andere Version oder völlig andere Logik ausführen.
OX zufolge fehlt MCP-Marktplätzen eine mit der Malware-Prüfung von App-Stores vergleichbare Kontrolle. Herausgeber könnten Server bereitstellen, ohne eine vergleichbare Prüfung zu durchlaufen. Da der Bericht die fünf Registries nicht nennt und ihre konkreten Kontrollen nicht dokumentiert, lässt sich diese Einschätzung anhand der verfügbaren Informationen nicht gleichermaßen auf alle fünf übertragen.
Als Vergleich nennt der Artikel Google Bouncer, einen Dienst, mit dem Google 2012 Android-Anwendungen überprüfte. Zugleich räumt er ein, dass Forschende Möglichkeiten fanden, Bouncer zu umgehen. Eine Prüfung ist also keine absolute Garantie, kann aber eine zusätzliche Kontrollebene schaffen, die laut OX im MCP-Ökosystem fehlt.
Der vollständige Bericht von OX mit dem Titel „15,465 MCP Servers, 0 Governance“ soll einen Proof of Concept zu Prompt Injection sowie weitere Bedrohungsszenarien enthalten. Die veröffentlichte Zusammenfassung bietet nicht genügend technische Einzelheiten, um die Voraussetzungen des Proof of Concept zu beurteilen oder festzustellen, ob er an einem aktiven Dienst Dritter getestet wurde.
Unternehmen müssen die Verbindungen absichern, nicht nur den Code
OX fordert MCP-Marktplätze auf, Prüfverfahren für Anbieter, Code-Signing und Herkunftsverifizierung einzuführen. Zusammen sollen diese Maßnahmen drei Fragen beantworten: Wer darf Inhalte veröffentlichen? Wurde ein Artefakt verändert? Und entspricht ein externer Dienst der erwarteten Quelle?
Unternehmen, die MCP nutzen, können die Verbindungen außerdem in bestehende Governance-Programme einbeziehen. Die Untersuchung nennt dafür Regeln zur Datenresidenz, Zero-Trust-Grenzen, eine differenzierte Identitäts- und Zugriffsverwaltung (IAM) sowie Audits der Lieferkette.
Auf MCP-Umgebungen übertragen heißt das: Unternehmen sollten nachvollziehen können, welche Agenten auf welche Server zugreifen dürfen und ob diese Endpunkte weiterhin innerhalb genehmigter Rechtsräume und Eigentumsverhältnisse liegen. Domainstatus und Hosting-Standort sind nicht dauerhaft; eine Genehmigung, die auf einer anfänglichen Prüfung beruht, kann deshalb veralten.
Auch die Prüfung eines Repositorys sollte als eine von mehreren Informationsquellen gelten, nicht als Beweis für das Laufzeitverhalten. Wenn ein Arbeitsablauf sensible Informationen verarbeitet, müssen Unternehmen sich auf den bereitgestellten Dienst und seinen Betreiber verlassen können – nicht nur auf den in einem öffentlichen Projekt angegebenen Code.
OX verweist außerdem auf frühere Untersuchungen zu Schwachstellen im MCP-Quellcode von Anthropic. Das Unternehmen bezeichnet diese Probleme als kritisch und gibt an, der Code sei mehr als 150 Millionen Mal heruntergeladen worden. Die verfügbaren Informationen enthalten jedoch weder CVE-Kennungen noch betroffene Versionen, technische Belege oder Angaben zur Behebung dieser früheren Schwachstellen. Daher lassen sie sich nicht als Teil der aktuellen Server-Untersuchung bewerten.
Die neu veröffentlichten Messwerte stammen von OX und wurden in den für diesen Artikel verfügbaren Unterlagen nicht unabhängig überprüft. Dennoch beschreiben sie ein konkretes Governance-Problem: Das Vertrauensverhältnis eines KI-Agenten könnte länger bestehen als die Infrastruktur, der Domaininhaber oder die Softwareimplementierung, auf denen es ursprünglich beruhte.
