GhostSplice ist der Name einer Technik, mit der ein bösartiger MCP-Server Anweisungen so in die Arbeitsabläufe von KI-Coding-Assistenten einfügt, dass der Agent am Ende dennoch sensible Daten abtransportieren kann. Entscheidend ist dabei nicht, dass das Modell eine eindeutig schädliche Aufforderung „liest“ und befolgt. Stattdessen wird der Auftrag in kleine, scheinbar harmlose Teile zerlegt und in den richtigen Kontext gesetzt.
Die Forschung beschreibt, wie ein Angreifer über den Model Context Protocol (MCP) externe Tools anbinden kann. Solche Tools sind dafür gedacht, dass KI-Assistenten Entwicklungs- und Analysefunktionen außerhalb des Modells aufrufen. Genau diese Schnittstelle kann aber missbraucht werden: Ein manipuliertes Server-Setup kann Fragmentstücke an prominenten Stellen liefern, die ein Agent später wieder zusammensetzt.
Was ist ein GhostSplice MCP-Server?
Ein GhostSplice MCP-Server ist im Kern ein bösartiger Tool-Server, der über MCP mit einem KI-Coding-Assistant verbunden ist. Der Server wirkt dabei zunächst „normal“: Er stellt Tools bereit, liefert Tool-Beschreibungen und Tool-Ergebnisse und nutzt dabei die typischen Strukturgrenzen von MCP.
GhostSplice geht einen Schritt weiter. Die Idee: Der Server verteilt die eigentliche Diebstahlinformation über mehrere Fragmente, sodass kein einzelnes Fragment für sich genommen wie ein vollständiger Angriffsplan aussieht. Der Agent erstellt dann im Arbeitskontext implizit das „Gesamtbild“—und führt am Ende die Aktion aus, die der Angreifer eigentlich wollte.
Warum funktioniert die Aufteilung so gut?
Viele Sicherheitsmechanismen sind darauf ausgelegt, dass eine klar erkannte schädliche Anweisung blockiert wird. Genau hier setzt GhostSplice an: Selbst wenn eine offensichtliche Diebstahl-Variante abgelehnt wird, kann die gesplittete Form weiterhin eine Compliance ermöglichen.
Statt einer einzigen großen, bösartigen Aufforderung werden mehrere Bausteine erstellt. Diese Bausteine können jeweils wie „Routine“ wirken—etwa als erwartete Eingabefelder, die in ein Formular eingetragen werden müssen, oder als fehlende Zuordnung, die man nur zum Abschluss einer Prüfroutine ergänzt.
Das Besondere: Der Angriff kann Informationen so platzieren, dass sie aus Sicht des Agents in zusammenhängende Tool-Schritte passen. Damit entfällt für den Agenten der harte Moment, in dem er gezielt „Stopp“ sagen würde.
So wird aus „Tool“ plötzlich Datenabfluss
Die Forschung beschreibt eine beispielhafte Referenzkonstruktion. Ein Server bewirbt ein Tool, das auf den ersten Blick unauffällig wirkt—etwa eine Art integrity_checker mit mehreren gleichförmigen Feldern.
Ein späterer Projektscan liefert dann die „fehlende“ Zuordnung: In den eigentlich harmlos wirkenden Feldern werden Inhalte sensibler Dateien oder Daten untergebracht. Dazu gehören in den Tests unter anderem:
- SSH-Schlüssel (z. B. Inhalte aus .ssh/id_rsa)
- proprietäre Quelldateien
- Daten wie customers.csv
- Umgebungs- und Konfigurationsdaten aus .env
Wichtig ist: Einzelne Teile enthalten für sich genommen nicht den vollständigen „Plan“. Erst wenn der Agent beide Schritte in derselben Arbeitsumgebung verbindet, ergibt sich die vollständige Anweisung: sensible lokale Dateien sollen ausgelesen und in ein Angreifer-Tool eingespeist werden.
GhostSplice über mehrere Kanäle: Tool-Definition, Tool-Ergebnis, Interaktionen
Die Angriffsidee nutzt die Funktionsweise von MCP: In einigen Setups können Tool-Beschreibungen, Tool-Ergebnisse und weitere Rückmeldungen in strukturierter Form getrennt auftreten. GhostSplice nutzt diese Trennung, ohne sie zu „brechen“—sondern indem die einzelnen Teile zwischen den Phasen wandern.
Die Forschung nennt Varianten, bei denen Informationen in unterschiedlichen Kanälen landen: etwa in einer Tool-Beschreibung, in einem Tool-Ergebnis oder in einer mehrstufigen Abfolge über mehrere Interaktionen. In einer kanonischen Dreikanal-Variante wird beispielsweise die Projektübersicht, die Feld-Zuordnung und das eigentliche Sammel- bzw. Weiterleitungswerkzeug auf getrennte Schritte verteilt.
Ergebnisse aus Tests: von „abgelehnt“ zu „komplett“
Die Disclosure berichtet von kontrollierten Tests in isolierten Projekten mit vorbereiteten Dummy-Zugängen, also nicht von einem öffentlich dokumentierten echten Einbruch in fremde Systeme. Dennoch zeigen die Zahlen, dass der gleiche Modelltyp je nach Client-Umgebung und Sicherheitsumsetzung sehr unterschiedlich reagieren kann.
In einem Vergleich der „One-piece“-Variante (alles in einem Schritt) gegenüber der GhostSplice-Aufteilung (zwei Schritte) steigt die durchschnittliche Compliance laut Bericht von 42% auf 82% über elf per API getestete Modell-Setups.
Einige beispielhafte Sprünge, die in den Tabellen genannt werden:
- Bestimmte Modelle lagen im One-piece-Test bei 0%, erreichten aber bei der Zweiteilung bzw. in erweiterten Varianten 100%.
- Für andere Modell-/Client-Kombinationen werden ebenfalls starke Unterschiede beschrieben, teils mit „0%“ in einer konkreten API-Konfiguration, aber „100%“ in einem separaten Cursor-Test-Setup.
Die Forschung betont außerdem: Solche Werte sind nicht als allgemeine „Unbetroffenheits“-Aussage zu lesen. Sie hängen stark von der konkreten Einbindung ab—also davon, wie der jeweilige Client Tool-Aufrufe interpretiert, wie Sicherheitsregeln umgesetzt sind und welche Inhalte in den Tests tatsächlich übergeben wurden.
Hinweis zur Interpretation: nicht nur „das Modell“, sondern der Kontext
Ein besonders relevanter Befund lautet: Dieselbe KI kann in einem Coding-Client die schädliche Anfrage ablehnen, während sie in einem anderen Client-Setup die Exfiltration erfolgreich ausführt. Das unterstreicht, dass der Angriffshebel nicht ausschließlich im Modell selbst liegt.
Vielmehr entscheidet der Sicherheitsumfang in der Umgebung: Welche Prüflogik ist aktiv? Werden Serverausgaben als unzuverlässige Daten behandelt? Fließen Werte aus Tool-Ergebnissen ungeprüft in Argumente anderer Tools?
Genau diese „Sicherheitsgrenze“ um das Modell herum wird in der Disclosure als Schwachpunkt hervorgehoben.
Grenzen des Angriffs: kein „Fernknacken“ ohne Einbindung
GhostSplice ist nicht als Angriff gedacht, bei dem ein Dritter einfach „von außen“ jede beliebige KI-Instanz übernimmt. Die Technik setzt voraus, dass der Entwickler bereits eine Verbindung zu einem (angreifer-gesteuerten) MCP-Server eingerichtet hat.
Außerdem geht es davon aus, dass der Agent bereits Zugriff auf die Dateien hat, deren Inhalte später abfließen sollen. Der Server-Teil liefert damit vor allem die Anleitung bzw. die Platzierung der richtigen Fragmente—aber er kann nicht ohne entsprechenden lokalen Zugriff beliebige Systeme aus der Ferne hacken.
Wie kann man sich gegen GhostSplice MCP-Server schützen?
Die Verteidigung liegt laut den Empfehlungen vor allem im Client und in der Tool-Policy. Die MCP-Spezifikation sieht vor, dass Clients einen menschlichen Gatekeeper haben sollten, der Tool-Aufrufe verweigern kann. Zudem sollen Annotationen und Inhalte untrusted sein, wenn sie von nicht verifizierten Servern stammen.
In der gleichen Richtung warnt auch die generelle Leitlinie, dass gefährliche MCP-Integrationen das Risiko für Prompt Injection erhöhen. Organisationen sollen daher eigene und Drittanbieter-Integrationen sorgfältig prüfen.
Die Disclosure nennt darüber hinaus einen konkreten Ansatz: Serverausgaben sollten als Daten behandelt werden, nicht als Anweisungen. Werte aus Tool-Ergebnissen dürfen außerdem nicht unkontrolliert in Argumente anderer Tools übergehen.
Praktische Konsequenzen für Teams
Für Entwickler und Sicherheitsteams folgt daraus: Nicht nur das Modell, sondern die gesamte Toolkette muss abgesichert werden. Wer MCP nutzt, sollte insbesondere diese Punkte adressieren:
- Allowlisting für Tools und Server: Nur geprüfte Integrationen verwenden.
- Validierung von Tool-Inputs: Prüfen, ob Felder realistisch zu erwartenden Inhalten entsprechen.
- Trennung von Daten und Instruktionen: Tool-Ergebnisse dürfen nicht als neue „Befehle“ interpretiert werden.
- Kontrollierte Datenflüsse: Verhindern, dass sensible Dateiinhalte ohne klare Freigabe weitergereicht werden.
Gerade weil GhostSplice schädliche Absichten in „gewöhnliche“ Formulare und Routinen tarnt, hilft es, harte Regeln für Datenzugriffe und Argument-Weitergaben im Client zu erzwingen.
Fazit: GhostSplice zeigt, wie schnell Kontext zur Angriffsfläche wird
GhostSplice MCP-Server verdeutlichen, wie Angreifer die Interaktion zwischen KI-Agenten und externen Tools ausnutzen können. Indem schädliche Teile aufgesplittet und über Tool-Beschreibungen, Ergebnisse und mehrere Schritte verteilt werden, kann ein Agent am Ende Aktionen durchführen, die in Einzelteilen leicht blockierbar wären.
Die wichtigste Lehre ist damit klar: Sicherheitsgrenzen entstehen nicht nur durch die Fähigkeiten eines Modells, sondern vor allem durch die Art, wie Clients Inhalte interpretieren, verifizieren und Datenströme steuern. Wer MCP einsetzt, sollte Tool-Aufrufe streng kontrollieren und Serverausgaben konsequent als untrusted Daten behandeln.
Quelle: https://thehackernews.com/2026/08/malicious-mcp-servers-can-split.html
