2026-07-31 · RESEARCH · Das Team von Offensive Technology

Sicherheit von Remote-MCP-Servern: Was eine Bestandsaufnahme von 19,321 veröffentlichten Servern zeigt

Die Hälfte der Server im offiziellen Registry des Model Context Protocol ist remote. Wir haben am 31. Juli 2026 den gesamten veröffentlichten Bestand abgerufen, 19,321 eindeutige Server, und analysiert, wie jeder einzelne bereitgestellt wird. 50.0% exponieren einen Remote-Endpunkt, eine URL, mit der sich Ihr KI-Agent über das Netzwerk verbindet, sodass der Code auf dem System eines Dritten läuft und Sie nur die zurückgelieferten Ergebnisse sehen. Die andere Hälfte, 48.3%, sind lokale Pakete, die auf Ihrem eigenen System laufen, wo Sie sie prüfen können. Genau diese Aufteilung ist die Sicherheitsfrage, die in jeder MCP-Installation steckt: Binden Sie eine Bibliothek ein, die Sie kontrollieren, oder verdrahten Sie Ihren Agenten mit dem Server eines Fremden? Darüber hinaus fordern 30.5% der Server Zugangsdaten an, bevor sie ausgeführt werden, und die Remote-Hälfte löst auf 7,420 verschiedene Drittanbieter-Hosts auf. Keine dieser Zahlen nennt einen Server, ein Unternehmen oder eine Person. Sie sind die Basiswerte eines Ökosystems, das die meisten Teams schneller übernehmen, als sie es auditieren.

Was ein Remote-MCP-Server wirklich ist

Das Model Context Protocol ist die Anbindung, über die ein KI-Agent externe Tools aufrufen kann: ein Ticket lesen, eine Datenbank abfragen, einen Pull Request öffnen. Ein Server bietet eine Reihe von Tools an, der Agent wählt eines aus, sendet Argumente und liest die Antwort zurück in seinen Arbeitskontext. Es gibt zwei Wege, wie ein solcher Server erreichbar ist. Ein lokaler Server ist ein Paket auf npm, PyPI oder als OCI-Image, das Sie selbst installieren und ausführen; er kommuniziert mit dem Agenten über stdio auf Ihrem eigenen System. Ein Remote-Server ist eine URL. Ihr Agent baut eine Verbindung dazu auf, streamt Tool-Aufrufe hinaus und Ergebnisse zurück.

Der Unterschied ist die Vertrauensgrenze (Trust Boundary). Bei einem lokalen Server befinden sich der Code, die Abhängigkeiten und die ausgehenden Netzwerkaufrufe auf Hardware, die Sie kontrollieren und prüfen können. Bei einem Remote-Server liegt der Code auf der Infrastruktur des Betreibers. Sie sehen ihn nicht, Sie können nicht die exakte Version per Hash pinnen, wie Sie es bei einem Paket tun würden, und jedes Argument, das Ihr Agent sendet, zusammen mit dem gesamten Kontext des Aufrufs, gelangt zu diesem Betreiber. Den zurückgelieferten Tool-Ergebnissen vertraut der Agent anschließend, als wären sie seine eigene Logik. Genau auf diesem Rückweg setzen Tool-Poisoning und indirekte Prompt Injection an.

Wie die 19,321 veröffentlichten Server bereitgestellt werden

Hier ist der gesamte Bestand, aufgeschlüsselt nach der Art und Weise, wie jeder Server Ihren Agenten erreicht. Der Remote-Anteil steht im Mittelpunkt, da hier die Vertrauensgrenze Ihr eigenes System verlässt.

Die genaue Verteilung verdient eine klare Betrachtung, da die gerundeten Hälften ein Detail verdecken. Von den 19,321 Servern sind 8,642 (44.7%) ausschließlich remote, ohne lokales Paket, das Sie stattdessen ausführen könnten. Weitere 1,014 (5.2%) bieten beides an, einen Remote-Endpunkt und ein lokales Paket, sodass Sie wählen können. 9,323 (48.3%) sind reine lokale Pakete, und ein Restanteil 342 (1.8%) gab weder ein Paket noch einen funktionierenden Endpunkt an. Wenn ein Server also remote ist, hat er meist keinen Fallback: Ihn zu nutzen bedeutet, den Endpunkt des Drittanbieters zu akzeptieren oder ihn gar nicht zu nutzen.

