Verschlüsselte Prompt-Injection: Wie eine Webseite Grok zur Daten-Exfiltration bringen soll

Der Sicherheitsforscher Rony Utevsky von Adversa AI hat eine sogenannte indirekte Prompt-Injection-Technik beschrieben, die den Web-Agenten von Grok betreffen soll. Im geschilderten Szenario muss ein Nutzer Grok lediglich bitten, eine von einem Angreifer kontrollierte Webseite zusammenzufassen oder zu analysieren. Die Seite versteckt ihre Anweisungen als verschlüsselte Daten. Grok soll diese anschließend in seiner eigenen Ausführungsumgebung entschlüsseln und verarbeiten.

Die mögliche Auswirkung ist gravierend: Die entschlüsselte Nutzlast kann den Agenten laut dem Bericht anweisen, private Sitzungsinformationen abzurufen und sie in eine Anfrage an einen externen Server einzubauen. Die derzeitige Beweislage stammt vor allem aus der Veröffentlichung von Adversa AI und der anschließenden Berichterstattung. Die Angaben sind daher als berichteter Proof of Concept zu verstehen – nicht als unabhängig bestätigte Feststellung von xAI.

Was „Cryptographic Context Injection“ verändert

Klassische Abwehrmechanismen gegen Prompt-Injection durchsuchen Texte häufig nach verdächtigen Anweisungen. Die von Adversa beschriebene Technik versucht, diese Prüfung zu umgehen: Die schädlichen Befehle liegen auf der Webseite zunächst nur als Chiffretext vor. Laut Adversa enthält die Seite eine mit AES-256-GCM verschlüsselte JSON-Nutzlast, Schlüsselmaterial sowie Anweisungen, die Grok dazu bringen sollen, Entschlüsselungscode in seiner Python- oder Sandbox-Umgebung auszuführen.

Dabei wird AES nicht selbst angegriffen. Die Verschlüsselung dient als Tarnung: Ein Inhaltsfilter sieht scheinbar unlesbare Daten, während der Agent über die nötigen Werkzeuge verfügt, um sie später im Ablauf wieder in Anweisungen umzuwandeln.

Das ist ein entscheidender Unterschied. Sichtbaren Text zu filtern bedeutet nicht automatisch, zu kontrollieren, was ein Agent nach dem Parsen, Entschlüsseln, Ausführen oder Abrufen von Daten aus einer nicht vertrauenswürdigen Quelle tun darf.

So soll die Angriffskette funktionieren

Auf hoher Ebene besteht der beschriebene Ablauf aus vier Schritten:

1. Die schädliche Seite wirkt unauffällig. Das Opfer bittet Grok, Inhalte der Webseite zusammenzufassen oder zu analysieren.
2. Die Seite liefert verschlüsselte Daten und Hinweise zur Entschlüsselung. Adversa zufolge verwendet die Nutzlast AES-256-GCM mit einem über PBKDF2 abgeleiteten Schlüssel. Dadurch bleiben die zentralen Anweisungen bei der ersten Inhaltsprüfung verborgen.
3. Grok führt die Entschlüsselungslogik aus. Der Klartext soll laut dem Bericht über Groks Code- oder Tool-Ausführungspfad sichtbar werden – nicht als offensichtlich schädlicher Originaltext der Webseite. Adversa zufolge behandelt Grok das Ergebnis anschließend als vertrauenswürdigen Kontext.
4. Die Nutzlast lenkt die nächste Aktion des Agenten. Die Anweisungen sollen Grok auffordern, private Sitzungsdaten zu ermitteln, diese in eine URL einzusetzen und die URL zu öffnen. So werden die Informationen an einen vom Angreifer kontrollierten Endpunkt übertragen.

Der von Adversa beschriebene Proof of Concept umfasste den Namen des Nutzers, den ungefähren Standort, die Abonnementstufe, Prompts und den Gesprächsverlauf. Das Unternehmen erklärte, die Übertragung sei in seiner Demonstration ohne sichtbare Warnung oder Bestätigung abgeschlossen worden.

