Dein MCP-Server ist die größte Sicherheitslücke

Ein böser MCP-Server kann deine SSH-Keys stehlen, ohne je eine einzige vollständige böse Anweisung zu schreiben. Die ASSET-Forschungsgruppe hat es bewiesen: Kommt der Diebstahlsbefehl auf einmal, lehnen die großen Modelle fast immer ab. Zerlegt man denselben Befehl in harmlos wirkende Fragmente, machen GPT-4o, Gemini 2.0 Flash und Llama 3.3 in 100% der getesteten Fälle mit.

Zugleich fügen die meisten Entwickler jede Woche einen neuen MCP-Server zu ihrem Agenten hinzu, kopiert von einer Config-Zeile auf GitHub. Jeder dieser Server hält ein Stück deines Zugangs: API-Tokens, Cloud-Keys, Service-Accounts. MCP ist nützlich — das bestreitet niemand. Aber der MCP-Server ist zum schwächsten Glied im gesamten Agent-Stack geworden.

Dieser Artikel behandelt, wie ein MCP-Server unbemerkt deine Geheimnisse leakt, den GhostSplice-Angriff, der Modellablehnungen umgeht, indem er seine Anweisungen zerlegt, und die konkreten Abwehrmaßnahmen, von Cloudflare WriteGuard bis zu Regeln, die du heute auf dein eigenes Setup anwenden kannst.

Ein MCP-Server ist die Brücke zwischen deinem Agenten und einem externen Tool: deiner Datenbank, deinem GitHub, deinem Slack, deiner Cloud. Um diese Brücke zu betreiben, speichert er alles, was er braucht, um sich als du anzumelden — Tokens, API-Keys, Service-Account-Zugangsdaten — im Klartext, in einer Config-Datei auf deiner Platte, meist ohne jede Verschlüsselung.

Ein Protokolldetail zählt für später. Verbindet sich ein Agent mit einem MCP-Server, schickt der Server seine Liste von Tools zurück, jedes mit einer Freitext-Beschreibung, die dem Modell sagt, wann und wie es zu nutzen ist. Diese Beschreibungen gehen direkt in den Kontext des Modells, mit demselben Gewicht wie deine eigenen Anweisungen, und auch die Ergebnisse der Tools landen dort. Ein MCP-Server redet also ständig mit deinem Agenten, in Text, den nie jemand erneut liest. Genau das macht den GhostSplice-Angriff erst möglich.

Das Ökosystem ist zudem schneller gewachsen als seine Leitplanken:

Signal	Zahl
Server im offiziellen MCP-Register	9.600+
Wachstum der Remote-Server-Deployments seit Mai 2025	5×

Jeder kann einen Server veröffentlichen, es gibt keine zentrale Prüfung, und dein Agent vertraut jedem genau wie einem offiziellen Tool. Die NSA veröffentlichte im Mai einen eigenen Sicherheitsguide zu MCP und erklärte, dass die Verbreitung des Protokolls schneller war als der Aufbau seiner Schutzmaßnahmen. Wenn ein Geheimdienst einen Guide zu deinem Lieblings-Dev-Tool schreibt, ist das selten ein Kompliment.

Das ist also die Ausgangslage: tausende Server, keine Prüfung, und deine Keys mittendrin.

Das erste Loch: Zugangsdaten werden im Klartext gespeichert. The Hacker News veröffentlichte am 17. August eine detaillierte Analyse der Leck-Mechanik, und der Ausgangspunkt ist unmissverständlich: Tokens landen direkt in Konfigurationsstrings und bleiben lesbar auf der Platte. Ein etwas hastiger Commit reicht, um eine Config mit den Keys darin in ein Git-Repo zu schieben. Es wird schlimmer durch das, was der Artikel Sprawl nennt: dieselben Keys mehrfach dupliziert über Config-Dateien, Umgebungsvariablen und Kopien in Dev, Staging und Produktion. Irgendwann weiß niemand mehr, wo die Geheimnisse liegen, also rotiert sie auch niemand — und ein statischer Key, der nie rotiert, ist ein Key, der auf seinen Angreifer wartet.

