Grok-Angriff mit verschlüsselten Anweisungen könnte Chatdaten abgreifen

Der entschlüsselte Text gelangt danach als Ausgabe eines Tools zurück in den Kontext des Modells. Genau hier entsteht das zentrale Vertrauensproblem: Kontrollierte Inhalte des Angreifers erscheinen nicht mehr nur als unzuverlässiger Webseiten-Text, sondern als Ergebnis einer scheinbar legitimen Werkzeugausführung.

Adversa testete die Methode nach eigenen Angaben gegen Grok 4.5 Fast auf grok.com. In einem separaten Bericht war der Angriff zwischen Juni und August 2026 bei 20 Versuchen in 40 Prozent der Fälle erfolgreich. Das beschreibt die Testumgebung der Forscher – es ist keine Aussage darüber, dass jede Sitzung oder jeder Versuch zwangsläufig betroffen wäre.

So läuft der Angriff ab

Die von Adversa beschriebene Angriffskette besteht aus mehreren Schritten:

1. Die Webseite enthält die versteckte Nutzlast. Ein Angreifer platziert Chiffretext, Entschlüsselungsanweisungen und Schlüsselmaterial auf einer Seite, die wie gewöhnlicher Inhalt aussehen kann. Zum Einsatz kommen laut Bericht PBKDF2 zur Schlüsselableitung und AES-256-GCM zur Verschlüsselung.

2. Die erste Prüfung erkennt den Befehl nicht. Groks Filter können sichtbare Seiteninhalte untersuchen. Der gefährliche Befehl liegt jedoch verschlüsselt vor und ist bei diesem Prüfschritt nicht als Klartext verfügbar.

3. Grok führt die Entschlüsselung aus. Nachdem der Nutzer Grok zum Zusammenfassen oder Analysieren der Seite aufgefordert hat, folgt der Agent den dort eingebetteten Anweisungen und startet den Entschlüsselungsvorgang in seiner Code-Umgebung.

4. Der Befehl kehrt als Tool-Ausgabe zurück. Der entschlüsselte Text wird als Ergebnis einer Werkzeugaktion präsentiert. Dadurch kann der Agent den Angreiferinhalt anders bewerten als eine direkte, offensichtlich nicht vertrauenswürdige Anweisung auf der Webseite.

5. Private Sitzungsdaten werden aus dem Kontext gelesen. Im Proof of Concept sollte Grok unter anderem den Namen des Nutzers, den ungefähren Standort, die Abo-Stufe und Prompts aus der verfügbaren aktiven Unterhaltung ermitteln.

6. Eine Browser-Anfrage überträgt die Daten. Grok öffnete anschließend eine vom Angreifer kontrollierte URL und übergab die gesammelten Werte als URL-Parameter. In der Demonstration erfolgte dies ohne zusätzliche sichtbare Bestätigung oder Warnung.

Wichtig ist die Reichweite des Nachweises: Die verfügbaren Informationen belegen den Zugriff auf Prompts und Kontext, die dem Agenten in der aktiven Sitzung zugänglich waren. Die Formulierung „vollständiger Chatverlauf“ sollte daher nicht automatisch so verstanden werden, als könne Grok auf jede jemals im Nutzerkonto gespeicherte Unterhaltung zugreifen.

Wann wurde xAI informiert?

Adversa teilte nach eigenen Angaben am 3. Juni 2026 über HackerOne mit, dass die Schwachstelle an xAI gemeldet worden sei. Am 4. und 10. August folgten weitere Versuche, die Offenlegung zu koordinieren.

Zum Stand vom 19. August 2026 erklärte Adversa, keine inhaltliche Antwort erhalten zu haben. Die Sicherheitsfirma gab außerdem an, den Angriff gegen Grok weiterhin reproduzieren zu können. Die damalige Berichterstattung nannte keinen veröffentlichten Fix, keine CVE-Nummer und keine nutzerseitige Umgehungslösung.

Diese Angaben stammen aus der Darstellung der Forscher und der darüber berichtenden Medien – nicht aus einer öffentlichen Sicherheitsmitteilung von xAI. Die vorliegenden Quellen belegen außerdem nicht, dass die Methode außerhalb der Demonstrationen gegen tatsächliche Nutzer eingesetzt wurde.

Warum Verschlüsselung eine blinde Stelle schaffen kann

Viele Schutzmechanismen gegen Prompt-Injection suchen nach verdächtigen Formulierungen in den Inhalten, die ein KI-System abruft. Bei Cryptographic Context Injection wird der gefährliche Befehl jedoch in eine spätere Verarbeitungsphase verschoben.

