MCP- und Agenten-Sicherheit

Die OWASP MCP Top 10, praktisch erklärt

Von CyberSec42 Research · Stand 2026

Die OWASP MCP Top 10 ist eine offene, gemeinschaftlich getragene Referenz für die zehn kritischsten Sicherheitsrisiken von MCP-Servern. Sie gibt Teams eine gemeinsame Sprache, um über Angriffsflächen zu sprechen, die es vor dem Model Context Protocol so noch nicht gab. Dieser Leitfaden nimmt jede der zehn Risikoklassen und ergänzt praktische Tiefe: was im Kern schiefgeht, wie Sie es testen, und welche strukturelle Gegenmaßnahme greift.

Warum MCP eine eigene Top 10 braucht

Das Model Context Protocol verbindet KI-Agenten mit Werkzeugen, Daten und APIs. Der MCP-Server sitzt an dieser Nahtstelle und läuft mit den Rechten und Zugangsdaten seines Betreibers. Er erbt damit die klassischen Server-Schwachstellen. Dazu kommen zwei neue Angriffsflächen. Die erste ist der Client: ein bösartiger Server kann ihn über Reverse-Channel-Verben treiben. Die zweite sind die geteilten Bibliotheken darunter, bei denen ein einzelner Defekt auf jeden abhängigen Server durchschlägt. Eine gemeinsame Taxonomie hilft, diese Grenzen sauber zu benennen. Die folgende Übersicht bleibt bewusst auf Klassen-Ebene und nennt keine konkreten verwundbaren Produkte.

Die zehn Risikoklassen im Detail

1. Fehlende oder schwache Transport-Authentifizierung

Der häufigste Fehler. Ein Server bindet einen HTTP- oder SSE-Endpunkt ohne Auth, im Vertrauen darauf, dass er ja nur auf localhost lauscht. Dann kann jeder lokale Prozess die Tools mit den Zugangsdaten des Betreibers steuern, über DNS-Rebinding sogar jede beliebige Webseite. Der Server wird zum Confused Deputy: er verwechselt "der Request kam an" mit "der Request ist autorisiert". Ein typischer Programmierfehler ist die ungenaue Host-Prüfung per startsWith statt exakter Gleichheit. An ihr kommt ein Host wie 127.0.0.1.beispiel.example vorbei.

Test: Authentifiziert jeder Transport-Einstieg? Wird Host und Origin exakt geprüft? Bindet der Server per Default nur auf loopback? Fix: ein Geheimnis pro Installation auf jeder Route, exakte Host-Allowlist, Bind auf 127.0.0.1, fail closed.

2. Fehler im OAuth-Vertrauensanker

MCP hat OAuth 2.1 übernommen und damit eine Klasse von Trust-Root-Fehlern geerbt. Der Authorization-Server, der Protected-Resource-Metadata-Zeiger und der Scope stammen oft aus einer Quelle, die der Client beeinflussen kann. Werden Origin und Issuer dabei nicht gepinnt, kann ein bösartiger oder zwischengeschalteter Resource-Server den Grant auf eigene Infrastruktur umlenken, das Token ernten oder einen zu breiten Scope in die Consent injizieren. Diese Klasse hat die höchste Hebelwirkung. Der Zeiger stammt oft aus einem server-kontrollierten WWW-Authenticate-Header, und ein einziger Bibliotheksdefekt vererbt sich an jeden abhängigen Server.

Test: Ist der Origin von Authorization-Server und Metadaten fest gepinnt? Wird ein cross-origin Metadaten-Zeiger abgelehnt? Wird der Scope geschnitten und die Token-Audience geprüft? Fix: Origin serverseitig pinnen, RFC 9728 Same-Origin-Regel durchsetzen, Scope mit dem Entitlement schneiden, aud validieren. Details im Leitfaden zu MCP und OAuth.

3. Indirekte Prompt-Injection und Tool-Poisoning

