Eine Zahl, die man nicht ungeprüft übernehmen sollte – und warum sie trotzdem stimmt
Zuerst die Quellenlage, weil sie für die Einordnung entscheidend ist. Enkrypt AI hat in den zwei Monaten vor der Anaconda-Übernahme 25.000 MCP-Server mit insgesamt 268.000 Werkzeugen gescannt und dabei mehr als 143.000 Schwachstellen gefunden – 73 Prozent der Server betroffen. Diese Zahl wurde in derselben Pressemitteilung verwendet, die die eigene Übernahme ankündigte. Eine Firma, die zeigt, wie gefährlich die Lage ist, und zwei Monate später genau dafür gekauft wird: Diese Konstellation verdient von Natur aus Skepsis, unabhängig davon, ob die Zahl am Ende zutrifft.
Sie trifft zu – nur eben nicht nur nach Aussage der interessierten Partei. Equixly fand in eigenen Tests bei 43 Prozent der geprüften Server eine Anfälligkeit für Command Injection und bei 30 Prozent für SSRF (Server-Side Request Forgery, bei der ein Server dazu gebracht wird, Anfragen an Ziele zu stellen, die eigentlich nicht erreichbar sein sollten). Endor Labs untersuchte 2.614 MCP-Implementierungen und fand bei 82 Prozent Dateioperationen, die anfällig für Pfadtraversierung sind – ein Fehler, bei dem ein Angreifer über manipulierte Dateipfade auf Bereiche außerhalb des vorgesehenen Verzeichnisses zugreifen kann. BlueRock Security prüfte über 7.000 Server und fand bei 36,7 Prozent SSRF-Schwachstellen. Eine akademische Untersuchung (Hasan u. a.) fand über 1.899 Server hinweg eine Tool-Poisoning-Rate von rund 5,5 Prozent. Trend Micro entdeckte im Juli 2025 zunächst 492 öffentlich im Internet erreichbare MCP-Server ganz ohne Authentifizierung oder Verschlüsselung – bei einer Nachzählung war die Zahl auf 1.467 gestiegen.
Fünf voneinander unabhängige Forschungsgruppen, unterschiedliche Methodik, unterschiedliche Stichproben – und durchgehend zweistellige bis hohe zweistellige Prozentsätze an Servern mit gravierenden Schwachstellen. Die konkrete Zahl 143.000 mag Marketing-Timing gewesen sein. Das zugrunde liegende Problem ist es nicht.
Warum das kein neues KI-Risiko ist – sondern ein altes an neuer Stelle
Der eigentlich bemerkenswerte Befund liegt nicht in der Häufigkeit, sondern in der Art der Fehler. SSRF, Pfadtraversierung, fehlende Authentifizierung: Das sind keine exotischen, KI-spezifischen Angriffe. Es sind die immer gleichen Grundfehler der Web- und API-Sicherheit, die seit rund zwanzig Jahren in Sicherheits-Schulungen behandelt werden – falsch validierte Eingaben, offene Endpunkte ohne Zugriffskontrolle, Vertrauen in Pfadangaben, die eigentlich geprüft werden müssten. Sie sind bei MCP-Servern nicht deshalb so verbreitet, weil KI-Agenten grundsätzlich unsicherer wären als andere vernetzte Software. Sie sind so verbreitet, weil ein neues Protokoll in kurzer Zeit von sehr vielen Teams implementiert wurde, die unter Zeitdruck standen, ein neues Feature auszuliefern – und dabei dieselben Fehler erneut gemacht haben, die die Sicherheitsbranche bei jeder neuen, schnell wachsenden Schnittstellen-Technologie beobachtet.
Diese Einordnung ist keine Verharmlosung. Sie ist im Gegenteil der Grund, warum sich das Problem vergleichsweise gut lösen lässt: Es sind bekannte Fehlerklassen mit bekannten Gegenmaßnahmen, keine neue Kategorie von Risiko, für die erst Lösungen entwickelt werden müssten. Wer MCP-Server wie jede andere netzwerkerreichbare API behandelt – mit Authentifizierung, Eingabevalidierung, Zugriffsbeschränkung – schließt den größten Teil der gefundenen Lücken.
Die eine Angriffsart, die wirklich neu ist – und für alte Scanner unsichtbar bleibt
Eine Kategorie aus der Liste verdient eine andere Behandlung: Tool-Poisoning. Jedes MCP-Werkzeug hat eine Beschreibung – einen Fließtext, der dem Sprachmodell erklärt, was das Werkzeug tut und wann es genutzt werden soll. Diese Beschreibung ist selbst Angriffsfläche. Ein manipulierter Beschreibungstext kann versteckte Anweisungen enthalten, die das Modell befolgt, ohne dass ein Mensch sie je zu Gesicht bekommt – etwa die Anweisung, bei jeder Ausführung zusätzlich eine bestimmte Aktion auszuführen, die mit der eigentlichen Aufgabe nichts zu tun hat.
Der Grund, warum das kein reines Wiederauftreten alter Fehler ist: Klassische Sicherheits-Scanner prüfen Code – Syntax, bekannte Schwachstellenmuster, Datenflüsse. Eine Werkzeugbeschreibung ist aber natürlicher Text, kein Code, und ihre Wirkung entfaltet sich erst im Sprachmodell, das sie interpretiert. Ein Scanner, der nach klassischen Mustern sucht, hat hier grundsätzlich nichts zu finden – die Schwachstelle liegt in der Bedeutung, nicht in der Syntax. Das ist der Teil des Problems, der tatsächlich neue Prüfverfahren braucht, keine altbekannten.
Ein realer Vorfall, kein Gedankenexperiment
Wie konkret das werden kann, zeigt ein bereits dokumentierter Fall aus der Software-Lieferkette. Im September 2025 identifizierte die Sicherheitsfirma Snyk eine manipulierte Version des populären MCP-Pakets postmark-mcp. Die veränderte Version funktionierte nach außen unauffällig – verarbeitete E-Mails wie erwartet – und schickte im Hintergrund zusätzlich eine Kopie jeder einzelnen verarbeiteten Nachricht per BCC an eine externe Adresse. Wer das Paket in eine bestehende Automatisierung eingebunden hatte, bemerkte den Datenabfluss nicht, weil die eigentliche Funktion weiterhin normal lief. Das ist exakt das Muster, das Sicherheitsforscher bei Tool-Poisoning beschreiben: unauffälliges Verhalten nach außen, eine zusätzliche, nicht autorisierte Handlung im Hintergrund.
Auch die Zahl der offiziell dokumentierten Schwachstellen bestätigt, dass es sich nicht um vereinzelte Laborfunde handelt. JFrogs Sicherheitsteam legte im Juli 2025 eine Lücke offen, die nach eigenen Angaben über 437.000 Umgebungen betraf. Check Point dokumentierte separat eine als „MCPoison“ bezeichnete Schwachstelle. Allein in einem 60-Tage-Fenster Anfang 2026 wurden über 30 weitere CVEs zu MCP-Implementierungen gemeldet, rund 43 Prozent davon mit Command-Injection-Mustern – demselben Fehlertyp, den auch Equixly in seinen eigenen Scans fand.
Was die Anaconda-Übernahme selbst über den Markt verrät
Unabhängig von der einzelnen Zahl ist die Übernahme selbst ein Signal. Anaconda integriert Enkrypts Werkzeuge – Pre-Deployment-Red-Teaming über mehr als 300 Angriffskategorien, Laufzeit-Schutzmechanismen, Compliance-Automatisierung für NIST-Rahmenwerke und den EU AI Act – direkt in seine Plattform. Das ist bezeichnend: MCP-Sicherheit wird gerade nicht mehr als Spezialthema für Sicherheitsforscher behandelt, sondern als Standardbestandteil dessen, was eine Unternehmensplattform mitbringen muss, um in regulierten Branchen überhaupt eingesetzt werden zu können. Für die eigene Einschätzung heißt das: Wenn Plattformanbieter dieses Thema bereits in ihre Compliance-Automatisierung einbauen, ist es kein Nischenrisiko mehr, das man auf später verschieben kann.
Was daraus praktisch folgt
Der Nutzen dieser Analyse liegt nicht darin, vor MCP zu warnen – das Protokoll ist aus gutem Grund zum Standard geworden, weil es genau das strukturierte Anbinden von KI-Agenten an eigene Systeme löst, das vorher jede Integration einzeln lösen musste. Der Punkt ist, MCP-Server mit derselben Sorgfalt zu behandeln wie jede andere netzwerkerreichbare Schnittstelle im eigenen Haus – nicht als Konfigurationsdetail, das man einmal einrichtet und dann vergisst.
- Inventur: Welche MCP-Server sind im eigenen Unternehmen tatsächlich im Einsatz – auch die, die einzelne Teams ohne zentrale Freigabe eingerichtet haben? Diese Liste ist bei den meisten Unternehmen länger, als IT oder Sicherheitsverantwortliche vermuten.
- Klassische Absicherung zuerst: Authentifizierung für jeden Server, Eingabevalidierung, keine öffentlich ohne Zugriffsschutz erreichbaren Endpunkte. Das schließt laut den zitierten Untersuchungen den größten Teil der real gefundenen Lücken.
- Werkzeugbeschreibungen wie Code behandeln: Vor dem produktiven Einsatz prüfen, was ein MCP-Werkzeug laut seiner Beschreibung eigentlich tut – und bei Aktualisierungen eines bereits eingesetzten Pakets erneut, nicht nur beim ersten Einbau.
- Herkunft prüfen: Bei extern bezogenen MCP-Paketen (etwa aus öffentlichen Registries) dieselbe Lieferketten-Vorsicht anwenden wie bei jeder anderen Drittanbieter-Abhängigkeit auch – der Postmark-Fall zeigt, dass genau das schon einmal genutzt wurde.
Und zur Ehrlichkeit gegenüber der eigenen Quellenlage: Diese Analyse verlässt sich nicht auf die einzelne, interessengeleitete Zahl eines Anbieters, sondern auf das übereinstimmende Bild aus sechs unabhängigen Untersuchungen. Genau diese Unabhängigkeit ist es, die aus einer Pressemitteilung einen belastbaren Befund macht.