Sicherheit & Governance

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

Von IdeaBosqueZuletzt aktualisiert: 2026年7月27日

Aktualisierung — 2026-08-18: OWASP GenAI MCP Server Security Baseline, MCP Project Sandboxing Baseline, MCP Ruby SDK und File Server Bugs — drei neue Standards und neue CVE-Klassen

Drei Entwicklungen fügen zwei neue MCP-Sicherheitsstandards und neue CVE-Klassen hinzu: OWASP GenAI Entwicklungs-Baseline, MCP Project Deployment-Baseline, sowie Ruby SDK und File Server Schwachstellen.

OWASP GenAI MCP Server Security Baseline (18. August) — Entwicklungskontrollen. Praktischer Leitfaden für sichere MCP-Serverentwicklung. Mit OWASP MCP Top 10 (Risikokatalog) und MCP Project Sandboxing Baseline (Deployment-Kontrollen) bildet ein geschichtetes MCP-Sicherheits-Framework.
MCP Project Sandboxing Baseline (16. August) — Deployment-Kontrollen von den Spec-Autoren. Das MCP Project veröffentlichte Sicherheits-Best-Practices, die Sandboxing oder Containerisierung für gespawnte Prozesse fordern.
MCP Ruby SDK und File Server Bugs (16. August) — neue CVE-Klassen. DoS im Ruby SDK und File-Disclosure durch unzureichende Pfadvalidierung. Das MCP-CVE-Katalog deckt nun Python, TypeScript, Java, Ruby und C# SDKs ab. Siehe den MCP Module Code Standard.

Update — 2026-08-17: CVE-2026-75011 NetForensicMCP und die Forcepoint Datenexpositions-Kontrolldimension

Zwei Entwicklungen erweitern diese Checkliste: eine neue STDIO-Befehlsinjektions-CVE und eine neue Kontrolldimension — Datenexposition — die Forcepoint als MCP-Sicherheitsanliegen erster Klasse neu gerahmt hat.

CVE-2026-75011 — NetForensicMCP 2.1.0 Befehlsinjektion. Ursache: dieselbe STDIO-Befehlsinjektionsklasse wie CISA KEV CVE-2026-42271 und OX Security Familie 1. Geschlossen durch Control 1 (Tool-Registrierung — alle Eingaben sanitisieren) und Control 7 (STDIO-Härtung — keine benutzergesteuerte Eingabe in Befehlsstrings).
Forcepoint Datenexpositions-Reframing — eine neue Kontrolldimension. "Authentifizierung repariert die Tür, nicht die Daten." Die Postmark-MCP-Hintertür wird als Datenexpositionsvorfall neu kontextualisiert. Vier Governance-Fragen: (1) Hält der Agent direkte oder vermittelte Credentials? (2) Ist Enforcement auf Feld- oder Anwendungsebene? (3) Sind Hochrisiko-Aktionen durch einen Menschen gegated? (4) Gibt es einen vollständigen Attribution-Trail?

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.
Deadbugz macht die Runtime zur Angriffsfläche: Metadaten-Poisoning wartet, bis Sie dem Server vertrauen — Pillar Security offenlegte am 23. September 2026 eine aktive MCP-Lieferketten-Kampagne: 23 Pull-Requests in 74 Minuten boten einen „Produktivitäts-Suite“-Server an, der sich für drei Tool-Aufrufe normal verhält und dann seine Tool-Metadaten umschreibt, um SSH-Schlüssel, AWS-Credentials, Shell-History und Kubernetes-Konfiguration zu suchen (Pillar Security). Scans zum Genehmigungszeitpunkt können ihn nicht sehen — siehe das Update vom 2026-09-30 unten.

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.

Update — 2026-08-07: Black-Hat-2026-MCP-Server-Erkennungsprodukte — Cyera, SailPoint, Check Point

Das vollständige Black-Hat-2026-Produktinventar (crn.com, 4. August 2026) fügt drei Produkte hinzu, die direkt Kontrolle 12 (Schattenserver-Erkennung) und die MCP-Server-Erkennbarkeits- und Governance-Dimension dieser Checkliste adressieren.

