CVE-2025-6515 – Prompt Hijacking bedroht MCP-Workflows in oatpp-mcp.
Eine neue Untersuchung von JFrog Security Research offenbart in der Oat++-Implementierung des Model Context Protocol (MCP) eine Schwachstelle (CVE-2025-6515), über die Angreifer Sessions kapern und Antworten in laufende KI-Workflows einschleusen können. Betroffen sind Konfigurationen/Deployments, in denen oatpp-mcp den HTTP/SSE-Transport nutzt und aus dem Netzwerk erreichbar ist.
Zusammenfassung (TL; DR):
- Neue Angriffsklasse: Prompt Hijacking nutzt Schwächen in MCP-Session-Mechanismen aus
- Folge sind manipulierte Ergebnisse in typischen Umgebungen wie IDEs oder KI-Assistenten
- Betroffen sind Installationen, die oatpp-mcp mit HTTP + SSE betreiben und deren SSE-Endpunkt aus dem Netzwerk erreichbar ist
Die Analyse zeigt, dass es sich nicht um eine klassische Modellschwachstelle handelt, sondern um eine protokoll- und sessionbezogene Schwachstelle, die das Verhalten des gesamten Workflows beeinflusst.
- Neue Angriffsklasse: Prompt Hijacking nutzt Schwächen in MCP-Session-Mechanismen aus, ohne das Modell selbst zu verändern. Das KI-Modell bleibt unangetastet; stattdessen wird der Antwortkanal manipuliert. So entstehen täuschend echte, aber falsche Assistentenantworten, die aus Sicht der Nutzer legitim wirken, weil sie über den gewohnten Client-Kanal eintreffen.
- Ursache: Kern des Problems sind vorhersehbare oder unsichere Session-IDs. Gelingt es, eine gültige ID zu erraten oder abzugreifen, lassen sich fremde Events in bestehende Sessions einschleusen. Diese Events können legitime Antworten überlagern oder so getimt werden, dass der Client sie bevorzugt verarbeitet.
- Auswirkungen: Die Folge sind manipulierte Ergebnisse in typischen Umgebungen wie IDEs oder KI-Assistenten – von falschen Empfehlungen (z. B. Paket-/Abhängigkeitsvorschläge) über irreführende Code-/Konfigurationsänderungen bis hin zu Risiken für die Lieferkette, wenn bösartige Artefakte unbemerkt in Entwicklungsprozesse einfließen.
Wie Prompt Hijacking funktioniert
Die Technik nutzt aus, wie Antworten an eine Session gebunden und per Streaming übertragen werden. Entscheidend ist, dass der Server Antworten anhand der Session-ID adressiert – nicht anhand der Identität des Anfragenden.
- Aufbau der Session: Der MCP-Client eröffnet per SSE eine Session; der Server verknüpft alle nachfolgenden Antworten mit einer Session-ID. Diese ID fungiert als „Adresse“ für den Rückkanal und ist damit die alleinige Vertrauensgrundlage für die Zuordnung.
- ID-Kompromittierung: Erlangt ein Angreifer diese ID – etwa durch Raten, Leckage oder Wiederverwendung vorhersagbarer IDs –, kann er eigene POST-Requests an genau diese Session senden. Aus Serversicht sind solche Anfragen nicht zuverlässig vom legitimen Client unterscheidbar.
- Einschleusen von Events: Der Server streamt Antworten zu allen Anfragen, die er der Session zuordnet. Bösartige Events landen im bestehenden Client-Kanal und können legitime Ergebnisse verdrängen oder verfälschen, abhängig von Timing, Inhalt und der Verarbeitung im Client.
- Client-Verhalten als Verstärker: Wenn Clients nur einfache, fortlaufende Event-Zähler nutzen oder erwartete Nachrichten nur oberflächlich prüfen, lässt sich der Schutz leicht umgehen. Ohne strenge Validierung – etwa mit eindeutig identifizierbaren Event-IDs sowie Prüfungen von Typ und Reihenfolge – steigt das Risiko, dass fremde Events akzeptiert und verarbeitet werden.
Wer ist betroffen und wie groß ist die Bedrohung?
Betroffen sind Installationen, die oatpp-mcp mit HTTP + SSE betreiben und deren SSE-Endpunkt aus dem Netzwerk erreichbar ist. Besonders gefährdet sind Umgebungen mit vorhersehbaren oder wiederverwendbaren Session-IDs; in der untersuchten Implementierung wurde die ID aus der Speicheradresse des Session-Objekts abgeleitet. Da Speicherallokatoren Adressen recyceln, können Angreifer viele Sessions anlegen und schließen, IDs sammeln und erneut zugewiesene IDs für eigene Requests nutzen. Das Risiko steigt, wenn Clients eingehende Events nur schwach prüfen, etwa mit einfachen Zählern, und dadurch fremde Nachrichten eher akzeptieren.
Fazit
Prompt Hijacking verdeutlicht, dass die Sicherheitslage von KI-Workflows maßgeblich durch Session- und Transportmechanismen bestimmt wird: Angriffe können das Ökosystem rund um das Modell kompromittieren, ohne das Modell selbst zu verändern. Effektive Abwehr verlangt kryptographisch starke, global eindeutige Session-IDs (mindestens 128 Bit Entropie) auf Server-Seite, klare Trennung von Sessions, strikte Timeouts sowie eine konsequente Event-Validierung im Client, die nur erwartete, unvorhersehbar gekennzeichnete Events akzeptiert und alles andere verwirft. Ergänzend sind robuste Ablauf- und Wiederherstellungsmechanismen im Transport unerlässlich, damit manipulierte oder verspätete Events keine Wirkung entfalten. Mit dieser Kombination aus starker Session-Verwaltung, gehärteter Client-Logik und soliden Protokollregeln lässt sich die Angriffsfläche signifikant reduzieren.
Den Ablauf eines Prompt-Hijacking-Angriffs veranschaulicht ein kurzes Video.
