01Scoping und Inventar
Am Anfang steht die Festlegung des Prüfgegenstands: Transport (stdio, Streamable HTTP oder der abgekündigte HTTP+SSE-Weg), Protokollrevision und die drei Parteien Server, Client/Host und Gateway. Erst die Revision entscheidet, welche Angriffsklassen überhaupt existieren – Session-Hijacking über den Mcp-Session-Id-Header etwa gibt es in der Revision 2026-07-28 nicht mehr, dafür kommen State-Handles und die Header-Body-Validierung hinzu. Wir katalogisieren jeden Server, jedes Tool samt vollständiger Definition, jedes Credential und jedes darüber erreichbare Zielsystem, und wir legen vorab schriftlich fest, mit welchen Testidentitäten und Scopes gearbeitet wird, denn tools/list darf je präsentierter Autorisierung variieren. Auch die Prüfwerkzeuge gehören ins Scoping: Der MCP Inspector – das offizielle Testwerkzeug des Projekts – war mit CVE-2025-49596 selbst Gegenstand einer kritischen Schwachstelle, die erst mit Version 0.14.1 behoben wurde; er ist deshalb mitzuversionieren und im Bericht auszuweisen.
02Identität und Berechtigungen (MCP07, MCP02)
Hier prüfen wir gegen normative Vorgaben statt gegen Geschmack: Ein Tool-Aufruf ohne oder mit ungültigem Token muss mit 401 und korrektem WWW-Authenticate-Header enden, und die Discovery-Kette muss vorhanden und korrekt verlinkt sein. Dabei ist zu unterscheiden: Protected Resource Metadata nach RFC 9728 ist für MCP-Server verpflichtend, beim Autorisierungsserver genügt wahlweise RFC 8414 oder OpenID Connect Discovery 1.0 – wer nur auf RFC 8414 prüft, produziert bei OIDC-Servern einen Fehlbefund. Für OAuth-URLs erwartet die Spezifikation HTTPS außerhalb von Loopback-Adressen. Zentraler Testfall ist die Audience-Prüfung, denn die Spezifikation verbietet Token-Passthrough ausdrücklich – ein Server darf keine Token akzeptieren, die nicht für ihn ausgestellt wurden. Bei Proxy-Architekturen kommt der Confused-Deputy-Pfad hinzu: eigene Consent-Seite je Client, exakter String-Vergleich der redirect_uri ohne Wildcards, kryptografisch erzeugter und einmalig verwendeter state-Parameter. Ergänzend prüfen wir die Scope-Minimierung: Wildcard- oder Omnibus-Scopes, gebündelte Privilegien und Server, die dem Scope-Claim im Token vertrauen, ohne selbst zu autorisieren.
03Tool-Definitionen: Poisoning, Shadowing, Rug Pull (MCP03)
Tool-Beschreibungen, Parameterdokumentation und JSON-Schemata sind ein Instruktionskanal, den das Modell autoritativ liest und den der Mensch in der Oberfläche in der Regel nie vollständig sieht. Wir erzeugen zuerst eine Baseline: Jede Definition aus tools/list, resources/list und prompts/list wird feldweise gehasht und dient als Referenz für spätere Vergleiche. Darauf folgen drei Prüfungen – die Gegenüberstellung von im Client sichtbarem Text und tatsächlich an das Modell übergebener Beschreibung, der kontrollierte Rug-Pull-Test in der Testumgebung (ändert sich eine bereits freigegebene Definition, muss der Host erneut zustimmen oder die Änderung melden) und der Shadowing-Test mit zwei parallel verbundenen Servern, die gleichnamige oder funktional überlappende Tools anbieten. Die Klasse ist praktisch belegt: Bei CVE-2025-54136 in Cursor wurden Änderungen an bereits freigegebenen MCP-Konfigurationen ohne erneute Zustimmung wirksam.
04Indirekte Prompt Injection über Tool-Ausgaben (MCP06)
Nicht nur die Beschreibung, auch die Rückgabeseite ist Angriffsfläche: Die Spezifikation verpflichtet Server ausdrücklich dazu, Tool-Ausgaben zu bereinigen (MUST), und empfiehlt Clients, Tool-Ergebnisse vor der Übergabe an das Modell zu validieren (SHOULD) – die schwächere Vorgabe auf der Client-Seite ist im Befundwortlaut abzubilden. Wir inventarisieren zunächst alle Kanäle, über die Fremdinhalte in den Kontext gelangen – Tool-Antworten, abgerufene Seiten und Dokumente, Repository-Inhalte, Tickets, Postfächer, persistiertes Memory – und bringen je Kanal einen harmlosen, eindeutig zurückverfolgbaren Marker ein, um zu beobachten, ob der Agent ihn als Anweisung oder als Datum behandelt. Geprüft wird dabei eine architektonische Kernfrage: Gibt es eine Herkunftstrennung zwischen Instruktion und Daten, oder landet beides im selben Kontextfenster? Liegen bei einem Agenten Zugriff auf sensible Daten, Verarbeitung nicht vertrauenswürdiger Inhalte und die Möglichkeit zur Außenkommunikation gleichzeitig vor – die Lethal Trifecta nach Simon Willison –, ist der Befund bereits architektonisch begründbar, auch ohne erfolgreiche Einzeldemonstration.
05Transport, Ausführung und Lieferkette (MCP05, MCP04, MCP09)
Am Transport gelten harte Vorgaben: Server müssen den Origin-Header eingehender Verbindungen validieren, lokal laufende Instanzen sollen an 127.0.0.1 binden statt an 0.0.0.0 – sonst genügt eine besuchte Webseite, um per DNS-Rebinding mit einem lokalen Server zu sprechen. Wir prüfen die serverseitige Validierung gegen das deklarierte Schema, den Umgang mit URLs im OAuth-Discovery-Pfad (private und Link-Local-Bereiche, Redirect-Ketten, DNS-Rebinding als TOCTOU-Szenario) sowie Sandboxing und Egress-Kontrolle der Tool-Ausführung; bereits der Nachweis, dass eine Eingabe ungeprüft in einen Interpreter gelangt, ist der Befund. Auf der Lieferkettenseite gleichen wir Registry-Eintrag, Repository und Maintainer ab und prüfen Version-Pinning, Signaturen und Freigabe-Gates für Updates – Labels wie „official“ oder „verified“ sind kein Vertrauensnachweis, wie CVE-2025-6514 im weit verbreiteten Paket mcp-remote gezeigt hat (betroffen sind die Versionen 0.0.5 bis 0.1.15, behoben in 0.1.16). Dazu kommt die Suche nach Schatten-Servern über Repository- und Endpoint-Scans, wiederholte Netzscans mit Differenzbericht sowie die Auswertung am Gateway, weil dort gemessen wird, welche Server ein Agent tatsächlich kontaktiert – und nicht nur, welche in der Konfiguration stehen.
06Telemetrie, Nachweisführung und Bericht (MCP08)
Die härteste Frage kommt zum Schluss: Lässt sich nachträglich rekonstruieren, welcher Agent zu welchem Zeitpunkt welches Tool mit welchen Parametern im Auftrag welcher Identität aufgerufen hat? Wir führen dafür eine definierte, harmlose Aktionsfolge durch – Verbindung, Tool-Auflistung, mehrere Aufrufe, ein abgelehnter Aufruf – und versuchen anschließend, genau diese Folge allein aus den Protokollen zu rekonstruieren; ein sauberer Negativbefund ist hier ein vollwertiges Ergebnis, weil er alle übrigen Befunde im Betrieb unbeweisbar macht. Im Bericht trennen wir zwei Beweiskategorien: Konfigurations- und Architekturbefunde sind deterministisch belegbar, verhaltensbasierte Befunde sind es nicht – für sie geben wir Wiederholungen, Trefferquote sowie Modell, Client und Version an. Jeder Befund wird zusätzlich der Ebene zugeordnet, auf der er liegt (Protokoll und Transport, Autorisierung, Tool-Definition, Client/Host, Agentenebene), weil sich Gegenmaßnahme und Verantwortlicher je Ebene unterscheiden.