Die Anforderung von Zugangsdaten: Ein Drittel der Server verlangt Ihre Schlüssel

Ein Tool, das Ihre GitHub-Issues liest oder Ihren Observability-Stack abfragt, muss sich irgendwo authentifizieren, daher sind Zugangsdaten-Anforderungen zu erwarten. Die Zahl ist dennoch bemerkenswert: 30.5% der veröffentlichten Server, genau 5,888 davon, deklarieren mindestens einen geheimen Zugangsschlüssel, etwa eine Umgebungsvariable oder einen Auth-Header, deren Name ein Token enthält wie KEY, TOKEN, SECRET, PASSWORD, oder AUTH. Ungefähr jeder dritte Server verlangt aktive Zugangsdaten, bevor er überhaupt irgendetwas tut.

Kombiniert man das mit dem Remote-Anteil, verschärft sich das Risiko. Wenn Sie einem lokalen Server Zugangsdaten übergeben, verbleibt das Geheimnis in Ihrer Umgebung und das Tool nutzt es von Ihrem System aus. Übergeben Sie Zugangsdaten an einen Remote-Server, leiten Sie diese entweder an den Betreiber weiter oder bevollmächtigen den Betreiber, in Ihrem Namen zu handeln. In beiden Fällen wird der Betreiber zum Besitzer Ihres Schlüssels. Wenn dieser Betreiber nachlässig mit Logs umgeht oder kompromittiert wird, wird der für ein Tool gedachte Schlüssel zum Werkzeug eines Angreifers. Das Prinzip der minimalen Rechtevergabe (Least Privilege) ist hier Pflicht: Ein Server sollte nur ein Token erhalten, das exakt auf das beschränkt ist, was seine Tools benötigen, und nichts darüber hinaus.

Wo die Remote-Endpunkte tatsächlich gehostet werden

Die Remote-Hälfte verteilt sich nicht auf eine Handvoll vertrauenswürdiger Clouds. Die 9,656 Server mit einem Remote-Endpunkt verteilen sich auf 7,420 verschiedene Hosts. Der Long-Tail ist real: 98.1% dieser Hosts betreiben genau einen Server, was eine Vielzahl unabhängiger Betreiber bedeutet, die Sie jeweils einzeln überprüfen müssten. Wenn Ihre Agenten das Registry unkritisch übernehmen würden, würden sie Verbindungen zu Tausenden von verschiedenen Endpunkten aufbauen, von denen die meisten von Parteien betrieben werden, von denen Sie noch nie gehört haben.

Am anderen Ende der Verteilung liegt die Konzentration. Der mit Abstand größte Gateway-Host bedient 13.5% aller Remote-Server, und die zehn aktivsten Hosts machen zusammen 18.9% aller Remote-Endpunkte aus. Etwa ein Viertel der Remote-Server nutzt einen gemeinsamen Multi-Tenant-Host statt einer eigenen Domain. Das ist die Kehrseite jedes Marktplatzes: Einige wenige Aggregatoren wickeln einen Großteil des Verkehrs ab. Das ist bequem, bedeutet aber auch, dass ein einziger Betreiber oder Ausfall einen erheblichen Teil des Ökosystems betrifft. Wir nennen diese Hosts nicht namentlich; wichtig ist die Struktur, nicht die konkrete Adresse.

Die Entwarnung: Versteckter Unicode

Ein gut dokumentierter MCP-Angriff verbirgt Anweisungen für den Agenten in den Textfeldern, die ein Server veröffentlicht, indem unsichtbare Zeichen genutzt werden: Unicode-Tag-Codepoints, Zero-Width Joiner, bidirektionale Steuerzeichen, ANSI-Escapes. Der Agent liest sie, ein menschlicher Prüfer nicht. Wir haben jedes für das Modell sichtbare Textfeld aller 19,321 Server auf diese Codepoint-Klassen gescannt. Das Ergebnis ist eine saubere Null: 0 von 19,321 Servern enthielten nicht druckbare Zeichen oder Steuerzeichen aus der Injection-Klasse in ihren Registry-Metadaten.