Das zweite Loch ist zu weitreichende Berechtigung. Während der Entwicklung gibst du deinem Server weite Rechte, um Autorisierungsfehler zu vermeiden, und diese weiten Rechte gehen unverändert in Produktion. Eine einzige Kompromittierung legt dann weit mehr offen, als reale Nutzung je gerechtfertigt hätte.

Das dritte Loch ist die Lieferkette. CVE-2025-6514 traf mcp-remote, einen OAuth-Proxy mit über 400.000 Downloads, und erlaubte einem bösen Server, Command Injection auf dem Rechner des Nutzers auszulösen — Code auszuführen und mit Zugangsdaten zu verschwinden. Ein beliebtes npm-Paket, in einer Zeile installiert, und die Tür stand offen.

Das vierte Loch ist am raffiniertesten: Prompt Injection. Ein Agent liest alles, was seine Tools zurückbringen — eine Webseite, ein Ticket, ein internes Dokument. Enthält eines davon eine versteckte Anweisung, kann der Agent ihr folgen, als käme sie von dir, und seine legitimen Tools nutzen, um genau das offenzulegen, was er eigentlich schützen sollte. Dieses Leck läuft über keine technische Lücke; es läuft über die Gutgläubigkeit des Modells.

Noch vor jedem raffinierten Angriff setzt der ganz normale Alltag eines MCP-Servers — Klartext-Config, überzogene Rechte, ungeprüfte Abhängigkeiten, ungefilterte Inhalte — bereits deine Geheimnisse aufs Spiel.

GhostSplice ist der Name, den die ASSET-Forschungsgruppe einer Technik gab, die deinen eigenen Agenten die Exfiltration ausführen lässt, mit dessen vollem Mitwirken. Das Prinzip passt in einen Satz: Statt den Diebstahlsbefehl vollständig zu schreiben, teilt der böse Server ihn auf, setzt ein Fragment in die Beschreibung eines Tools und ein anderes in das Ergebnis, das dieses Tool zurückgibt. Jedes Stück wirkt für sich allein harmlos. Aber der Agent kombiniert alles, was in seinen Arbeitskontext gelangt: Er baut die vollständige Anweisung wieder zusammen und führt sie in völliger Gutgläubigkeit aus — aus seiner Sicht füllt er nur das Formular aus, um das das Tool ihn gebeten hat.

Die Testzahlen sind die eigentliche Geschichte:

Modell	Anweisung am Stück	Zerlegte Anweisung
GPT-4o	Lehnt 100% ab	Macht 100% mit
Gemini 2.0 Flash	Lehnt 100% ab	Macht 100% mit
Llama 3.3	Lehnt 100% ab	Macht 100% mit
Claude Haiku 4.5	Lehnt über die API ab	Macht im Dreiteiler-Test in Cursor 100% mit

Das Claude-Detail zerstört jede einfache Schlussfolgerung: Dasselbe Modell kann in einem Client ablehnen und in einem anderen exfiltrieren, je nachdem, welchen Schutz der jeweilige Client hinzufügt oder nicht.

Was GhostSplice in den Tests stiehlt: SSH-Keys, Umgebungsgeheimnisse, Quellcode, Kundendaten. Die Forscher arbeiteten mit isolierten Projekten und Fake-Keys, nicht mit echten Opfern, aber die Methode ist veröffentlicht und reproduzierbar.

GhostSplice ist kein erster Versuch. Dasselbe Labor veröffentlichte im Juni Ghostcommit, einen Angriff, der seine Anweisungen in PNG-Dateien versteckte, auf die Projektkonventionen verwiesen, und die gestohlenen Geheimnisse dann als Ganzzahlen im Quellcode kodierte. Instruction Splitting ist also eine ganze Angriffsfamilie, die sich etabliert, keine isolierte Kuriosität.

Zwei Dinge relativieren das Ganze. Der Angriff hat zwei Voraussetzungen: Der böse Server ist bereits in deinen Agenten eingebunden, und der Agent hat Lesezugriff auf die Zieldateien. Genau deshalb zählt Herkunft so sehr — woher deine Server kommen, ist deine erste Verteidigungslinie. Und die Mechanik gilt es sich zu merken: Das Alignment des Modells schützt dich nicht, weil der Angriff nie auf einmal etwas Verbotenes verlangt.