Grok muss den schädlichen Text beim ersten Lesen der Seite nicht verstehen. Es reicht, wenn der Agent eine scheinbar nützliche Anweisung befolgt – etwa ein Entschlüsselungsskript auszuführen. Erst danach wird der Befehl lesbar. Zu diesem Zeitpunkt kann der Agent bereits Zugriff auf privaten Gesprächskontext sowie auf Browser- und Netzwerkfunktionen haben.

Damit handelt es sich weniger um ein simples Versagen eines Stichwortfilters als um ein Architekturproblem von KI-Agenten. Sobald ein Agent externe Inhalte lesen, Code ausführen, Sitzungsdaten verwenden und Netzwerkwerkzeuge aufrufen kann, lässt sich diese Kombination als Weg zum Datenabfluss missbrauchen.

Ein Teil des größeren Problems mit KI-Agenten

Der Fall reiht sich in eine wachsende Zahl von Untersuchungen ein, bei denen nicht das zugrunde liegende Modell oder Betriebssystem direkt kompromittiert wird. Stattdessen liefern Angreifer Inhalte, die ein Agent bestimmungsgemäß lesen soll – und nutzen anschließend dessen eigene Berechtigungen aus.

• EchoLeak bei Microsoft 365 Copilot: Eine Fallstudie dokumentierte eine Zero-Click-Prompt-Injection-Schwachstelle, durch die eine präparierte E-Mail eine entfernte und nicht authentifizierte Datenübertragung auslösen konnte. Die Schwachstelle wird als CVE-2025-32711 geführt.
• CoSnitch bei Microsoft Copilot Personal: Varonis-Forscher berichteten, dass wiederholte Manipulationen der Schlussfolgerungen von Copilot dazu führen konnten, dass vertrauliche Daten an einen externen Server gesendet und dauerhafte Erinnerungen manipuliert wurden.
• Angriffe auf Coding-Agenten: In Adversas TrustFall-Forschung konnte eine manipulierte Repository-Konfiguration unter anderem Claude Code, Gemini CLI, Cursor CLI und GitHub Copilot CLI dazu bringen, einen vom Angreifer kontrollierten MCP-Server aufzurufen und Befehle auszuführen.

Der gemeinsame Nenner: Der Angreifer muss nicht unbedingt das Modell selbst knacken. Es genügt, Inhalte einzuschleusen, die der Agent verarbeitet. Dessen Berechtigungen können dann zum Abrufen von Informationen, Aufrufen von Werkzeugen, Ändern von Zuständen oder Senden von Netzwerk-Anfragen missbraucht werden.

Welche Schutzmaßnahmen sich daraus ableiten lassen

Der Fall zeigt, dass stärkere Prompt-Injection-Filter allein nicht ausreichen. Sinnvolle Schutzmaßnahmen sind unter anderem:

• Herkunft klar trennen: Webseiteninhalte und Tool-Ausgaben müssen technisch und sichtbar von Systemanweisungen sowie vertrauenswürdigen Anwendungsdaten getrennt bleiben.
• Code-Ausführung begrenzen: Abgerufene Inhalte sollten nicht ohne eine streng kontrollierte Richtlinie beliebige Entschlüsselungs- oder andere Skripte ausführen dürfen.
• Das Prinzip der geringsten Rechte anwenden: Ein Agent sollte nur auf den für die Aufgabe nötigen privaten Kontext zugreifen können.
• Sensible Aktionen bestätigen lassen: Netzwerk-Anfragen, die Nutzer- oder Gesprächsdaten enthalten, sollten eine ausdrückliche und verständliche Zustimmung erfordern.
• Ausgehenden Datenverkehr kontrollieren: Domain-Allowlisten, Proxy-Prüfungen und Egress-Kontrollen können verhindern, dass Agenten Kontextdaten an beliebige URLs senden.
• Werkzeugketten überwachen: Ungewöhnliche Abfolgen wie Webseitenabruf, Code-Ausführung, Kontextauslese und anschließende externe Navigation sollten protokolliert und alarmiert werden.

Die zentrale Lehre lautet: Eine Ausgabe wird nicht automatisch vertrauenswürdig, nur weil sie von einem Tool stammt. Im beschriebenen Grok-Fall wurde eine Webseite zur Entschlüsselungs- und Ausführungskette – und anschließend konnten die eigenen Berechtigungen des Agenten genutzt werden, um privaten Kontext aus der Sitzung heraus zu übertragen.