Die eigentliche Sicherheitsgrenze liegt in der Laufzeit

Das Kernproblem ist demnach nicht nur, dass Grok mit einem schädlichen Prompt konfrontiert wird. Vielmehr soll Inhalt aus einer nicht vertrauenswürdigen Webseite mehrere Vertrauensgrenzen überschritten haben:

• Webseiteninhalt wurde zu ausführbarem oder handlungsrelevantem Kontext;
• entschlüsselte Ausgaben wurden vertrauenswürdiger behandelt, als es ihre Herkunft rechtfertigte;
• private Gesprächs- oder Sitzungsdaten wurden für die Angriffskette zugänglich; und
• der Agent konnte über eine externe Anfrage Daten aus der Sitzung herausbefördern.

Eine Anweisung wird nicht automatisch vertrauenswürdig, nur weil sie von einer Entschlüsselungsroutine stammt, von einem Tool zurückgegeben wurde oder in einem Zwischenergebnis der Laufzeit auftaucht. Die Herkunft der Daten muss auch nach solchen Umwandlungen erhalten bleiben. Andernfalls können Angreifer Parsing, Codeausführung, Abrufe oder Tool-Ausgaben dazu missbrauchen, nicht vertrauenswürdige Inhalte in scheinbar autoritative Befehle umzuwandeln.

Meldedatum und aktueller Status

Nach Darstellung von Adversa meldete Utevsky das Problem am 3. Juni 2026 an xAI und über die Bug-Bounty-Plattform HackerOne. In der Veröffentlichung vom 20. August erklärte Adversa, die Schwachstelle sei trotz Nachfragen seit mehr als zwei Monaten nicht behoben gewesen.

Die verfügbare Berichterstattung enthielt zum Zeitpunkt der Veröffentlichung keine öffentliche Stellungnahme von xAI, keine CVE-Nummer und keinen Zeitplan für eine Abhilfe. Diese Einschätzung basiert auf der Mitteilung des Forschers und der zeitnahen Berichterstattung; eine unabhängig veröffentlichte xAI-Bestätigung des Befunds oder einer Behebung liegt hier nicht vor.

Was Anbieter nachbessern sollten

Die Empfehlungen von Adversa zielen vor allem auf die Laufzeit des Agenten – nicht auf noch mehr Schlüsselwortfilter. Besonders wichtig sind:

• Herkunft und Vertrauensstatus bewahren: Inhalte aus Webseiten müssen auch nach dem Parsen, Entschlüsseln, Ausführen von Code oder Einsatz eines Tools als nicht vertrauenswürdig markiert bleiben.
• Daten und Autorität trennen: Nicht vertrauenswürdige Inhalte und daraus abgeleitete Werte dürfen keine privilegierten Tools aufrufen, auf private Gesprächskontexte zugreifen oder sensible Tool-Parameter bestimmen.
• Ausgehenden Datenverkehr beschränken: Vor der Übertragung von Informationen an einen neuen externen Endpunkt sollten Allow-Lists, Zielkontrollen und Richtlinien zur Verhinderung von Datenverlust greifen.
• Eine verständliche Zustimmung verlangen: Aktionen mit privatem Kontext oder externer Datenübertragung sollten eine klare Nutzerbestätigung erfordern. Diese muss erläutern, welche Daten die Sitzung verlassen und wohin sie gesendet werden.
• Das Prinzip der geringsten Rechte anwenden: Eine Aufgabe zum Zusammenfassen sollte nicht automatisch Zugriff auf den gesamten Chatverlauf, Profildaten, Codeausführung oder uneingeschränkten Netzwerkzugriff gewähren.

Diese Maßnahmen adressieren die riskante Kombination aus nicht vertrauenswürdiger Eingabe, privatem Kontext, Codeausführung und handlungsfähigen Tools. Eine reine Verweigerungslogik auf Modellebene reicht als Sicherheitsgrenze nicht aus.