GhostSplice setzte einen bereits eingebundenen bösen Server voraus. Aber wer entscheidet eigentlich, was eingebunden wird? In einem Team ist die ehrliche Antwort: niemand. Das ist das Problem, das Cloudflare Shadow MCP nennt: all die Server, die Entwickler ohne jede Sicherheitsprüfung mit ihren Agenten verbinden. Bis vor Kurzem war dieser Traffic unsichtbar — eine MCP-Anfrage sieht aus wie jeder andere HTTPS-Aufruf.

Cloudflare hat das mit Erkennung auf Protokollebene geändert. Seit dem Spec-Update sendet jeder konforme MCP-Client einen MCP-Protocol-Version-Header mit seinen Anfragen, und Gateway prüft diesen Header im gesamten TLS-Traffic, den es entschlüsselt. Ein Security-Team kann jetzt jeden im Unternehmen genutzten MCP-Server sehen, mit einem eigenen Dashboard: einzelne Server, Nutzer, Anfragevolumen. Dieser Header-Ansatz schlägt das Filtern nach Domainnamen, weil ein MCP-Server keinen Grund hat, sich mcp-irgendwas zu nennen — das Protokoll wird an dem erkannt, was es sagt, nicht an dem, was es vorgibt zu sein.

Das Team kann auch handeln: Ein is_mcp-Selektor lässt dich jeden MCP-Traffic blockieren, der nicht über ein genehmigtes Portal kam. Das Portal ist die andere Hälfte des Setups — ein einziger Zugangspunkt, der die geprüften Server hinter Identitätsauthentifizierung bündelt.

Die neueste Spec-Version treibt die Sichtbarkeit weiter voran. Die neuen Mcp-Method- und Mcp-Name-Header zeigen die angeforderte Operation und das genutzte Tool, ohne dass die Firewall den Request-Body öffnen muss. Ein Team kann so einen Agenten, der ein Ticket liest, von einem unterscheiden, der fünfzig davon löscht, direkt auf Netzwerkebene.

Cloudflare unterscheidet hier zwei Fälle: reines Shadow MCP, ein nie genehmigter Server, und Portal-Bypass, ein genehmigter Server, der direkt am Checkpoint vorbei erreicht wird. Beide werden mit derselben Grundregel blockiert. Die Logik ist einfach: Alles über das Portal ist bekannt und protokolliert, alles andere wird blockiert. Für ein Unternehmen ist das das Ende des am Freitagabend installierten Geister-MCP-Servers.

Auch ein genehmigter Server kann Schaden anrichten, weil ein Agent auf einmal alle Rechte seines Nutzers erbt. Genau hier kommt WriteGuard ins Spiel, das Cloudflare gerade in Private Beta geöffnet hat. Die Idee: jedes Tool jedes MCP-Servers in eine Risikostufe einteilen und pro Stufe eine andere Regel anwenden.

• Ein Read läuft reibungslos durch.
• Ein begrenztes Write, wie das Posten eines Kommentars, läuft durch, aber angereichert: Die Aktion wird als vom Agenten kommend signiert, im Auftrag einer bestimmten Person, und ein Audit-Event geht an ein zentrales Log.
• Eine kritische Aktion — Code mergen, in Produktion deployen, Massenlöschung — wird blockiert, bevor der Server sie überhaupt ausführt.

Das GitLab-Beispiel in Cloudflares Beitrag zeigt die Abstufung: Einen Merge Request lesen geht durch, ihn kommentieren geht durch mit Zuordnung, und ihn mergen wird verweigert, bis ein Mensch es selbst tut.

Der interessanteste Teil ist das Identitätsmodell. Der Agent behält die Berechtigungen des Mitarbeiters, dem er dient, aber jedes Write trägt nun zwei Signaturen: die Person und die Agent-Session, die für sie handelt. Nachgelagerte Systeme können so endlich eine handgemachte Änderung von einer maschinell erzeugten unterscheiden, und das Audit läuft asynchron in ein zentrales Log, bereinigt von sensiblen Daten. Bisher war ein Agent im Log nicht von seinem Menschen zu unterscheiden; für ein Incident-Audit ändert das alles — eine einzige Abfrage zeigt, ob der zweifelhafte Merge vom Dienstag von einem gehetzten Kollegen oder einer kreativ gewordenen Agent-Session kam.