Tools geben nicht vertrauenswürdige Inhalte (Webseiten, Repo-Dateien, Datenbankzeilen, Dokumente) wörtlich in den Agent-Kontext zurück. Darin versteckte Anweisungen erreichen die eigenen schreibenden, ausführenden oder abrufenden Tools des Servers. Privater Datenzugriff plus nicht vertrauenswürdiger Inhalt plus ein Ausgangskanal ergibt Exfiltration, die sogenannte lethal trifecta. Das Tückische: der Angreifer spricht nie direkt mit dem Server. Mehr dazu im Leitfaden zu Prompt-Injection.

Test: Ist nicht vertrauenswürdiger Tool-Output klar als Daten abgegrenzt und gelabelt? Kann eingeschleuster Inhalt ein zustandsänderndes oder ausgehendes Tool erreichen? Fix: die Kernregel des Bedrohungsmodells durchsetzen, Tool-Output ist Daten und nie ein Kontrollkanal. Bestätigung für destruktive und ausgehende Tools, Lese- und Handlungsrechte trennen.

4. Scheinbare Kontrollen (False Assurance)

Ein Server bewirbt eine Kontrolle, deren Implementierung sich umgehen lässt: eine Command-Whitelist, eine Code-Sandbox, ein Read-only-Modus, eine Denylist. Am gefährlichsten ist der Fall, in dem das Sicherheitsversprechen selbst die Lücke ist. Sobald die Kontrolle existiert, hinterfragt sie niemand mehr. Zwei Umgehungen sind verbreitet. Bei der Type-Confusion umläuft ein Array oder Objekt einen Check, der nur Strings erwartet. Bei fehlender Normalisierung schlüpft eine Unicode-äquivalente Form (Fullwidth, Homoglyph) an einem Byte-Vergleich vorbei.

Test: die Kontrolle direkt angreifen, Whitelists über andere Flags, Sandboxes über Introspektion, Text-Checks über Encoding und Normalisierung. Fix: strukturell durchsetzen statt textuell, kanonisieren und Typ prüfen VOR dem Check, default-deny, nicht-konforme Typen ablehnen.

5. SSRF und ungefilterte Abrufe

Ein Tool lädt eine vom Aufrufer bestimmte URL ohne Scheme- oder Host-Allowlist und ohne Sperre interner Adressen und gibt oft den Antwort-Body wörtlich zurück. Ziel sind Cloud-Metadaten unter 169.254.169.254, interne Hosts oder file://. MCP hat zwei Datenflächen, Tools und Resources, und SSRF taucht auf beiden auf. Der häufigste stille Fehler ist ein Gate, das bei einem Parse-Fehler durchlässt statt abzulehnen.

Test: Kann ein Tool interne Adressen oder file:// erreichen? Gibt es eine Allowlist? Fällt das Gate offen? Fix: Scheme- und Host-Allowlist (nur https), loopback, link-local und private Bereiche blocken inklusive IPv6-Formen, DNS auflösen und die IP pinnen, Redirects aus, fail closed.

6. Command- und Code-Injection bis RCE

Agent-kontrollierter Input erreicht exec, eval, einen Subprozess oder eine Sandbox, die keine ist. Das sind die schärfsten Severities im Katalog, weil ein einziger Tool-Call zum vollständigen Server-Compromise führt. Verwandte Sinks sind unsichere Deserialisierung, unsicheres YAML, Template-Injection und XXE. Das Muster ist immer dasselbe: ein nicht vertrauenswürdiges Tool-Argument erreicht einen mächtigen Interpreter oder Parser.

Test: Erreicht ein Tool-Parameter eine Shell, einen Interpreter oder einen Deserialisierer? Fix: Agent-Input nie an eine Shell geben, argv-only plus Allowlist ohne shell=True, echte Isolation ohne Netz, für Ausdrücke einen echten Parser statt eval(), default-deny für Ausführung.

7. Secret- und Credential-Exposure inklusive Reverse-Channel

Operator-Credentials liegen neben nicht vertrauenswürdigem Code, Tokens werden geloggt, geechot oder ungeprüft an ein fremdes Ziel weitergereicht, TLS-Verifikation ist aus. Neu in dieser Klasse ist der Reverse-Channel: die MCP-Verben sampling/createMessage und elicitation/create lassen einen bösartigen Server den Client treiben und privaten Kontext oder auto-beantwortete Secrets abziehen. Hier ist die verwundbare Partei der Client, weshalb rein serverseitige Reviews diese Klasse strukturell verpassen.

