OWASP MCP Top 10 Assess

Überblick

Die OWASP MCP Top 10 ist OWASPs erstes eigenständiges Top-10-Projekt für Model-Context-Protocol-Implementierungen. Während die Top 10 for LLM Applications Risiken auf Modellebene adressieren und die Top 10 for Agentic Applications autonomes Agentenverhalten behandeln, zielt diese Liste auf das Verbindungsgewebe: die Protokollebene, die Assistenten mit realen Systemen und Daten verdrahtet. Der angegebene Umfang reicht von Model Misbinding, Context Spoofing, Prompt-State-Manipulation, unsicheren Memory-Referenzen bis zu Covert-Channel-Missbrauch, wobei Risiken als MCP01:2025 bis MCP10:2025 katalogisiert sind und explizit in agentischen, Model-Chaining- und Multi-Modal-Orchestrierungsszenarien verstärkt werden (Projektseite, Imperva).

Das Timing ist das Argument dafür, es separat zu verfolgen. MCP entwickelte sich innerhalb von weniger als achtzehn Monaten von einem Protokoll, das die meisten Security-Teams kaum kannten, zur Standard-Integrationsebene für AI-Agenten, wobei die Adoption die Hardening-Maßnahmen überholte (PipeLab, Cycode). Bestehende AppSec-Checklisten setzen einen menschlichen oder deterministischen Caller voraus; MCP-Server brechen diese Annahme, weil der Caller ein LLM ist, das seine Argumente durch Inferenz über ein Context Window generiert (SkillAudit). Eine dedizierte Taxonomie ist das Mindestvokabular, das für dieses Gespräch nötig ist.

Wir stufen es als assess ein, weil es glaubwürdig ist und bereits als kanonisches Framework zitiert wird, aber es befindet sich noch in Beta und Pilot Testing, wird als lebendes Dokument veröffentlicht, und wir haben keine Belege für Produktionsprogramme gesehen, deren Controls end-to-end davon geleitet werden. Lesen, mappen, gegen das eigene MCP-Inventar pilotieren — aber noch keine Audit- oder Procurement-Gates an die Kategorienummerierung koppeln.

Adoptionssignale

  • OWASP positioniert es als sein erstes eigenständiges Top-10-Projekt für MCP, neben den Top 10 for LLM Applications und den Top 10 for Agentic AI (Cycode).
  • Es hat eine namentlich benannte Projektleitung (Vandana Verma Sehgal) und eine dokumentierte Roadmap und wird als Dokumentationsprojekt in OWASP Nest getrackt (DEV Community, OWASP Nest).
  • Behördliche Guidance wird darauf gemappt: Die NSA-MCP-Guidance, die das agentische Setup als verbundenes System statt als separate Endpoints behandelt, wurde mit entsprechenden Testansätzen auf die MCP Top 10 gemappt (Equixly).
  • Tool-Anbieter und Forscher nutzen es als Scoring-Baseline: Stacklok verglich die ToolHive-Abdeckung mit der Liste (nhimg), CheckMCP auditierte 271 Server damit (CheckMCP), und SkillAudit mappte Befunde aus 101 Servern auf ihre Kategorien (SkillAudit).
  • Praktikerorientierte Erklärungen und Guides verbreiten sich schnell, jede geht alle zehn Kategorien für Security-Teams durch (agen.co, Practical DevSecOps, Medium).
  • Der zugrunde liegende Incident-Record, den es indexiert, ist real: über 30 CVEs allein im Januar–Februar 2026 gegen MCP-Server, Clients und Tooling eingereicht, 43 % davon Shell Injections (Practical DevSecOps); mindestens sieben indexierte CVEs gegen benannte MCP-Komponenten, darunter ein CVSS 9.6 in mcp-remote (MCP.Directory); und CVE-2026-32211, eine unauthentifizierte kritische Funktion in Microsofts gehostetem MCP-Dienst (obot.ai).

Risiken

  • Beta-Status und ein bewegliches Ziel. Die Liste befindet sich in Beta (Phase 3, Beta-Release und Pilot Testing) und ist ausdrücklich ein lebendes Dokument, das sich mit Protokollinnovationen weiter ändern wird, sodass Control-Mappings, die an spezifische MCP0x-Identifier gepinnt sind, überarbeitet werden müssen (Imperva, Projektseite).
  • Kein Enforcement-Pfad. OWASP mappt das Risiko; die MCP-Spezifikation verweigert bewusst jede Erzwingung, sodass Inventar, Identity Lineage, Per-Call-Autorisierung und Audit Trails vom Unternehmen selbst aufgebaut werden müssen (obot.ai).
  • Unvollkommene Passung zu MCP-Servern. Forscher, die versucht haben, jeden Befund über 101 Server zu mappen, berichteten, dass die Übung vor allem dort aufschlussreich war, wo OWASP an den strukturellen Unterschieden von MCP scheitert (SkillAudit).
  • Tooling-Lücken auf Modellebene. Keine einzelne Tool-Kategorie deckt die gesamte Liste ab, und Punkte wie Intent Flow Subversion benötigen weiterhin Controls auf Modellebene, die Runtime-Enforcement allein nicht liefern kann (PipeLab, nhimg).
  • Die Liste allein beantwortet nicht die Audit-Frage. Ein CISO benötigt Belege dafür, dass ein Deployment gegen bekannte Vulnerability-Kategorien getestet wurde, und eine Taxonomie ohne Test- und Reporting-Harness liefert diesen Beleg nicht (x.com).
  • Ausmaß unverwalteter Exposition übertrifft die Checkliste. OX Securitys Disclosure vom April 2026 nannte über 150 Mio. Downloads, über 7.000 exponierte Server und bis zu 200.000 verwundbare Instanzen, und Audits fanden Vernachlässigung — eingestellte Wartung und veraltete Protokollversionen — statt exotischer Exploits als dominierende Schwachstelle (MCP.Directory, CheckMCP).