Cloudflare verkauft hier keine Theorie, sondern beschreibt die eigene interne Nutzung: Ihr Portal verbindet 27 MCP-Server, hoch von 13 im April. Diese Zahl erzählt die eigentliche Geschichte — selbst bei Cloudflare verdoppelt sich die Serverzahl in wenigen Monaten, und genau deshalb wird Kontrolle pro Tool notwendig. Die Richtung, die die Branche einschlägt, ist klar: keinem ganzen Server mehr vertrauen, sondern Aktion für Aktion entscheiden, was ein Agent darf.

Die Grenzen müssen klar benannt werden. WriteGuard ist eine Private Beta hinter einem Anmeldeformular, und Gateways Erkennung braucht ein Cloudflare-Zero-Trust-Deployment mit aktivierter TLS-Inspektion: Für einen Solo-Entwickler oder ein kleines Team ist das schlicht nicht deine Infrastruktur. Selbst in einem Unternehmen sieht die Erkennung nur den Netzwerktraffic, den sie entschlüsselt — ein lokaler MCP-Server, der über stdio läuft, gestartet als normaler Prozess auf deiner Maschine, bleibt für Gateway unsichtbar. Und genau so laufen die meisten der von Entwicklern installierten Server tatsächlich.

Vor allem repariert keins dieser Tools den Kernmechanismus, den GhostSplice offengelegt hat: Solange ein Agent frei kombiniert, was in seinen Kontext gelangt, werden harmlose Fragmente sich immer wieder zu feindlichen Anweisungen zusammensetzen. Die ASSET-Forscher sagen es selbst: Die Lösung erfordert, Tool-Output als Daten zu behandeln, nie als Anweisungen, und diese Trennung existiert in Agenten heute noch nicht nativ.

In der Zwischenzeit laufen ihre Empfehlungen auf drei Schritte hinaus: Werte, die aus einem Tool kommen, nicht ungeprüft in die Argumente eines anderen Tools einfließen lassen, die Möglichkeit behalten, jeden Tool-Aufruf manuell zu verweigern, und jede Notiz von einem ungeprüften Server standardmäßig als feindlich behandeln. Keiner der drei Punkte läuft heute automatisch: Du wendest sie an, oder niemand tut es. Behandle alles, was Cloudflare hier liefert, als Sicherheitsgurt, nicht als Bremse — es begrenzt den Schaden, verhindert aber nicht den Zusammenstoß.

Was ab heute zu tun ist:

1. Inventur. Liste die MCP-Server auf, die wirklich mit deinen Agenten verbunden sind, und entferne die, die du nicht mehr nutzt.
2. Nach Herkunft sortieren. Ein offizieller Server eines bekannten Anbieters — ja. Ein GitHub-Repo mit 40 Sternen aus einem Thread — nein, nicht bevor du gelesen hast, was er mit deinen Daten macht.
3. Rechte begrenzen. Gib jedem Server ein dediziertes Token mit minimalem Scope, nie deinen Master-Key, und rotiere diese Tokens wie bei jedem Produktivsystem.
4. Die Hand auf sensiblen Aktionen behalten. Ein Agent, der schreibt, mergt oder löscht, muss über dich zurücklaufen — die Handarbeit-Version dessen, was WriteGuard industrialisiert.
5. Die GhostSplice-Regel im Alltag anwenden. Verkettet dein Agent Tool-Aktionen, die du nicht angefragt hast, stoppe ihn und lies, was der Server ihm erzählt hat.

Jeder Agent-Client kann seine verbundenen Server und deren Tools auflisten, und diese Liste zu lesen dauert dreißig Sekunden. Diese dreißig Sekunden sind das beste Zeit-zu-Sicherheit-Verhältnis in deinem gesamten Setup.

Bist du in einem Unternehmen, ergänze die Netzwerkebene: Gateways MCP-Erkennung und die Portale lohnen den Rollout, denn Shadow MCP existiert in deiner Organisation bereits, ob du es siehst oder nicht.

MCP ist nicht das Problem — das Tempo, in dem wir ihm unsere Keys übergeben haben, ist es.