Das sind gute Nachrichten mit einer gewissen Einschränkung, und diese Einschränkung ist wichtig. Das Registry veröffentlicht den Namen, den Titel und die Beschreibung eines Servers, nicht aber die Beschreibungen der einzelnen Tools, die er bereitstellt. Genau diese Felder werden jedoch bei jedem Aufruf in den Kontext des Agenten geladen und stellen das lukrativere Ziel für Angriffe mit versteckten Anweisungen dar. Unser Null-Ergebnis zeigt, dass die eigene Metadatenschicht des Registry aktuell sauber ist. Es bedeutet nicht, dass die Tools hinter diesen Servern es auch sind, da das Registry diese Oberfläche nicht für ein passives Auslesen bereitstellt. Das ehrliche Fazit fällt daher präzise aus: Auf der Schicht, die wir messen können, ohne fremde Server zu kontaktieren, wird der Kanal über unsichtbare Zeichen nicht genutzt.

Die Perspektive eines Angreifers auf dieses Registry

Betrachten Sie diese Zahlen aus der Perspektive dessen, der entscheidet, ob eine Schutzmaßnahme relevant ist. Ein Angreifer, der über KI-Tools in ein Unternehmen eindringen will, hat zwei naheliegende Optionen, und die Bestandsaufnahme zeigt, dass beide im großen Stil machbar sind. Die erste besteht darin, einen eigenen Server zu betreiben: Veröffentlichen Sie etwas Nützliches, sorgen Sie für die Installation, und schon empfangen Sie legitim jede Anfrage, die der Agent sendet, und kontrollieren jedes Ergebnis, das er liest. Da die Hälfte des Registry bereits remote ist, erweckt ein weiterer Remote-Server keinen Verdacht. Die zweite Option besteht darin, einen Betreiber zu kompromittieren, der bereits das Vertrauen vieler Teams genießt, und die Konzentration an der Spitze der Host-Verteilung zeigt, wo sich dieser Ansetzpunkt befindet.

Die Zahl der geforderten Zugangsdaten wirkt als Multiplikator. Einem Drittel der Server wird bereits ein Geheimnis anvertraut. Ein manipulierter oder übernommener Server beschränkt sich also nicht darauf, Datenverkehr mitzulesen; er kann über Schlüssel verfügen, die bis in die Systeme hinter den Tools reichen. Dies ist dieselbe Erweiterung der Angriffsfläche, die wir in unserem Leitfaden dazu beschreiben, was Angreifer tatsächlich über Ihr Unternehmen sehen können, nur eine Schicht nach innen verlagert: Die Angriffsfläche umfasst nicht mehr nur Ihr öffentliches DNS und Ihre Dienste, sondern die Gesamtheit der externen Server, mit denen Ihre Agenten kommunizieren dürfen. Jeder einzelne davon ist eine Abhängigkeit, und über Abhängigkeiten beginnen moderne Sicherheitsvorfälle.

Wie Sie Remote-MCP-Server unter Kontrolle halten

Nichts davon spricht grundsätzlich gegen Remote-MCP-Server. Es spricht dafür, sie wie die Drittanbieter-Abhängigkeiten zu behandeln, die sie nun einmal sind. Wenn Sie Agenten mit MCP-Tools betreiben, sollten Sie folgende Maßnahmen ergreifen.

• Führen Sie eine Allowlist, nutzen Sie kein offenes Registry. Legen Sie fest, welche konkreten Server Ihre Agenten nutzen dürfen, und pinnen Sie diese. Wenn die Hälfte des Registry remote ist, bedeutet das, dass Sie der Hälfte der Betreiber bewusst vertrauen müssen. Entscheiden Sie also gezielt, anstatt Tools nach der Entdeckung einfach zu installieren.
• Bevorzugen Sie lokal, wenn beides existiert. Bei den 5.2%, die sowohl ein Paket als auch einen Endpunkt anbieten, verbleiben der Code und der Datenverkehr beim lokalen Paket auf Ihrem System. Nutzen Sie diese Option, wenn das Tool nicht zwingend remote laufen muss.
• Beschränken Sie alle Zugangsdaten exakt auf das jeweilige Tool. Da 30.5% der Server Zugangsdaten verlangen, stellen Sie Tokens aus, die genau auf das beschränkt sind, was die Tools des Servers benötigen. Rotieren Sie diese und übergeben Sie niemals weitreichende Schlüssel an einen Server, den Sie nicht auditiert haben.
• Behandeln Sie Tool-Ausgaben als nicht vertrauenswürdige Eingaben. Ergebnisse, die von einem Server zurückgeliefert werden, können Anweisungen enthalten, die auf Ihren Agenten abzielen. Schränken Sie ein, was der Agent damit tun darf, und lassen Sie Tool-Ergebnisse nicht stillschweigend privilegierte Aktionen ausführen.
• Wissen Sie, wer am anderen Ende sitzt. Ein Remote-Endpunkt führt zum Host einer bestimmten Partei. Kennen Sie bei den Servern, von denen Sie abhängen, den Betreiber und denken Sie daran, dass die meisten Hosts in diesem Registry nur einen einzigen Server einer einzelnen Partei betreiben.