Cyera Agent Guardian — Schatten-MCP-Server-Erkennung. Cyera lancierte Agent Guardian, um Schatten-MCP-Server und nicht genehmigte KI-Agenten im gesamten Unternehmen zu erkennen. Für Kontrolle 12 ist Cyera die produktisierte Version des Inventarisierungs- und Drift-Überwachungsmusters: statt manuell ein Inventar zu pflegen, entdeckt Cyera automatisch MCP-Server in Produktion — einschließlich solcher, die nie registriert wurden. Die 1.467 exponierten Server sind die internetseitige Population; Cyera adressiert die interne Population.
SailPoint Identity Security — MCP-Server-Identitäts-Governance. SailPoint erweiterte seine Identity-Security-Plattform um MCP-Server-Identitäten. Für Kontrolle 4 fügt SailPoint MCP-Server als verwalteten Identitätstyp hinzu — jeder MCP-Server hat einen Lebenszyklus, der von derselben Identitäts-Governance-Infrastruktur verwaltet wird, die auch menschliche Identitäten behandelt.
Check Point AI Network Firewall — MCP-Kommunikationsüberwachung. Check Point lancierte eine AI Network Firewall, die MCP-Verkehr auf Richtlinienverstöße und Datenexfiltration überwacht. Für Kontrolle 9 fügt Check Point Netzwerkebenen-Durchsetzung hinzu: ein Tool-Server, der versucht, Daten über seine MCP-Antworten zu exfiltrieren, wird auf Firewall-Ebene erfasst.

Die MCP-Sicherheitsproduktkategorie hat nun dedizierte Anbieter für Schattenserver-Erkennung (Cyera), Identitäts-Governance (SailPoint) und Netzwerkebenen-Überwachung (Check Point) — drei Oberflächen, die die 12 Kontrollen adressieren, aber zuvor Custom-Builds erforderten.

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.

Update — 2026-09-30: Deadbugz runtime-gated metadata poisoning — die vierte MCP-Angriffsklasse besiegt Scans zum Genehmigungszeitpunkt

Pillar Security hat Deadbugz offengelegt am 23. September 2026 — eine aktive MCP-Lieferketten-Kampagne, die 23 GitHub-Pull-Requests in 74 Minuten einreichte, jeder bot einen „Produktivitäts-Suite“-MCP-Server an. Der Server verhält sich für drei Tool-Aufrufe normal; nach dem dritten kippt der pro Client geführte Aufrufzähler, den er pflegt, seine eigenen Metadaten: nachfolgende tools/list- und prompts/get-Antworten weisen den verbundenen KI-Agenten an, SSH-Schlüssel, AWS-Credentials, Shell-History und Kubernetes-Konfiguration zu suchen — und die Aktivität vor dem Operator zu verbergen. Der Server kündigt tools.listChanged an, also ruft der Client die vergifteten Definitionen ab, ohne sich neu zu verbinden. Die Cloud Security Alliance vermerkt mechanische Nähe zur früheren „Miasma“-Kampagne über 73 GitHub-Repositories hinweg. Die vollständige Mechanismusanalyse findet sich im Deadbugz-Artikel.

Dies ist die vierte distinkte MCP-Angriffsklasse — nach STDIO-Befehlsinjektion, Tool-Poisoning und SHA-Pinning-Bypass — und diejenige, die genau die Kontrollen zum Genehmigungszeitpunkt dieser Checkliste in Schicht 3 besiegt. Deadbugz' Tools sind zum Zeitpunkt der Genehmigung durch den Operator genuin benign; die bösartige Payload wartet hinter einem Runtime-Gate. Kein Scan zum Genehmigungszeitpunkt kann ihn sehen, weil es zum Genehmigungszeitpunkt nichts zu sehen gibt. Die Erkennungsfläche wandert von der Installation zur Runtime.