Vorteile & Nachteile

Vorteile

  • Es verschafft Model-Tool-Integrationen eine eigenständige, benannte Risikotaxonomie (MCP01:2025 bis MCP10:2025), die MCP-spezifische Fehlerbilder wie Model Misbinding, Context Spoofing, Token Mismanagement, Tool Poisoning, Context Oversharing und Shadow-MCP-Server abdeckt, statt Teams zu zwingen, Web- oder API-Checklisten passend zu dehnen.
  • Es fügt sich nahtlos in den bestehenden OWASP-AI-Stack neben den Top 10 for LLM Applications und den Top 10 for Agentic Applications ein, sodass eine Organisation Risiken auf Modell-, Agenten- und Connector-Ebene mit einem gemeinsamen Vokabular abdecken kann.
  • Dritte nutzen es bereits als Vergleichs- und Testbaseline — die NSA-MCP-Guidance wurde darauf gemappt, Stacklok hat die ToolHive-Abdeckung damit verglichen, und Audits von 271 bzw. 101 MCP-Servern wurden gegen ihre Kategorien bewertet.

Nachteile

  • Das Projekt befindet sich noch in der Beta-Phase (beschrieben als Phase 3, Beta-Release und Pilot Testing) und wird als lebendes Dokument unter einer CC BY-NC-SA 4.0-Lizenz veröffentlicht, sodass sich Kategorienummerierung und Formulierungen noch verschieben können, unter jedem Control-Mapping, das man darauf aufbaut.
  • Es ist ein Awareness- und Dokumentationsartefakt, kein Enforcement-Mechanismus: Die MCP-Spezifikation erzwingt bewusst nichts davon, und Berichte weisen darauf hin, dass keine einzelne Tool-Kategorie die gesamte Liste abdeckt, sodass die Kontrollebene vollständig der adoptierenden Organisation überlassen bleibt.
  • Unabhängige Scanning-Arbeiten haben festgestellt, dass das OWASP-Mapping nicht saubep auf MCP-Server passt, und Coverage-Analysen weisen darauf hin, dass einige Punkte wie Intent Flow Subversion weiterhin Controls auf Modellebene erfordern, die aktuelles Runtime-Tooling nicht liefern kann.

Empfehlung

Bewerten Sie es jetzt bewusst (assess). Lassen Sie Ihre AI-Platform- und Security-Teams die zehn Kategorien lesen und eine einzelne, klar abgegrenzte Mapping-Übung gegen ein reales MCP-Deployment durchführen: Welche Kategorie adressiert jedes bestehende Control, welche Ebene erzwingt es, und wo gibt es überhaupt nichts. Erwarten Sie, dass das Mapping unvollkommen ist — planen Sie für Kategorien, die nicht saubep passen, und für Modellebenen-Punkte wie Intent Flow Subversion, die Runtime-Tooling allein nicht schließen kann. Behandeln Sie das Ergebnis als Gap-Register, nicht als Compliance-Report.

Kombinieren Sie die Taxonomie mit den zwei Dingen, die sie Ihnen nicht liefert. Erstens: Inventar — Shadow-MCP-Server, also nicht genehmigte Deployments, die außerhalb formaler Governance betrieben werden, sind eines der benannten Risiken, und man kann nicht bewerten, was man nicht erfasst hat. Zweitens: Enforcement — weil das Protokoll bewusst nichts erzwingt, besteht das praktische Programm aus Identity Lineage von Mensch zu Tool, Autorisierung, die bei jedem Call geprüft wird, und einem Audit Trail, der rekonstruieren kann, was passiert ist. Bestehende, von der NSA abgeleitete Guidance hat bereits ein veröffentlichtes Mapping auf diese Liste, was ein vernünftiger Ausgangspunkt für den Aufbau konkreter Tests ist.

Machen Sie MCP-Top-10-Abdeckung noch nicht zu einer vertraglichen oder Gate-Bedingung, solange das Dokument in Beta ist und als CC BY-NC-SA 4.0-lizenziertes Material weiterhin evolviert. Überprüfen Sie es im nächsten Radar-Zyklus erneut: Eine Beförderung zu trial sollte an ein stabiles Non-Beta-Release plus Belege dafür gekoppelt sein, dass Teams wiederholbare Tests durchführen und Coverage-Nachweise gegen die Kategorien erbringen, nicht nur, dass sie in Blogposts zitiert werden.

Quellen