Methodik, damit Sie den Zahlen vertrauen können

Der Datensatz stammt aus unserer eigenen Erhebung auf Basis einer öffentlichen Quelle und enthält ausschließlich aggregierte Daten. Wir haben am 31. Juli 2026 die öffentliche Listing-API des offiziellen Model Context Protocol Registry abgefragt und den gesamten Katalog durchgegangen, wobei 62,430 Versionsdatensätze erfasst wurden. Diesen Bestand haben wir reduziert auf die 19,321 Server, die als aktuelle, neueste Version markiert sind, was dem bereinigten Live-Bestand entspricht und die Grundgesamtheit für alle Prozentangaben hier bildet. Die Bereitstellungsart wurde anhand der von jedem Server deklarierten Pakete und Remote-Endpunkte klassifiziert; die Zahl der Zugangsdaten erfasst jede deklarierte Umgebungsvariable oder jeden Auth-Header, deren Name ein Token mit Geheimnis-Charakter enthält; die Host-Konzentration wurde durch Auflösung des Hostnamens jedes Remote-Endpunkts ermittelt; und der Scan auf versteckte Zeichen prüfte jedes Textfeld gegen den Unicode-Tag-Block, Zero-Width- und bidirektionale Formatzeichen, ANSI-Escapes sowie weitere Steuer- und Sonderzeichen.

Wir haben ausschließlich die öffentliche API des Registry ausgelesen. Wir haben uns mit keinem einzigen der aufgeführten Server verbunden, keine Anfrage an den Endpunkt eines Betreibers gesendet und keine Daten über Einzelpersonen erhoben. Das Auslesen eines öffentlichen Katalogs ist eine passive Maßnahme; das Kontaktieren der darin enthaltenen Hosts wäre es nicht, und das haben wir nicht getan.

Was diese Untersuchung nicht beweist

Eine Zahl ohne Kontext ist Marketing, daher folgen hier die Grenzen dieser Daten.

• Es handelt sich um ein einzelnes Registry. Das offizielle Registry ist der zentrale Katalog, aber es gibt Server, die dort nie veröffentlicht werden, und andere Verzeichnisse führen eigene Listen. Dies misst den veröffentlichten, auffindbaren Bestand, nicht jeden existierenden Server.
• Deklariert, nicht beobachtet. Bereitstellungsform und Zugangsdaten basieren auf den Angaben, die jeder Server in seinem Registry-Eintrag macht. Ein Server könnte ein Geheimnis verlangen, das er nicht aufgeführt hat, oder ein Paket anbieten, das er nicht wirklich unterstützt. Wir haben das Manifest gemessen, keine Live-Installation.
• Remote ist eine Angriffsfläche, kein Urteil. Ein Remote-Server ist nicht unsicher, nur weil er remote ist. Viele werden von professionellen Betreibern gewissenhaft betrieben. Die 50.0% beschreiben den Umfang der Vertrauensentscheidung, nicht die Anzahl böswilliger Akteure.
• Das Null-Ergebnis ist kontextgebunden. Null Treffer bei versteckten Zeichen betreffen nur die Felder auf Serverebene im Registry. Die Beschreibungen pro Tool, die bei jedem Aufruf in einen Agenten geladen werden, sind für ein passives Auslesen nicht öffentlich zugänglich. Dies ist also kein Freibrief für die Tools selbst.
• Es ist eine Momentaufnahme. Das Registry wächst täglich. Diese Zahlen beschreiben den Stand vom 31. Juli 2026, keinen Trend, und ein erneuter Abruf im nächsten Monat wird andere Werte liefern.