Für die 12-Kontrollen-Checkliste ergibt sich daraus ein Schicht-4-Posten: Tool-Metadaten-Drift-Erkennung nach der Installation. Erfassen Sie einen Hash-Fingerabdruck jeder Tool-Definition, die ein Server zum Genehmigungszeitpunkt zurückgibt — Name, Beschreibung, Input-Schema, Annotations. Wenn der Server tools.listChanged signalisiert (oder nach einem Zeitplan), rufen Sie die neuen Definitionen ab, vergleichen Sie sie mit dem Fingerabdruck, und behandeln Sie jede Abweichung als Metadaten-Drift-Sicherheitsereignis, das eine erneute Operator-Genehmigung erfordert, bevor das geänderte Tool sensible Aktionen beeinflussen kann. Derselbe Fingerabdruck-Vergleich erfasst die frühere Tool-Poisoning-Klasse, weil beide Angriffe denselben Mechanismus teilen: eine Tool-Definition, die sich nach der Genehmigung ändert. Verifizierung: verbinden Sie sich mit dem genehmigten Server, führen Sie drei oder mehr gewöhnliche Tool-Aufrufe aus, rufen Sie dann tools/list erneut ab und vergleichen Sie es mit dem Fingerabdruck zum Genehmigungszeitpunkt — Deadbugz ist darauf ausgelegt, jede Review zu bestehen, die vor diesem vierten Aufruf stoppt.

Update — 2026-10-01: das Modell-Level-Komplement — Gemini 4 Argon führt Gray Swans IPI-Benchmark anDie Modul-Level-Verteidigungen oben haben nun ein benanntes Modell-Level-Gegenstück. Googles MENA-Crosspost des Argon-Announcements vom 1. Oktober gibt an, dass Gemini 4 Argon durch automatisiertes Red-Teaming und adversariales Training „in der Prompt-Injection-Robustheit an Gray Swans Indirect Prompt Injection (IPI)-Benchmark führend“ ist. Das ist ein Anbieter-Benchmark-Claim — behandeln Sie ihn als Beschaffungs-Evidenz, die Sie auf Ihrer eigenen Workload verifizieren, nicht als Kontrolle. Die Architektur-Lesart bleibt bestehen: Modell-Level-Robustheit senkt die Basisrate erfolgreicher Injektionen; sie ersetzt nicht die Runtime-Kontrollen der Schicht 3, die Fingerprint-Drift-Erkennung oder das Egress-Scoping, weil eine Verteidigung, die auf Modell-Ebene offen ausfällt, die Modul-Ebene braucht, um zu halten. Deployments, die beides paaren, erhalten Defense in Depth über den Injektionspfad; Deployments, die auf eines allein setzen, erben den Ausfallmodus dieser einen Schicht.

Update — 2026-10-02: Der Helpdesk als Konzentration von Anmeldedaten — der DIVD-ATA-Breach

Das offensive Gegenstück zu den Layer-2- (Authentifizierung) und Layer-3/4- (Runtime) Kontrollen dieser Checkliste landete im Feld: Sysdigs Analyse vom 2. Oktober dokumentiert einen Agentic Threat Actor, der am 21. September 2026 das Dutch Institute for Vulnerability Disclosure (DIVD) kompromittierte, indem er zwei Zammad-Helpdesk-Zero-Days verkettete — CVE-2026-102489 (RCE, CVSS 8,7) und CVE-2026-102490 (LPE, CVSS 8,5) — von gekaperter Session zu Root in Sekunden (Sysdig). Für die 12-Kontrollen-Checkliste ergibt das einen Systeminventar-Punkt: Ein Helpdesk konzentriert Session-Cookies, Passwort-Reset-Flows und Integrationstokens — genau die Assets, die ein Agent zur Verkettung bis Root braucht. Kartieren Sie, welche Ihrer agentenzugänglichen Systeme Anmeldedaten so konzentrieren, verifizieren Sie deren Session-Hijacking-Postur (dieselbe Klasse, die CVE-2026-16496 im Terraform MCP Server offenlegte), und behandeln Sie „Agent mit Token auf ein anmeldedatendichtes System“ als eigene Risikoklasse im Inventar-Kontrolleintrag — denn im DIVD-Fall begann die gesamte Eskalationskette mit genau dem.

Aktualisierung — 2026-10-04: Pro-Agent-Datenbankisolation als Speicherschicht-Kontrolle