Test: Trägt ein Tool-Output oder weitergeleiteter Request ein Secret? Bindet der Client privaten Kontext in einen server-initiierten Sampling-Request oder füllt eine Elicitation automatisch? Fix: Calls host-seitig brokern, Secrets nie loggen oder durchreichen, explizite Zustimmung pro server-initiiertem Vorgang.

8. Zu breite Capability und fehlende Per-Call-Autorisierung

Tools können weit mehr, als der Anwendungsfall braucht, etwa auf das ganze Dateisystem oder beliebiges SQL zugreifen. Dazu kommt, dass die Autorisierung über die Protokollfläche ungleich angewandt wird. Das Grundmuster teilt sich mit BOLA und IDOR: Zugriff auf ein Objekt ohne Ownership-Prüfung. Auch neuere Protokoll-Verben gehören hierher, etwa ein Completion-Endpunkt, der privilegierte Werte ohne die Autorisierung des echten Tools enumeriert, oder ein Batch, in dem eine verbotene Methode ungeprüft mitgeschmuggelt wird.

Test: Greift dieselbe Autorisierung auf jede Methode und jedes Batch-Element? Ist eine Capability breiter als ihr Anwendungsfall? Fix: jedes Tool auf das Minimum scopen, jede Methode und jedes Batch-Element identisch autorisieren, deny by default.

9. Unsichere Standardwerte

0.0.0.0-Bind, Wildcard-Allowlist, DNS-Rebinding-Schutz aus, Sandbox-Bypass-Flags an, mitgelieferte oder bekannte Signierschlüssel, Default-Admin-Credentials. Der Angriff braucht keinen Exploit, nur den unveränderten Standard. Diese Klasse ist zugleich die Wurzel von Klasse 1: der offene Bind und der Wildcard-Host ermöglichen den Confused Deputy überhaupt erst. Auch die Akzeptanz von alg=none bei JWTs oder vorhersagbar erzeugte Tokens gehören hierher.

Test: Startet der Server auch in einer unsicheren Kombination? Werden privilegierte oder Debug-Tools aktiviert ausgeliefert? Fix: safe-by-default, explizites Opt-in für gefährliche Modi, Start bei offensichtlich unsicheren Kombinationen verweigern, Tokens mit einem CSPRNG erzeugen.

10. Path-Traversal, unsicherer Dateizugriff und DoS

Agent-gelieferte Pfade entkommen dem Root, etwa über ../, absolute Pfade, Symlinks oder Normalisierung. Ein Archive-Entry schreibt per Zip-Slip aus dem Zielordner heraus. Oder ein winziger Payload expandiert ohne Größenlimit und erschöpft Speicher und CPU des Hosts. Auch Path-Traversal taucht auf beiden Datenflächen auf, bei Tools und bei Resources.

Test: Bleibt der aufgelöste Pfad unter dem Root? Wird ein Symlink abgelehnt? Ist die dekomprimierte Größe gedeckelt? Fix: kanonisieren plus Containment-Prüfung gegen den Real-Root, Symlinks und ..-Segmente ablehnen, dekomprimierte Größe hart deckeln und Bytes streamend zählen, Timeouts plus Recovery auf Prozessebene.

Von der Checkliste zum belastbaren Nachweis

Eine Klasse zu kennen ist nicht dasselbe, wie zu wissen, dass die Kontrolle in Ihrem Server hält. Ein Teil dieser Klassen ist statisch erkennbar, als Code-Muster oder Config-Literal, etwa unsichere Defaults, SSRF-Sinks oder Injection-Pfade. Ein anderer Teil liegt im Design von Fähigkeiten und Vertrauensgrenzen, etwa Prompt-Injection oder Ownership-Prüfungen, und wird erst im Verhalten der Agent-Schleife sichtbar. Belastbare Sicherheit braucht deshalb beide Ebenen: eine statische Prüfung gegen definierte Invarianten und eine dynamische Prüfung, die jeden Einzelbefund mit einem ausgeführten Nachweis belegt, statt ihn nur zu vermuten.

Häufige Fragen