Prompt Hijacking
JFrog entdeckt neue Schwachstelle: Prompt Hijacking gefährdet MCP-Workflows in oatpp-mcp
JFrog entdeckt CVE-2025-6515
Das Security-Research-Team von JFrog hat eine neue Sicherheitslücke in der Oat++-Implementierung des Model Context Protocol (MCP) entdeckt. Die Schwachstelle, registriert als CVE-2025-6515, ermöglicht es Angreifern, laufende KI-Sessions zu kapern und eigene Antworten in bestehende Workflows einzuschleusen. Besonders gefährdet sind Deployments, in denen oatpp-mcp über HTTP/SSE aus dem Netzwerk erreichbar ist.
Das steckt hinter der Entdeckung
Die Analyse zeigt: Es handelt sich nicht um eine klassische Schwachstelle im KI-Modell selbst, sondern um ein Problem auf Protokoll- und Session-Ebene. Dadurch kann das Verhalten ganzer Workflows beeinflusst werden – auch wenn das zugrunde liegende Modell völlig unverändert bleibt.
Neue Angriffsklasse: Prompt Hijacking
Bei diesem Angriff wird nicht das Modell manipuliert , sondern der Kommunikationskanal. Angreifer nutzen Schwächen in der Session-Verwaltung aus, um sich in bestehende Konversationen einzuklinken. Sie können täuschend echte, aber falsche Antworten einschleusen, die für Nutzer legitim erscheinen – weil sie über den gewohnten Client-Kanal eintreffen.
Ursache: Unsichere Session-IDs
Im Kern liegt das Problem bei vorhersehbaren oder unsicheren Session-IDs. Wenn ein Angreifer eine gültige ID errät oder abgreift, kann er eigene Events in eine laufende Session einschleusen. Diese manipulierten Nachrichten können legitime Antworten überlagern oder vom Client bevorzugt verarbeitet werden.
Dieses kurze Video veranschaulicht den Ablauf eines solchen Angriffs
Auswirkungen: Manipulierte Ergebnisse in Entwicklerumgebungen
Die Folgen reichen von irreführenden Empfehlungen in IDEs oder KI-Assistenten über fehlerhafte Code-Vorschläge bis hin zu Risiken in der Lieferkette – etwa wenn manipulierte Artefakte unbemerkt in Build-Prozesse gelangen.
So funktioniert Prompt Hijacking
Prompt Hijacking nutzt aus, wie Antworten in einer Session per Streaming übertragen werden. Entscheidend ist: Der Server ordnet Antworten der Session-ID zu – nicht der Identität des Anfragenden.
- Session-Aufbau: Der Client eröffnet eine Session, der Server weist ihr eine ID zu und verwendet diese als Rückkanal-Adresse.
- Kompromittierung: Gelingt es einem Angreifer, diese ID zu erraten oder über eine Leckage zu erlangen, kann er eigene Requests an die Session senden.
- Einschleusen von Events: Der Server streamt daraufhin auch die bösartigen Antworten über denselben Kanal, wodurch sie für den Client legitim wirken.
- Client-Verhalten als Risikofaktor: Wenn Clients eingehende Events nur oberflächlich prüfen – etwa anhand einfacher Zähler –, steigt das Risiko, dass manipulierte Nachrichten akzeptiert werden.
Wer ist betroffen?
Gefährdet sind vor allem Installationen, bei denen oatpp-mcp über HTTP und SSE erreichbar ist. In der analysierten Implementierung wurde die Session-ID aus der Speicheradresse des Session-Objekts abgeleitet – ein unsicheres Verfahren, da Speicheradressen wiederverwendet werden können. Angreifer können dadurch viele Sessions anlegen, IDs sammeln und erneut zugewiesene IDs für eigene Anfragen nutzen. Wenn Clients eingehende Events nur schwach prüfen, steigt die Wahrscheinlichkeit, dass fremde Nachrichten als echt durchgehen.
Fazit
Prompt Hijacking zeigt deutlich: Die Sicherheit von KI-Workflows hängt nicht allein vom Modell ab, sondern vor allem von den Session- und Transportmechanismen. Selbst wenn das Modell unangetastet bleibt, kann der umgebende Kommunikationskanal kompromittiert werden. JFrog empfiehlt:
- Verwendung kryptographisch starker, eindeutiger Session-IDs (mindestens 128 Bit Entropie)
- Strikte Trennung und zeitliche Begrenzung von Sessions
- Validierung eingehender Events im Client anhand eindeutiger IDs, Typen und Reihenfolgen
- Robuste Transport- und Wiederherstellungsmechanismen, damit verspätete oder manipulierte Events keine Wirkung entfalten
Mit einer solchen gehärteten Architektur lässt sich die Angriffsfläche deutlich reduzieren.