Die Checkliste bekommt eine Speicherschicht-Kontrolle neben Modell-Gateway- und Tool-Scope-Eindämmung: die Pro-Agent-Datenbank. Supabase hat 150 Mio. $ aufgebracht und Turso für die Bereitstellung von Datenbanken pro Agent übernommen — 600 % Datenbankwachstum AI-Agenten zugeschrieben — und damit produktisiert, was der Datenexfiltrations-Abschnitt dieser Checkliste bislang als Annahme behandelte. Mit einer Datenbank pro Agent scheitertlaterale Bewegung zwischen den Datenflächen von Agenten auf der Credential-Schicht statt auf der Netzwerkschicht, und die Auditfrage („welcher Agent hat diese Zeile geschrieben?") löst sich durch die Konstruktion selbst. Der Trade ist agentenübergreifende Konsistenz: Joins und gemeinsame Referenzdaten wandern in die Orchestrierungsebene.

Aktualisierung — 2026-10-04: MCP-Events-Abonnements sind Credentials — und der Widerruf ist asymmetrisch

Der Credential-Management-Abschnitt der Checkliste hat eine neue Objektklasse zu governen: MCP-Events-Abonnements. OpenAIs Mechanismus fügt MCP-Servern signierte Webhook-Ereignisabonnements hinzu — events/subscribe erzeugt ein Abonnement mit Auslieferungsmodus, Callback-URL, HMAC-Signaturgeheimnis und Cursor. WorkOS' Einordnung ist die maßgebliche: das Abonnement ist selbst ein Credential und braucht Widerruf, Rotation und Zugriffskontrolle wie jedes andere. Der asymmetrische Teil gehört ausdrücklich auf die Checkliste: ChatGPT unterstützt den Webhook-Auslieferungsmodus, nicht aber den terminated-Umschlag — ein „widerrufenes" Abonnement kann daher weiter feuern, bis sein TTL erreicht ist; verifizieren Sie, welchen Auslieferungsmodus Ihre Agentenplattform einhält, bevor Sie den Widerruf als sofortig behandeln.

Aktualisierung — 2026-10-04: CrewAIs Sandbox-Umgehungen — die erste Open-Source-Framework-CVE-Familie seit Semantic Kernel

Die These der governierten Module reicht in diesem Zyklus bis zu Open-Source-Agenten-Frameworks: CrewAI hat fünf CVEs absorbiert — angeführt von CVE-2026-37008, einer RCE-Umgehung der Python-Sandbox über Objektgraph-Manipulation, dazu CVE-2026-2275 (CodeInterpreter-RCE, Docker-Sandbox und SandboxPython-Fallback), CVE-2026-2285 (SSRF), CVE-2026-2286 sowie CVE-2026-2287 (lokales Einlesen von Dateien) — unter CERT/CC-Advisory VU#221883. CrewAIs Remediation ist der Aufschluss: Das CodeInterpreterTool wurde vollständig entfernt, allow_code_execution als veraltet markiert. Die SandboxPython-Fallback-Kette — nach Docker greifen und bei Scheitern in unsichere lokale Ausführung abfallen — ist dasselbe unsichere-Defaults-Muster wie der LiteLLM-Standard-Adminkey-Fund, nun auf Framework-Ebene: der Sandbox-Posten der Checkliste muss verifizieren, dass der Fallback in einer Ablehnung endet, nicht in einer Degradation.

Authentifizierungs-Scoping von Agenten-SDKs (Präzedenzfall CVE-2026-104873). Authentifizierungsflächen von Framework-SDKs sind eine wiederkehrende Schwachstellenklasse — CrewAIs Sandbox-Familie und LangGraphs langgraph-sdk CVE-2026-104873 (gefixt in 0.4.4) trafen in derselben Woche ein. Der LangGraph-Defekt ließ actions-gescopete Auth-Handler universell gelten: ein angemeldeter Nutzer konnte die Threads anderer Nutzer erreichen. Checklisten-Posten: verifizieren Sie Nutzerisolation auf der Thread-/Session-Ebene unabhängig von den Auth-Handler-Defaults des Frameworks und pinnen Sie SDK-Versionen mit dem Scoping-Fix.

Update — 2026-10-06: drei neue MCP-CVE-Klassen kommen in die Checkliste — Confluence-Dateilesen, ArcadeDB-Token-Exposition, Facebook-Ads-SSRF

Der MCP-CVE-Bestand, den diese Checkliste verfolgt, bekommt drei Werkzeug-Ebenen-Angriffsflächen (bonfy.ai, MCP Security Statistics 2026): CVE-2026-73498 (Atlassian Confluence MCP) — confluence_upload_attachment reichte client-seitig gelieferte Dateipfade ohne Validierung direkt in Dateiöffnungs-Aufrufe durch und ermöglicht willkürliches Datei-Lesen über den Pfad-Parameter des Werkzeugs; CVE-2026-67357 (ArcadeDB MCP) — das Settings-Tool legte das HA-Cluster-Token im Klartext offen, ausreichend, um über spezifische Request-Header root zu impersonieren — eine neue Unterklasse: Secret-Leakage über die Werkzeug-Antwort; CVE-2026-19956 (Facebook Ads MCP Server) — SSRF in der Paginierungsfunktion; ein authentifizierter Remote-Aufrufer treibt Requests aus der Netzwerkposition des Servers. Die Übersetzung in die Checkliste: Pfadvalidierung für jedes dateibehandelnde Werkzeug ergänzen (der Server validiert, niemals der Client), die Antworten der Werkzeuge auf Secret-Leakage auditieren — nicht nur die Aufrufe auf Injektionen — und den Egress des Moduls netzwerkseitig eingrenzen, damit ein SSRF innerhalb eines Connectors nicht zu internen Metadaten-Endpunkten pivotieren kann. Jede Klasse mappt auf eine bestehende Kontrollfamilie (Eingabevalidierung, Antwort-Audit, Netzwerkisolierung) — genau das Argument der Checkliste: Die Klassen wechseln wöchentlich, die Kontrollfamilien nicht.

Update — 2026-08-08: Skill/Plugin Security Scanning — anbieterseitige Supply-Chain-Minderung

Anthropic veröffentlichte Skill/Plugin Security Scanning am 6. August 2026 — die erste modellanbieterseitige Supply-Chain-Minderung für Drittanbieter-Werkzeugserver. Der Scan prüft Drittanbieter-Claude-Code-Uploads (Skills und Plugins) auf bösartige Inhalte, bevor sie den Marketplace erreichen. Dies ist die anbieterseitige Ergänzung zur Prüfung, die ein Betreiber an seinen eigenen Werkzeugdefinitionen vornimmt: Kontrolle 10 (Tool-Poisoning-Abwehr) regelt die Prüfung, die Sie durchführen; Skill/Plugin Scanning regelt, was der Modell-Anbieter auf seinem Marketplace prüft.

Das digitalapplied.com-Framework (6. August 2026) quantifiziert die Produktionslücke: 88% der KI-Agenten-Projekte erreichen nie die Produktion, mit durchschnittlichen Projektausfallkosten von 340.000 $. Sieben Fehlermuster erklären 94% der Blockaden — Scope-Creep (34%), Datenqualität (27%), Sicherheitsblocker (14%), Integrationskomplexität (9%), Kostenüberschreitungen (7%), Governance-Lücken (5%) und organisatorischer Widerstand (4%). Die 12%, die die Produktion erreichen, teilen vier Merkmale: engerer Scope, Datenbereitschaftsinvestition, parallele Sicherheitsarchitektur und Governance vor Bereitstellung. Organisationen, die strukturierte Fehlermodus-Bewertung anwenden, senken Ausfallraten auf unter 15% — eine 4x-Verbesserung.

Update — 2026-10-11: AgentCorruption — die IMDS-Credential-Fläche erreicht die Managed-Agent-Platform

Zenity Labs' AgentCorruption-Disclosure (8. Oktober 2026, SecTor Toronto) ist die Credential-Expose-Klasse, für die es die Runtime-Kontrollen dieser Checkliste gibt — diesmal dokumentiert auf einer Managed-Agent-Platform. Ein einziger Prompt an einen öffentlich erreichbaren Amazon-Bedrock-AgentCore-Agenten richtete ein HTTP-fähiges Tool auf 169.254.169.254, und der Instance Metadata Service lieferte die temporären Credentials der Standard-Executionsrolle des Agenten zurück — eine Rolle, deren Gültigkeit nicht diesem Agenten galt, sondern jedem AgentCore-Agenten im selben AWS-Konto und derselben Region. Die Kette danach war pures IAM: DescribeLogGroups zählte jede Agenten-ID auf, InvokeAgentRuntime erreichte interne Agenten, für die der Nutzer nie autorisiert war, ListEvents las alle privaten Konversationen, GetSecretValue zog API-Keys und OAuth-Tokens, und eine agentenübergreifende Memory-Schreibberechtigung pflanzte dauerhafte Verhaltensänderungen, die die Session überlebten. Das ist dieselbe Credential-Klasse, die der LiteLLM-KEV-Artikel auf der Gateway-Ebene dokumentierte — Pass-Through-Routing, das eine schwache Grenze in die Kompromittierung des ganzen Cloud-Kontos verwandelt —, die nun die Plattform-Ebene erreicht, wo der Default der Plattform selbst die überprivilegierten Credentials lieferte. Die Checkliste-Übersetzung für die Runtime-Kontrollfamilie: blockiere Link-Local-Metadata-Endpunkte (169.254.169.254) auf jedem Modul-Egress-Pfad, lies die Richtlinie der Ausführungsrolle Berechtigung für Berechtigung, bevor der Agent live geht, und verifiziere, dass die Rolle die Ressourcen anderer Agenten im Konto nicht auflisten, aufrufen, lesen oder schreiben kann. AWS härtete die Standardrolle am 29. September 2026 — 278 Tage nach der ersten Meldung — und das ist die zweite Lehre: Das Fenster zwischen gemeldet und behoben gehört dem Kunden, auf jeder Managed Platform. Die vollständige Vorfallanalyse steht im AgentCorruption-Artikel.

Ein repräsentativer Build: ein mittelständischer Distributor, der ein MCP-Modul bereitstellt, das ein NetSuite-Katalog liest, Angebote generiert, Lagerverfügbarkeit hält und die akzeptierte Bestellung ins ERP zurückschreibt. Kontrollen 1–4 (SSE-Migration, Netzwerkisolation, OAuth, Agenten-Identität) sind die Architektur. Kontrollen 5–8 (Tool-Poisoning-Scan, signierte Provenienz, STDIO-Härtung, Rate-Limiting) sind die Lieferketten- und Runtime-Schicht. Kontrollen 9–12 (Kontextgrenze, Kill-Switch, Audit-Logging, Shadow-Erkennung) sind die operative Schicht, die bestimmt, ob das Modul eine Woche oder ein Jahr läuft. Die einwöchige Discovery-Phase produziert das System-Inventar und die Workflow-Map, die jede Kontrolle verifizierbar macht, bevor das Modul Produktionsverkehr berührt.

Einwöchige Discovery. Sie erhalten ein System-Inventar, eine Workflow-Map und einen festen Scope — ob Sie mit uns bauen oder nicht.

Aktualisierung — 2026-10-20: Splunk CVE-2026-76286 — die im Werkzeug konfigurierte URL ist selbst eine Vertrauensgrenze

Splunk hat CVE-2026-76286 am 7. Oktober 2026 im eigenen MCP Server offengelegt (CWE-918, CVSS 5.3, in 1.2.1 korrigiert) — eine SSRF, die das Plattform-Token des laufenden Nutzers an die in einem benutzerdefinierten API-Werkzeug konfigurierte URL sendet (Advisory). Der Befund schließt sich dem Register an (die CVSS-10.0-Sitzungsklasse von CVE-2026-16496, die Spring-AI-SSRF CVE-2026-45609 sowie die zwei KEV-Einträge) und bringt eine eigene Kontrolllektion mit: Die im Werkzeug konfigurierte URL ist selbst eine Vertrauensgrenze. Konfigurierte Werkzeug-URLs fixieren und validieren, nutzergelieferte Roh-URLs niemals in die Werkzeugkonfiguration aufnehmen, und jeden abgehenden Abruf eines Werkzeugs als Träger der eigenen Zugangsdaten des Servers behandeln.

Möchten Sie dies für Ihre Systeme gebaut?

Jedes Dokument hier stammt aus echter Produktionsarbeit. Wenn Sie ein Zielsystem und einen Workflow im Sinn haben, können wir in einer Woche einen Build umreißen.

Build mit festem Umfang anfragen

Einwöchiges Discovery. Sie erhalten ein Systeminventar, eine Workflow-Mappe und einen festen Umfang — unabhängig davon, ob Sie mit uns bauen.