MCP-Server-Sicherheitslücken 2026:
30 CVEs, Keine Authentifizierung, Keine Verschlüsselung

Zwischen Januar und Februar 2026 offenbarten Sicherheitsforscher 30 CVEs gegen Model Context Protocol (MCP) Server — die Infrastrukturschicht, die KI-Coding-Assistenten mit Datenbanken, APIs und Dateisystemen verbindet. Der höchste Schweregrad erreichte CVSS 9.6 (Kritisch), was Remote-Code-Ausführung ohne Authentifizierung ermöglicht. Dies ist die Sicherheitskrise, die Agentic-AI-Entwickler verstehen müssen, bevor sie die Produktion trifft.

Was ist MCP und warum ist es für die Sicherheit wichtig?

Model Context Protocol ist Anthropics offener Standard für die Verbindung von KI-Assistenten mit externen Tools und Datenquellen. In der Praxis ist ein MCP-Server ein lokaler oder Remote-Prozess, mit dem sich Ihr KI-Coding-Assistent (Cursor, Claude Desktop, VS Code mit GitHub Copilot, Windsurf, Cline) über JSON-RPC verbindet, um Tools wie „diese Datei lesen", „diese Datenbank abfragen", „diesen API-Endpunkt abrufen" aufzurufen.

Das Sicherheitsproblem ist strukturell. MCP wurde für Entwicklerkomfort konzipiert, nicht für Sicherheit in der Produktion. Die Spezifikation hat keinen integrierten Authentifizierungsmechanismus, keine erforderliche Transportverschlüsselung und keinen Standard für Berechtigungsbegrenzung. Jede Sicherheitskontrolle ist als Implementierungsdetail überlassen — und viele Implementierungen lassen sie ganz aus.

Die 30 CVEs: Was wurde gefunden

Sicherheitsforscher von mehreren Unternehmen führten zwischen Januar und Februar 2026 systematische Audits beliebter MCP-Server und des Protokolls selbst durch. Die 30 offengelegten CVEs fielen in sechs Kategorien:

Warum 38% der MCP-Server ohne Authentifizierung haben

Die Authentifizierungslücke ist nicht Entwickler-Nachlässigkeit — es ist ein Dokumentations- und Designproblem. Die offizielle MCP-Spezifikation schreibt keine Authentifizierung vor, und die Referenzimplementierungs-Beispiele enthalten sie nicht. Entwickler, die die Schnellstart-Dokumentation befolgen, versenden unauthentifizierte Server, weil die Dokumentation es ihnen nicht mitteilt.

Die Situation wird durch das Deployment-Modell verschärft. Die meisten MCP-Server laufen lokal — auf der Workstation des Entwicklers, auf localhost, in einem Docker-Container. Die implizite Annahme ist, dass lokaler Zugriff gleich vertrautem Zugriff ist. Diese Annahme bricht in drei häufigen Szenarien auf:

• Multi-User-Entwicklungsumgebungen (gemeinsame Cloud-VMs, Pair-Programming-Setups), bei denen „localhost" für mehrere Benutzer zugänglich ist
• Browser-basierte Angriffe, bei denen eine gefährdete Webseite Anfragen an 127.0.0.1:3000 aus der Browser-Sandbox stellt
• Malware auf der Entwickler-Maschine, die MCP-Server entdeckt und mit ihnen kommuniziert, um ihre Fähigkeiten zu erweitern

Remote-MCP-Deployments — bei denen der Server auf einem Cloud-Host läuft und der KI-Assistent sich über HTTPS verbindet — sind seltener, aber sehen sich das gesamte Spektrum von Webanwendungs-Sicherheitslücken gegenüber, verstärkt durch die fehlende Standard-Auth in der MCP-Spec.

Das PII-Risiko in ungeskützten MCP-Deployments

MCP-Server haben konstruktionsbedingt Zugriff auf Entwickler-Kontext: den Codebase, die Datenbankverbindungs-Strings, die API-Schlüssel, die Kundendaten-Dateien. Das ist, was sie mächtig macht. Es macht sie auch zu hochkarätigen Zielen.

Wenn ein KI-Coding-Assistent einen MCP-Server aufruft, um eine Datenbank abzufragen oder eine Datei zu lesen, kann es sein, dass persönliche Daten weitergeleitet werden — Kundennamen, E-Mail-Adressen, Finanzunterlagen — über den MCP-JSON-RPC-Transport. Wenn dieser Transport unauthentifiziert und unverschlüsselt ist, kann jeder Beobachter im lokalen Netzwerk (oder jeder Prozess auf der lokalen Maschine) diese Daten lesen.

Die Tool-Poisoning-CVEs sind besonders gefährlich für PII. Ein Angreifer, der eine bösartige Tool-Beschreibung in einen MCP-Server einschleusen kann — zum Beispiel durch Ändern einer gemeinsamen MCP-Konfigurationsdatei in einem Repository — kann jeden Entwickler-KI-Assistenten anweisen, sensible Daten in seinem nächsten ausgehenden Tool-Call einzubeziehen. Der Entwickler sieht die Ausleitung niemals; sie sieht aus wie normales KI-Assistent-Verhalten.

MCP-Sicherheitshärtungs-Checkliste

Bis die MCP-Spezifikation aktualisiert wird, um obligatorische Authentifizierung und Transportsicherheit zu beinhalten, müssen Entwickler Kontrollen auf der Deployment-Schicht implementieren. Hier ist die minimale Härtungs-Checkliste für Production-MCP-Deployments:

• Token-Authentifizierung an jedem Endpunkt — Fügen Sie Bearer-Token-Validierung zu allen MCP-Server-Routen hinzu. Generieren Sie beim Start ein zufälliges 32-Byte-Geheimnis, speichern Sie es nur in Umgebungsvariablen, validieren Sie bei jeder Anfrage. Niemals hardcodieren.
• TLS für alle Remote-Deployments — Wenn Ihr MCP-Server nicht auf localhost läuft, muss er HTTPS verwenden. Verwenden Sie Let's Encrypt oder ein verwaltetes Zertifikat. Setzen Sie MCP niemals über einfaches HTTP auf einen Remote-Host ein.
• Nur Localhost-Bindung — Lokale MCP-Server sollten sich an 127.0.0.1 binden, nicht an 0.0.0.0. Bindung an alle Interfaces setzt den Server dem gesamten lokalen Netzwerk aus.
• Tool-Beschreibungs-Integrität — Wenn Ihr MCP-Server Tool-Beschreibungen aus externen Quellen lädt (Konfigurationsdateien, Remote-URLs, Benutzereingaben), validieren und desinfizieren Sie sie vor der Verwendung. Führen Sie niemals Tool-Beschreibungen aus nicht vertrauenswürdigen Quellen ohne Überprüfung aus.
• Prinzip des geringsten Privilegs für Tools — Jedes MCP-Tool sollte die minimalen Berechtigungen haben, die erforderlich sind. Ein Datei-Lesevorkommen sollte keine Schreib-Berechtigungen haben. Ein Datenbank-Tool sollte eine schreibgeschützte Verbindung für Lesevorgänge verwenden.
• PII-Anonymisierung auf der Protokoll-Ebene — Leiten Sie alle MCP-Ein- und Ausgaben über einen PII-bewussten Proxy (z. B. den anonymize.dev MCP-Server) weiter, der persönliche Daten entfernt, bevor sie in den KI-Modell-Kontext eintreten und bevor sie in Tool-Call-Parametern erscheinen.
• Audit-Logging für Tool-Calls — Protokollieren Sie jeden Tool-Call mit Zeitstempel, Tool-Name, Aufrufer-Identität (falls authentifiziert) und Parameter-Hash (nicht die vollständigen Parameter, die sensible Daten enthalten können). Überwachen Sie auf anomale Tool-Call-Muster.
• Abhängigkeits-Pinning und Integritätsprüfungen — MCP-Server-Pakete sind npm/pip-Abhängigkeiten. Heften Sie exakte Versionen fest und überprüfen Sie Prüfsummen. Die Supply-Chain-Angriffsfläche für MCP-Tooling ist derzeit nicht geprüft.
• Separate MCP-Instanzen pro Projekt — Verwenden Sie nicht eine einzelne MCP-Server-Konfiguration über Projekte mit unterschiedlichen Datensensitivitätsebenen hinweg. Ein Server mit Zugriff auf Produktionskundendaten sollte nicht denselben Agenten-Kontext wie eine Entwicklungs-Sandbox bedienen.
• Regelmäßige CVE-Überwachung — Abonnieren Sie die @modelcontextprotocol GitHub-Sicherheitsempfehlungen und die relevanten Paket-Sicherheitsempfehlungen (@anthropic-ai/mcp-server-*, Community-Pakete). Die 30-CVE-Welle ist die erste, nicht die letzte.

Wie anonymize.dev die strukturelle Sicherheitslücke von MCP adressiert

Der anonymize.dev MCP-Server funktioniert als Privacy-Proxy in der MCP-Protokoll-Kette. Anstatt Ihren KI-Assistenten direkt mit Ihren Tools zu verbinden, leiten Sie die Verbindung über den anonymize.dev MCP-Server weiter, der:

1. Alle eingehenden Tool-Call-Parameter abfängt und mit 340+ Entity-Type-Detektoren über 48 Sprachen auf PII analysiert
2. Identifizierte PII mit strukturierten Platzhaltern ([PERSON_1], [EMAIL_1], usw.) ersetzt, bevor die Weiterleitung an das zugrunde liegende Tool weitergegeben wird
3. Alle Tool-Antworten abfängt und deanonymisiert sie, bevor sie an den KI-Assistenten zurückgegeben werden
4. Einen verschlüsselten Session-Mapping-Speicher verwaltet, sodass die Hin- und Rückweg-Deanonymisierung verlustfrei ist

Diese Architektur bedeutet, dass selbst wenn der zugrunde liegende MCP-Server gefährdet ist — durch Tool-Poisoning, Pfad-Traversal oder unauthentifizierten Zugriff — der Angreifer nur deanonymisierte Platzhalter sieht, nicht echte persönliche Daten. Das wertvollste Ausleitziel (PII) ist strukturell auf der Protokoll-Ebene abwesend.

tool_call("query_db", {"where": "email = 'alice@company.com'"})

tool_call("query_db", {"where": "email = '[EMAIL_1]'"})

Der anonymize.dev-Ansatz beseitigt nicht die Notwendigkeit für Authentifizierung und TLS — diese Kontrollen sollten immer noch implementiert werden. Aber es bietet die kritische Daten-Schicht-Abwehr, die die MCP-Spezifikation selbst nicht mandatieren kann: Sicherstellung, dass selbst ein vollständig gefährdetes MCP-Deployment keine PII zum Ausleihen hat.