Häufig gestellte Fragen

Ist die Nutzung von Remote-MCP-Servern sicher?

Ein Remote-MCP-Server ist nur so sicher wie der Betreiber, der ihn betreibt, da Ihr Agent Anfragen an den Endpunkt dieses Betreibers sendet und Ergebnisse von dort liest. In dieser Bestandsaufnahme waren 50.0% der Server remote, und alle nutzten HTTPS, sodass die Übertragung nicht die Lücke ist. Das Problem ist Vertrauen. Pinnen Sie die Server, die Sie geprüft haben, und vergeben Sie jeweils Zugangsdaten nach dem Prinzip der minimalen Rechtevergabe.

Was ist der Unterschied zwischen einem lokalen und einem Remote-MCP-Server?

Ein lokaler Server läuft als Paket auf Ihrem eigenen System, sodass Sie den Code und die Netzwerkaufrufe prüfen können. Ein Remote-Server ist eine URL, mit der sich Ihr Agent verbindet, sodass der Code auf der Infrastruktur eines Dritten läuft und Sie nur die Antworten sehen. In der Bestandsaufnahme waren 48.3% reine lokale Pakete, 44.7% reine Remote-Server und 5.2% boten beides an.

Wie viele MCP-Server gibt es?

Das offizielle Registry führte 19,321 eindeutige veröffentlichte Server, als wir am 31. Juli 2026 den gesamten Bestand abriefen, wobei jeweils nur die neueste Version gezählt wurde. Es wächst schnell, betrachten Sie diese Zahl daher als stichtagbezogene Momentaufnahme.

Benötigen MCP-Server API-Schlüssel oder Zugangsdaten?

Viele ja. In der Bestandsaufnahme deklarierten 30.5% der Server mindestens einen geheimen Zugangsschlüssel, sodass ungefähr jeder dritte Server nach einem Schlüssel oder Token verlangt, bevor er läuft. Das vergrößert den Schadensradius im Falle einer Kompromittierung des Servers oder seines Betreibers.

Kann ein MCP-Server Ihre Daten stehlen?

Ein böswilliger oder kompromittierter Server kann jede Anfrage lesen, die Ihr Agent an ihn sendet, und präparierte Ergebnisse in den Kontext des Agenten zurückliefern. Auf diesem Prinzip beruhen Tool-Poisoning und Prompt-Injection. Er kann nicht über die Tools und Zugangsdaten hinausgreifen, die Sie ihm gewähren, daher sind minimale Rechtevergabe und eine geprüfte Allowlist die Verteidigung.

Wird das MCP-Registry geprüft?

Nein. Ein Eintrag ist lediglich eine Veröffentlichung, kein Sicherheitsaudit. Das Registry erfasst, wo ein Server gehostet wird, nicht ob dessen Betreiber vertrauenswürdig ist. Remote-Server lösten auf 7,420 Hosts auf, von denen 98.1% jeweils nur einen einzigen Server betrieb. Der Großteil der Lieferkette besteht somit aus Betreibern, die Sie individuell überprüfen müssten.

Welche Sicherheitsrisiken bergen MCP-Server?

Die Hauptrisiken sind die Rückgabe präparierter Tool-Ausgaben an Ihren Agenten, ein Remote-Betreiber, der jede Anfrage sieht und protokolliert, die Offenlegung von Zugangsdaten bei der Anforderung von Schlüsseln sowie Konzentrationsrisiken, wenn viele Server hinter einem einzigen Gateway liegen. In dieser Bestandsaufnahme waren komplexe Tricks wie versteckter Unicode in den Registry-Metadaten nicht vorhanden (0 von 19,321), sodass das akute Risiko in Vertrauen und Zugriff liegt, nicht in der Zeichencodierung.

Weiterführende Artikel

• Was können Angreifer tatsächlich über Ihr Unternehmen sehen? Die Angriffsfläche, die in diesem Beitrag nach innen auf Ihre Agenten-Tools erweitert wird.
• Reicht p=none aus? Dieselbe passive Messmethode, angewendet auf E-Mail-Authentifizierung.
• Autorisierung geht vor. Warum jede von uns veröffentlichte Messung im rechtlich zulässigen Rahmen bleibt.