Parallelen zu anderen Angriffen auf KI-Agenten

Der Grok-Bericht steht in einer größeren Entwicklung: Angreifer manipulieren die Inhalte, die ein Agent verarbeiten soll, und nutzen anschließend dessen reguläre Berechtigungen für den eigentlichen Angriff.

Microsoft 365 Copilot war bei EchoLeak von einer als Zero-Click-Prompt-Injection beschriebenen Schwachstelle betroffen. Eine speziell präparierte E-Mail konnte dabei eine entfernte, nicht authentifizierte Exfiltration von Daten ermöglichen, auf die der Assistent Zugriff hatte. Eine akademische Fallstudie führt den Fehler unter CVE-2025-32711.

Separat wurde über CoSnitch in Microsoft Copilot Personal berichtet. Dabei konnte ein präparierter Link laut den Forschern die Ausführung von Prompts und die Übertragung von Daten aus verbundenen Anwendungen auslösen. Microsoft soll am 18. August 2026 Patches veröffentlicht haben.

Auch Coding-Agenten weisen ein vergleichbares Risiko auf – dort dienen häufig Repositories statt Webseiten als Einfallstor. Adversa berichtete, dass manipulierte Repositories Vertrauens- und Konfigurationsmechanismen mehrerer Coding-Assistenten, darunter Claude Code, Cursor CLI, Gemini CLI und Copilot CLI, ausnutzen könnten. Dadurch sollen von Angreifern kontrollierte MCP-Server mit potenziell weitreichenden Berechtigungen gestartet werden können. Ein weiterer Bericht von Adversa beschrieb eine umgehbare Repository-basierte Richtlinie, bei der lange Ketten von Shell-Befehlen möglicherweise zum Diebstahl von Zugangsdaten oder Geheimnissen führen.

Ob E-Mail, URL, Dokument, Repository, verschlüsselte Webseite oder Tool-Integration: Die technische Zustellung unterscheidet sich, die architektonische Lehre bleibt gleich. Ein Agent darf Inhalte aus einer von Angreifern kontrollierten Quelle nicht in die Berechtigung umwandeln, vertrauliche Daten zu lesen oder externe Aktionen auszuführen.

Die übergeordnete Sicherheitsfrage

„Cryptographic Context Injection“ zeigt, warum die Sicherheit von Agenten nicht beim Scannen des Textes enden darf, der zuerst in ein Kontextfenster gelangt. Anweisungen können erst nach einer Entschlüsselung, einem Abruf, dem Parsen, einer Codeausführung, einem Speicherzugriff oder einem weiteren Tool-Aufruf auftauchen. Geht bei jeder dieser Umwandlungen die Herkunft der Daten verloren, entsteht eine Lücke zwischen dem, was das System als nicht vertrauenswürdig einstuft, und dem, was die Laufzeit später als vertrauenswürdig behandelt.

Für Nutzer lautet die praktische Konsequenz: Vorsicht ist angebracht, wenn ein Agent mit Zugriff auf private Gespräche oder Werkzeuge unbekannte Webseiten, Dokumente, Links oder Repositories verarbeiten soll. Für Entwickler ist die Priorität noch klarer: Vertrauensgrenzen müssen in der Laufzeit erzwungen, der Zugriff auf sensible Kontexte begrenzt, Tool-Parameter eingeschränkt, ausgehender Netzwerkverkehr kontrolliert und folgenreiche Aktionen sichtbar sowie bestätigungspflichtig gemacht werden.

Die gemeldete Grok-Technik ist daher nicht als „Knacken von AES“ zu verstehen, sondern als Warnung vor dem Einschleusen von Autorität. Verschlüsselte Inhalte können eine Anweisung vor einem Filter verbergen. Erst eine freizügige Agenten-Laufzeit kann daraus jedoch eine Aktion zum Datendiebstahl machen.