Ghostjacking: Präparierte Logs übernehmen KI-Coding-Agenten in neun von zehn Fällen
Tenet Security zeigt auf der DEF CON, wie Anweisungen in Logs von Cloudflare, Datadog und Sentry Coding-Agenten kapern. Was Firmen jetzt prüfen sollten.
Eine Web Application Firewall blockiert eine schädliche Anfrage. Das ist der Normalfall, dafür ist sie da. Sie schreibt die abgewehrte Anfrage anschließend Zeichen für Zeichen ins Protokoll, auch das ist der Normalfall. Fragt am nächsten Morgen jemand seinen KI-Assistenten, was in den Logs auffällig war, liest der Assistent den Text des Angreifers als Befund einer vertrauenswürdigen Quelle. Genau an dieser Stelle setzt ein Angriff an, den die israelische Sicherheitsfirma Tenet Security am 9. August 2026 auf der DEF CON 34 in Las Vegas vorgestellt hat. Sie nennt ihn Ghostjacking.
Die Schutzmaßnahme wird zum Zustellweg
Ghostjacking ist eine indirekte Prompt Injection. Der Angreifer schickt seine Anweisung nicht an das Modell, sondern platziert sie dort, wo das Modell später von sich aus nachsieht. Tenet demonstrierte das an drei Plattformen, die in vielen Entwicklungsteams zum Standard gehören: Cloudflare mit den Protokollen blockierter Anfragen, Datadog mit gefälschten Diagnosemeldungen und Sentry mit präparierten Fehlerberichten.
Der Ablauf im Cloudflare-Szenario ist bemerkenswert schlicht. Der Angreifer sendet eine Anfrage, die von der Managed Rule zuverlässig abgewiesen wird. Die Ablehnung ist der Punkt: Erst sie sorgt dafür, dass die Nutzlast wortgetreu im Protokoll landet. Wird der Agent später gebeten, die blockierten Ereignisse durchzusehen, führt er die dort hinterlegte Anweisung aus, schreibt die DNS-Einträge der Domain um und meldet den Vorfall als erledigt. Web- und E-Mail-Verkehr laufen anschließend über den Angreifer.
Die Firewall ist nie ausgefallen. Sie hat nur aufgehört, eine Rolle zu spielen.
So fasst Tenet das Ergebnis zusammen, und der Satz beschreibt das Problem genauer als jede Schwachstellenbeschreibung. Es wird keine Software-Lücke ausgenutzt. Der Agent benutzt ausschließlich die Zugänge, die ihm das Unternehmen selbst erteilt hat.
Neun von zehn Versuchen, keine einzige Warnung
Die Zahlen aus der Untersuchung sind deutlich. Gegen Claude Code funktionierte die Kette in neun von zehn Fällen, und zwar in der Konfiguration, die Cloudflare selbst empfiehlt. Ausgelöst wurde dabei keine einzige Warnmeldung, weil jeder einzelne Schritt aus Sicht der Protokollierung eine legitime Aktion eines berechtigten Werkzeugs ist.
Über die DNS-Manipulation hinaus zeigten die Forscher Codeausführung auf Entwicklerrechnern, das Abziehen von Umgebungsvariablen und Cloud-Zugangsdaten sowie das Hinterlegen dauerhafter Hintertüren in Konfiguration, Speicher und Werkzeugen des Agenten. In einem Fall brachten sie einen Agenten dazu, einen Angriff so aufzubereiten, dass ein zweiter Agent ihn akzeptierte.
Nicht der erste Fall dieser Bauart
Ghostjacking ist die Fortsetzung einer Forschungslinie. Im Juni 2026 hatte dieselbe Firma unter dem Namen Agentjacking gezeigt, dass ein einzelner gefälschter Fehlerbericht in Sentry ausreicht, um einen Coding-Assistenten fremden Code auf dem Entwicklerrechner ausführen zu lassen. Der Unterschied liegt in der Reichweite: Agentjacking endete auf der Maschine des Entwicklers, Ghostjacking greift in die Infrastruktur des Unternehmens ein. Die Meldung an Datadog datiert Tenet auf den 17. Juni 2026.
Der Zeitpunkt der Veröffentlichung ist für Anwender von Claude Code zusätzlich relevant. Anthropic stellt das Werkzeug am 14. August auf den Auto-Modus als Standard um, in dem Shell-, Git- und Werkzeugaufrufe ohne Rückfrage laufen. Wer beides kombiniert, also weniger Rückfragen und Zugriff auf Observability-Plattformen, verkürzt genau den Weg, den Ghostjacking nutzt.
Was das für Ihr Unternehmen heißt
- Logs sind Eingabedaten, keine Befunde. Alles, was ein Angreifer in ein Protokoll schreiben kann, muss ein Agent als nicht vertrauenswürdigen Text behandeln. Das gilt für Firewall-Logs, Monitoring-Alarme und Fehlerberichte gleichermaßen.
- Die Rechte des Agenten sind die Rechte des Angreifers. Prüfen Sie, welche Tokens und Zugänge Ihre KI-Werkzeuge tatsächlich besitzen. Ein Agent, der Logs lesen soll, braucht keine Schreibrechte auf DNS-Einträge.
- Trennen Sie Lesen und Handeln. Eine Analyse von Protokolldaten und eine Änderung an der Produktivumgebung sollten nicht in derselben Sitzung mit denselben Berechtigungen ablaufen.
- Automatisch heißt unbeobachtet. Je weniger Rückfragen ein Agent stellt, desto weniger Gelegenheit hat ein Mensch, eine unsinnige Aktion zu bemerken. Die Umstellung auf den Auto-Modus am 14. August ist ein guter Anlass, die eigene Konfiguration anzusehen.
- Persistenz gehört in die Prüfung. Konfiguration, Speicher und Werkzeugdefinitionen eines Agenten sind mögliche Ablageorte für Hintertüren. Sie tauchen in klassischen Schwachstellenscans nicht auf.
- Klassische Abwehr greift hier nicht. Firewall, Endpoint-Schutz und Signaturprüfung sehen legitime Aufrufe mit gültigen Zugangsdaten. Die Kontrolle muss auf der Ebene der Agentenberechtigungen ansetzen.
Einordnung für die Praxis
Der Angriff ist kein Sonderfall für Konzerne mit großen Entwicklungsabteilungen. Sobald ein Coding-Assistent an eine Plattform angebunden wird, in der außenstehende Personen Text hinterlassen können, entsteht dieselbe Konstellation. Ein Kontaktformular, das Fehler nach Sentry meldet, reicht dafür aus.
Wer KI-Werkzeuge in der Entwicklung einsetzt, sollte deshalb einmal aufschreiben, welche Datenquellen ein Agent liest und welche Systeme er verändern darf. Wenn sich diese beiden Listen berühren, gibt es Arbeit. Bei der Bestandsaufnahme und beim Setzen sinnvoller Grenzen unterstütze ich Sie gern.
