Sicherheit & Governance

MCP-Sicherheitshärtungs-Checkliste: 1.467 offengelegte Server und die Kontrollen, die sie schließen

Von IdeaBosqueZuletzt aktualisiert: 2026年7月26日

Trend Micro扫描te das Internet und fand 1.467 MCP-Server offen vor — keine Authentifizierung, keine Verschlüsselung, für jeden erreichbar. Practical DevSecOps fand, dass 82 % von 2.614 befragten Servern anfällig für Path Traversal sind. Ein Protokoll, das dafür gedacht war, KI-Agenten an Unternehmenssysteme anzubinden, wurde ohne eine Productionsicherheits-Baseline ausgeliefert, und die Deployment-Patterns beweisen es: Die meisten Teams exponierten MCP zum Internet, bevor sie es härteten. Diese Checklist ist die Baseline, die zuerst hätte kommen sollen — 12 Kontrollen über Transport, Authentifizierung, Tool-Registrierung, Runtime und Audit, jede in unter fünf Minuten verifizierbar, bevor ein MCP-Server Produktionstraffic berührt.

Kernpunkte

1.467 MCP-Server sind öffentlich zugänglich ohne Authentifizierung oder Verschlüsselung — Trend Micros korrigierter Scan, Juli 2026. 1.227 davon betreiben den SSE-Transport, den die Spezifikation 2026-07-28 mit einer 12-Monats-Deprekationsuhr ausmustert.
82% von 2.614 untersuchten MCP-Servern sind anfällig für Path Traversal, und nur 8,5% verwenden OAuth — Practical DevSecOps MCP Security Statistics 2026 Report. Die Angriffsklassen sind in eingesetzten Servern weit verbreitet, nicht theoretisch.
3 CVEs landeten im offiziellen MCP Python SDK im Juli 2026 — CVE-2026-59950 (DNS-Rebinding/CSRF), CVE-2026-52869 (unverifizierte Session-Anfragen), CVE-2026-52870 (offene Task-Handler). Die Referenzimplementierung lieferte dieselbe Klasse von Fehler wie die Community-Server.
78,3% Angriffserfolgsquote wenn 5 MCP-Server sich mit 1 Agent verbinden — Palo Alto Networks Unit 42. Fünf Server ist eine typische Bereitstellung, keine große. OX Security identifizierte einen architekturebenen RCE, der 150M+ Downloads betrifft, und die Cloud Security Alliance klassifizierte MCP-Sicherheit als systemisches Designfehler-Problem.
Die MCP 2026-07-28 Spezifikation wird am 28. Juli 2026 als final veröffentlicht — alle vier Tier-1-SDKs (TypeScript, Python, Go, C#) sprechen den neuen zustandslosen Kern, mit einer 12-Monats-Deprekationspolitik für den SSE-Transport. Migration und Härtung sind dieselbe Arbeit.

Eine Produktions-MCP-Bereitstellung, die die 12 Kontrollen dieser Checkliste besteht, ist nicht unangreifbar — kein System ist es — aber sie ist nicht mehr in der Population, die Trend Micro fand, die Practical DevSecOps scannte, oder die die Juli-CVE-Welle erfasste. Die Checkliste mappt jede Kontrolle auf die OWASP-MCP-Top-10-Kategorie, die sie adressiert, das CVE oder die Exposition, die sie verhindert, und den Verifizierungsschritt, den ein Operator in unter fünf Minuten ausführen kann. Das Microsoft Agent Governance Toolkit — die erste von einem Hyperscaler gelieferte Open-Source-Governance-Runtime mit 10/10 OWASP-MCP-Top-10-Abdeckung — ist die Referenzimplementierung. Dieser Artikel ist das operative Komplement: ein scannbares Härtungs-Review für einen Engineering-Leiter oder Plattform-Verantwortlichen, der sich darauf vorbereitet, einen MCP-Server dem Produktionsverkehr auszusetzen.

Die Angriffsfläche, in Zahlen

Das OWASP MCP Top 10 (Beta Release v0.1, Phase 3 of 5) katalogisiert 10 benannte Risikokategorien über den MCP-aktivierten System-Lebenszyklus. Die Zahlen dahinter verwandeln „Governance ist gute Praxis" in „Governance ist ein Produktions-Gate":

1.467 offengelegte Server — Trend Micros korrigierter Scan fand 1.467 öffentlich zugängliche MCP-Server ohne Authentifizierung oder Verschlüsselung, hoch von einer anfänglichen Zählung von 492. 1.227 betreiben den deprékierten SSE-Transport. Mindestens drei legen Patienten-Krankenakten über ein progress_note-Tool offen. Das execute_sql-Tool erscheint auf 70 Hosts.
82% Path-Traversal-Exposition — Practical DevSecOps maß 82% Path-Traversal-Schwachstelle und 8,5% OAuth-Adoption über 2.614 untersuchte Server. 97M+ monatliche MCP-Downloads bedeutet, dass die Exposition mit der Adoption skaliert.
150M+ Downloads betroffen von architekturem RCE — OX Security rahmte die STDIO-Befehlsinjektions-Ursache als architekturebenen Fehler ein, nicht isolierte CVEs. Die Cloud Security Alliance klassifizierte es als systemisches Designfehler-Problem in der KI-Agenten-Infrastruktur.
3 CVEs im SDK im Juli 2026 — CVE-2026-59950 (fehlende Host/Origin-Validierung, DNS-Rebinding/CSRF), CVE-2026-52869 (unverifizierte Session-Anfragen), CVE-2026-52870 (offene Task-Handler). Das offizielle Python SDK — die Referenzimplementierung, von der jeder Python-MCP-Server erbt — lieferte dieselbe Fehlerklasse wie die Community-Server, die es stützt.
3 neue Angriffsflächen in der finalen Spezifikation — backslash.security identifizierte drei neue Angriffsflächen, die durch das zustandslose Redesign in der Spezifikation 2026-07-28 eingeführt wurden. Neue Fähigkeiten schaffen neue Einstiegspunkte, die die Sicherheits-Community noch kartografiert.

Die cataam.com-Analyse rahmt den Stand der MCP-Sicherheit präzise ein: „MCP-Sicherheit befindet sich ungefähr dort, wo die Web-Sicherheit vor fünfzehn Jahren stand — die Angriffe sind alt, nur das Ziel ist neu." Die Härtungs-Checkliste unten ist die Menge von Kontrollen, die die Web-Sicherheit von 82% Path-Traversal-Exposition zu einer Baseline bewegten, bei der Produktionssysteme erwartet werden, sie zu bestehen. Dieselben Kontrollen gelten hier.

Die 12 Härtungskontrollen

Die Checkliste organisiert sich um fünf Schichten, die auf das OWASP MCP Top 10 und die Änderungen der MCP 2026-07-28 Spezifikation mappen:

Schicht 1 — Transport und Netzwerk

Kontrolle 1: SSE-zu-Streamable-HTTP-Migration. Die MCP 2026-07-28 Spezifikation wird am 28. Juli 2026 als final veröffentlicht, mit einer 12-Monats-Deprekationspolitik für den HTTP+SSE-Transport. Alle vier Tier-1-SDKs (TypeScript, Python, Go, C#) sprechen den neuen zustandslosen Kern ab Veröffentlichungstag, mit Migrationshinweisen für die brechenden Teile. Die 1.227 deprékierten SSE-Server in Trend Micros Scan sind die am stärksten betroffene Population — sie betreiben einen Transport, den die Spezifikation ausmustert. Verifizierung: prüfen Sie die Transportkonfiguration des Servers. Wenn er SSE bedient, ist er auf der Deprekationsuhr. Migrieren Sie zu Streamable HTTP, bevor das 12-Monats-Fenster schließt.

Kontrolle 2: Netzwerkisolation und Origin-Validierung. CVE-2026-59950 — bestätigt in der National Vulnerability Database — ist ein fehlender Host/Origin-Validierungs-Fehler im offiziellen MCP Python SDK. Eine Webseite, die das Opfer besucht, kann seinen lokalen MCP-Server über DNS-Rebinding und CSRF steuern. Der Browser wird zum Proxy des Angreifers in einen Loopback-Server, den der Operator für privat hielt. Verifizierung: bestätigen Sie, dass der Server Host- und Origin-Header auf jeder Anfrage validiert. Wenn der Server internet-facing ist, bestätigen Sie, dass er hinter einer Netzwerkgrenze sitzt, die direkten Zugriff von nicht vertrauenswürdigen Origins verhindert. Ein Server, der nie vom öffentlichen Internet erreichbar hätte sein sollen, darf nicht vom öffentlichen Internet zugänglich sein.

Schicht 2 — Authentifizierung und Identität

Kontrolle 3: OAuth 2.1 + OIDC-Durchsetzung. Die Spezifikation 2026-07-28 macht OAuth 2.1 plus OpenID Connect obligatorisch — ein Wechsel vom vorherigen „bringen Sie Ihr eigenes Token"-Ansatz. Der WorkOS-Authentifizierungs-Migrationsleitfaden detailiert die Anforderungen: RFC 8707 (Resource Indicators) zur Verhinderung von Token-Replay über Server, Client ID Metadata Documents ersetzen Dynamic Client Registration, Issuer-Verifizierung (RFC 9207). Der Practical DevSecOps-Befund — nur 8,5% der untersuchten Server verwenden OAuth — ist die Baseline, die diese Kontrolle anhebt. Verifizierung: prüfen Sie die Authentifizierungskonfiguration des Servers. Wenn er unauthentifizierte Anfragen akzeptiert oder statische API-Keys ohne OAuth verwendet, fällt er durch. Bestätigen Sie, dass der Server RFC 8707 Resource Indicators implementiert.

Kontrolle 4: Agenten-Identitätstrennung. Die NIST AI Agent Standards Initiative (Februar 2026) schlägt vor, Agenten als eigenständige nicht-menschliche Identitäten mit eigenem Lebenszyklus zu behandeln: Provisionierung, Attestierung, Widerruf. Die meisten Bereitstellungen authentifizieren den menschlichen Benutzer und geben diese Identität an den Agenten weiter. Wenn der Agent eine Aktion durchführt, sagt das Audit-Protokoll, der Mensch habe es getan. Verifizierung: bestätigen Sie, dass jeder Agent eigene Credentials (OAuth-Token, SPIFFE SVID) hat, die vom menschlichen Operator getrennt sind. Widerruf der Agenten-Identität sollte alle Agenten-Aufrufe stoppen, ohne den Zugriff des Menschen zu beeinträchtigen.

Schicht 3 — Tool-Registrierung und Lieferkette

Kontrolle 5: Tool-Poisoning-Scan. OWASP MCP03 nennt Tool-Poisoning ein Top-10-Risiko: Rug Pulls (ein vertrauenswürdiges Tool wird nach Installation auf eine bösartige Version aktualisiert), Schema Poisoning (die Schnittstellendefinition selbst wird korrumpiert, um das Modell irrezuführen), Tool Shadowing (ein falsches Tool fängt Aufrufe ab, die für das echte bestimmt sind). Der McpSecurityScanner des Microsoft Agent Governance Toolkits erkennt Tool-Poisoning, Typosquatting und versteckte Anweisungen — ein Demo-Tool namens read_flie (Typosquatting von read_file) mit Injektion in seiner Beschreibung erzielte 85/100 Risiko. Verifizierung: inspizieren Sie den Tool-Registrierungsprozess. Wenn Tools ohne Sicherheits-Scan registriert werden, fällt er durch. Der Scan muss Prompt-Injektions-Muster in Beschreibungen, Typosquatting gegen bekannte Tool-Namen und versteckte System-Direktiven abdecken.

Kontrolle 6: Signierte Provenienz und Abhängigkeitsüberwachung. OWASP MCP04 deckt Lieferkettenangriffe und Abhängigkeitsmanipulation ab. Die Postmark-MCP-Hintertür — der erste bösartige MCP-Server, der in freier Wildbahn entdeckt wurde — war ein legitimität aussehendes npm-Paket, das stillschweigend E-Mails abfing und exfiltrrierte. Es bestand die Registry-Prüfung. Die UpGuard-Forschung fand, dass einer von 15 MCP-Servern ein Lookalike ist, der einen legitimen Dienst imitieren soll. Verifizierung: bestätigen Sie, dass jeder MCP-Server in der Bereitstellung einen signierten Provenienz-Eintrag und ein AIBOM (AI Bill of Materials)-Inventar hat. Bestätigen Sie, dass die Abhängigkeitsüberwachung aktiv ist und bei neuen CVEs im Abhängigkeitsbaum alarmiert.

Kontrolle 7: STDIO-Härtung. Die OX-Security-Offenlegung identifizierte einen architekturen RCE in STDIO-Konfigurationen, der 150M+ Downloads betrifft. Die Ursache: shell: true im TypeScript SDK ermöglichte Befehlsinjektion über Konfigurations-Strings. Die Cloud Security Alliance klassifizierte dies als systemisches Designfehler-Problem. Verifizierung: wenn der Server STDIO-Transport verwendet, bestätigen Sie, dass shell: false oder äquivalente Härtung gesetzt ist. Bestätigen Sie, dass Befehls-Allowlists Argumente prüfen, nicht nur Binär-Namen — die Upsonic- und Flowise-Bypässe (CVE-2026-30625, CVE-2026-40933) zeigten, dass npx -c <bösartiger-Befehl> durch eine Allowlist gelangt, die nur das Binär prüft.

Schicht 4 — Runtime und Ausführung

Kontrolle 8: Rate-Limiting. Jedes Tool deklariert sein eigenes Rate-Limit im Registrierungsaufruf. Das Backbone setzt Limits pro-Agent, pro-Tool und pro-Fenster durch. Wenn ein Limit erreicht wird, erhält der Agent eine 429-Antwort mit einem Retry-After-Header. Ein kompromittierter Agent kann Upstream-API-Quotas nicht erschöpfen, weil das Rate-Limit an der Modulgrenze durchgesetzt wird. Verifizierung: bestätigen Sie, dass jedes registrierte Tool ein Rate-Limit hat. Bestätigen Sie, dass das Limit an der Modulgrenze durchgesetzt wird, nicht an der Upstream-API. Ein Tool ohne Rate-Limit ist ein Tool, das ein kompromittierter Agent unbegrenzt aufrufen kann.

Kontrolle 9: Kontextgrenze. OWASP MCP10 nennt Kontext-Injektion und Over-Sharing ein Top-10-Risiko. Ein Agent mit breitem Kontextzugriff leckt Informationen über Tenants, Sessions oder Benutzer hinweg — ein besonders akuter Anliegen für B2B-Bereitstellungen, wo derselbe Agent mehreren Kunden mit unterschiedlichen Datenzugriffsrechten dient. Verifizierung: bestätigen Sie, dass jedes Tool nur den Kontext erhält, den es für seine spezifische Operation benötigt. Bestätigen Sie, dass das Kontextfenster pro-Tool abgegrenzt ist, nicht global über alle Tools geteilt. Ein Tool, das den vollständigen Session-Kontext erhält, wenn es nur ein einzelnes Feld benötigt, ist eine Datenleck-Fläche.

Kontrolle 10: Kill-Switch pro Modul. Jedes MCP-Modul muss unabhängig deaktivierbar sein, ohne das Orchestrierungs-Backbone zu berühren. Der Kill-Switch ist eine Konfigurationsänderung, keine Code-Bereitstellung. Wenn eine Schwachstelle offengelegt wird — wie die Juli-CVE-Welle 3 SDK-CVEs und 7+ Server-CVEs in einer Woche offenlegte — ist die erste Frage des Operators: Kann ich dieses Modul deaktivieren, ohne den Agenten herunterzufahren? In einer governanceten Bereitstellung lautet die Antwort ja. Verifizierung: bestätigen Sie, dass jedes Modul über ein Feature-Flag oder eine Konfigurationsänderung deaktiviert werden kann. Bestätigen Sie, dass der Deaktivierungspfad getestet wurde — nicht nur konfiguriert. Ein Kill-Switch, der nie ausgeübt wurde, ist ein Kill-Switch, der versagen wird, wenn er gebraucht wird.

Schicht 5 — Audit und Telemetrie

Kontrolle 11: Pro-Aufruf-Audit-Logging. OWASP MCP08 nennt fehlendes Audit und Telemetrie ein Top-10-Risiko. Ohne Protokolle von Tool-Aufrufen und Kontextänderungen bleiben Token-Diebstahl und Injektion unsichtbar. Jeder Tool-Aufruf muss Zeitstempel, Agent-ID, Tool-Name, Input-Hash (nicht roher Input — PII-Grenze), Output-Status, Dauer und Upstream-System protokollieren. Protokolle sind strukturiertes JSON, das an die Observability-Pipeline gesendet wird. Verifizierung: bestätigen Sie, dass jeder Tool-Aufruf einen strukturierten Protokolleintrag erzeugt. Bestätigen Sie, dass das Protokoll den Input-Hash enthält, nicht den rohen Input. Bestätigen Sie, dass das Protokoll unveränderlich ist — ein Angreifer, der den Server kompromittiert, kann den Audit-Trail nicht umschreiben.

Kontrolle 12: Shadow-Server-Erkennung. OWASP MCP09 deckt Shadow-MCP-Server ab — nicht genehmigte oder unbeaufsichtigte Bereitstellungen, die für Governance unsichtbar sind. UpGuard fand, dass einer von 15 MCP-Servern ein Lookalike ist. Ein Ingenieur, der das falsche mcp-server-postgress (beachten Sie den Tippfehler) installiert, erhält ein Paket, das stillschweigend SSH-Schlüssel und .env-Dateien exfiltrriert. Verifizierung: bestätigen Sie, dass ein Inventar jedes MCP-Servers in der Bereitstellung existiert. Bestätigen Sie, dass das Inventar gegen ein Register bekannt-guter Pakete geprüft wird. Bestätigen Sie, dass die Drift-Überwachung alarmiert, wenn ein neuer Server erscheint, der nicht im Inventar war.

Wie die Frameworks auf die Checkliste mappen

Kontrolle	OWASP MCP	Spec 2026-07-28	Microsoft AGT	NIST	CSA
1. SSE-Migration	—	12-Monats-Deprekation	—	—	—
2. Netzwerkisolation	MCP07	Origin-Validierung	—	—	—
3. OAuth 2.1 + OIDC	MCP07	Obligatorische Auth	—	OAuth 2.0	—
4. Agenten-Identität	MCP07	—	AgentMesh Identity	SPIFFE/SPIRE	—
5. Tool-Poisoning-Scan	MCP03	—	MCP Security Gateway	—	—
6. Signierte Provenienz	MCP04	—	—	—	—
7. STDIO-Härtung	MCP05	—	—	—	Systemischer Designfehler
8. Rate-Limiting	—	—	Policy Engine	—	—
9. Kontextgrenze	MCP10	—	Response Sanitizer	—	—
10. Kill-Switch pro Modul	—	—	Hypervisor Kill-Switch	—	—
11. Pro-Aufruf-Audit-Logging	MCP08	—	Audit + Metrics	—	—
12. Shadow-Server-Erkennung	MCP09	—	—	—	—

Kein einzelnes Framework deckt alle 12 Kontrollen. Die Checkliste ist die Schnittmenge von OWASP, der Spezifikation, Microsoft, NIST und CSA — jedes Framework trägt die Kontrollen bei, die den anderen fehlen. Das Microsoft Agent Governance Toolkit deckt 10/10 OWASP-MCP-Top-10-Kategorien ab (7/10 vollständig, 3/10 partiell mit Roadmap) und ist die erste von einem Hyperscaler gelieferte Open-Source-Runtime mit expliziten OWASP-Mappings — 68 Tests in der Agent OS Policy Engine, 127 Tests im MCP Security Gateway, 80 Tests im Agent Hypervisor Execution Control inklusive Kill-Switch.

Die Checkliste bewerten

Ein produktionsbereiter MCP-Server besteht alle 12 Kontrollen. Ein partiell bereiter Server besteht 8–11. Ein Server, der weniger als 8 besteht, sollte nicht dem Produktionsverkehr ausgesetzt werden ohne einen dokumentierten Remediation-Plan und ein Zieldatum für jede fehlgeschlagene Kontrolle.

Score	Status	Aktion
12/12	Produktionsbereit	Mit Monitoring bereitstellen
8–11/12	Partiell bereit	Mit dokumentierten Ausnahmen und Remediation-Zeitstrahl bereitstellen
<8/12	Nicht bereit	Nicht bereitstellen. Fehlgeschlagene Kontrollen zuerst remediiieren

Das häufigste Fehlermuster ist das Bestehen der Kontrollen 1–4 (Transport, Authentifizierung, Identität) bei gleichzeitigem Scheitern der Kontrollen 5–12 (Lieferkette, Runtime, Audit). Die ersten vier sind architektonisch und erhalten Aufmerksamkeit in Design-Reviews. Die letzten acht sind operativ und werden übersehen, bis ein Vorfall oder ein Audit sie zutage fördert. Die Juli-2026-CVE-Welle — 3 SDK-CVEs und 7+ Server-CVEs in einer Woche — ist, was passiert, wenn die operativen Kontrollen fehlen.