Prompt Injection bei Claude Code, Gemini CLI und Codex: die Black-Hat-Lücke

Ein öffentliches GitHub-Issue kann jeder öffnen. Kein Login außer einem kostenlosen Account, keine besonderen Rechte, kein Vertrauensvorschuss nötig. Genau diese niedrige Hürde reichte aus, um in drei völlig unabhängigen KI-Coding-Werkzeugen Codeausführung und gestohlene Zugangsdaten zu erzwingen – und zwar jedes Mal mit demselben simplen Trick. Vorgestellt wurden die Ergebnisse auf der Black Hat USA 2026 in Las Vegas, und im Kern geht es dabei gar nicht um drei separate Bugs. Es geht darum, was passiert, wenn ein Werkzeug, das eigentlich nur Code lesen soll, plötzlich alles andere mitliest – und den Unterschied nicht erkennt.

Was ein Coding-Agent wirklich tut, sobald er in deiner Pipeline hängt

Die Grundidee von Zero Trust lautet: Nichts bekommt automatisches Vertrauen, nur weil es schon im Netzwerk sitzt. Genau das ignorieren diese Werkzeuge standardmäßig. Ein Coding-Agent ist Software, die einen Prompt liest, selbst entscheidet, welche Codeänderungen oder Befehle nötig sind, und diese eigenständig ausführt – oft mitten in einer Continuous-Integration-Pipeline (ein automatisiertes System, das bei jeder Änderung im Repository Code, Tests und Skripte laufen lässt, ohne dass jemand einen Knopf drücken muss). Hängt man so einen Agenten an ein öffentliches Code-Repository, kann er Bug-Reports sortieren, Fixes vorschlagen, auf Kommentare reagieren oder Wartungsaufgaben automatisch erledigen.

Der Komfort ist real. Genau darin liegt aber auch das Risiko. Ein Agent, der in solche Automatisierung eingebunden ist, sieht nicht nur den Code, den du geschrieben hast. Er sieht alles, was auf der öffentlichen Seite des Repositorys landet: Issue-Texte von Fremden, Kommentare, Konfigurationsdateien, kurz alles, was durch die Pipeline läuft, die er beobachtet. Wer einen Coding-Assistenten an so ein Setup angeschlossen hat oder das vorhat, sollte sich nicht fragen, ob das Tool clever genug ist. Die eigentliche Frage lautet, ob es zuverlässig zwischen “Inhalt zum Zusammenfassen” und “Anweisung zum Befolgen” unterscheiden kann.

Dieselbe Verwechslung, dreimal unabhängig gefunden

Auf der Black Hat präsentierten Forscher der Sicherheitsfirma Novee Security einen Vortrag mit dem Titel “Trusted Enough to Run: Breaking AI Agents in Official Workflows”. Darin gingen sie drei Coding-Agenten von drei verschiedenen Anbietern durch, die alle an demselben Test scheiterten. In jedem Fall platzierte ein Außenstehender ohne jegliche Repository-Rechte versteckte Anweisungen in Inhalten, die der Agent routinemäßig verarbeitete – meistens ein öffentliches GitHub-Issue. Sobald die automatisierte Pipeline diesen Inhalt aufgriff, behandelte der Agent ihn nicht als Bug-Report zum Lesen. Er behandelte ihn als Befehl zum Ausführen – ein Muster, das Sicherheitsforscher Prompt Injection nennen.

Diese eine Verwechslung öffnete, einmal ausgelöst, die Tür zu ernsten Konsequenzen: beliebige Befehle auf der Maschine ausführen, die die Pipeline betreibt; Dateien und Geheimnisse lesen, die eigentlich privat bleiben sollten; oder Anweisungen einschleusen, die still liegen bleiben und später erneut befolgt werden. Nichts davon erforderte ein erratenes Passwort oder eine Netzwerklücke. Der Einstiegspunkt war öffentlicher, nicht authentifizierter Text, den die Software vertrauensvoll automatisch verarbeitet hatte.

Elad Meged, Gründungsingenieur bei Novee und einer der Forscher hinter dem Vortrag, brachte es im Bericht des Teams auf den Punkt: Diese Werkzeuge wurden gebaut, um in Automatisierung nützlich zu sein – und genau dieses Design macht sie für jeden erreichbar, der Text in das richtige Feld schreiben kann. Noveés eigener Bericht ist die genaueste Quelle zu den Details und lohnt die vollständige Lektüre, wenn eines dieser Produkte bei dir in CI läuft.

Claude Code: eine Kette, die in einem Datenleck über einen öffentlichen Zähler endete

Anthropics Kommandozeilen-Tool Claude Code (nicht zu verwechseln mit der Claude-Chat-App) war von einer Schwachstelle betroffen, die als CVE-2026-54316 geführt und in Version 2.1.163 behoben wurde. Eine CVE, kurz für Common Vulnerabilities and Exposures, ist schlicht der öffentliche Katalogeintrag, den MITRE einer offengelegten Sicherheitslücke zuweist, damit Forscher, Hersteller und Verteidiger vom selben Problem unter derselben Nummer sprechen.

Claude Code – Anthropics agentisches Coding-Tool, das im Terminal und in CI-Pipelines läuft.

Hier lohnt sich eine Trennung: Was ist offiziell bestätigt, was beschreibt der Forscher zusätzlich. Der CVE-Text selbst nennt nur eines: einen Kanal zum Datenabfluss, außerhalb des üblichen Netzwerkpfads, über eine Domain, die das Tool vorab freigegeben hatte, ohne einzuschränken, welche Pfade darauf abgerufen werden durften. Ein Angreifer konnte einen gestohlenen API-Schlüssel Zeichen für Zeichen abziehen, indem er Hugging Faces öffentlichen Zähler für Modell-Downloads missbrauchte – eine für jeden sichtbare Zahl, die sich als unwahrscheinlicher, aber funktionierender Nebenkanal zum Datenschmuggel eignete. Novee Security, das die Lücke fand, beschreibt eine längere Kette bis zu diesem Schritt, darunter einen Weg zur Befehlsinjektion und eine Methode, beliebige Dateien zu lesen. Diese breitere Darstellung ist von Anthropic aber nicht unabhängig bestätigt worden; der offizielle CVE-Eintrag nennt ausschließlich den Hugging-Face-Kanal zum Datenabfluss. Die Lücke betraf Claude Code in den Versionen 0.2.54 bis 2.1.162 und wurde mit 2.1.163 geschlossen. Anthropic hatte schon zuvor mehrere kleinere Patches ausgeliefert, zu breite Shell-Berechtigungsregeln entfernt und die Hugging-Face-Domain eingeschränkt, bevor die CVE offiziell vergeben wurde.

Gemini CLI: eine Sandbox, die schon vor dem Start umgangen werden konnte

Googles Gemini CLI (auch hier zu unterscheiden von der Gemini-Chat-App oder dem zugrunde liegenden Modell) trug die schwerwiegendste Einstufung der drei Fälle: CVE-2026-12537 mit einem CVSS-Wert von 10.0, dem Maximum auf dieser Skala. CVSS, das Common Vulnerability Scoring System, ist eine Branchenformel, die bewertet, wie ernst eine Schwachstelle ist – von 0 bis 10, je nachdem, wie leicht sie ausnutzbar ist und wie viel Schaden sie anrichten kann. Die vollständige Advisory ist unter der GitHub-Security-Advisory-ID GHSA-wpqr-6v78-jr5g dokumentiert.

Die eigentliche Ursache war eine Befehlsinjektion auf Betriebssystemebene im Starter, der für den Aufbau der Sandbox zuständig ist – jenem isolierten Container, der eigentlich alles einsperren soll, was der Agent tut. Eine präparierte .gemini/.env-Konfigurationsdatei konnte Codeausführung auf dem Host-Rechner auslösen, noch bevor die Sandbox überhaupt gestartet war, und hebelte die Isolation damit komplett aus. Ein zweiter, verwandter Fehler ließ einen eigentlich eingesperrten Kindprozess die Geheimnisse des Elternprozesses auslesen, darunter GitHub-Tokens und Gemini-API-Schlüssel, über eine Linux-Systemdatei (/proc/$PPID/environ), die die Umgebungsvariablen eines laufenden Prozesses offenlegt. Google behob beide Probleme in Gemini CLI Version 0.39.1, zusammen mit einem Update des begleitenden Tools, und der Fix brachte eine bewusste, breaking Änderung daran mit sich, wie viel Vertrauen das Tool unbeaufsichtigten Läufen standardmäßig entgegenbringt. Noveés Bericht vermerkt, dass die betroffene Paketlinie rund zwei Millionen monatliche Installationen zählte – ein Hinweis darauf, wie verbreitet diese Konfiguration bereits im Einsatz war.

Gemini CLI – Googles quelloffener Terminal-KI-Agent, aufgebaut auf der Gemini-API.

Warum Codex für dasselbe Grundproblem keine CVE bekam

OpenAIs Codex (der Coding-Agent openai/codex, nicht ChatGPT) tauchte in derselben Untersuchung auf und teilte dieselbe zugrunde liegende Schwäche – erhielt aber überhaupt keine CVE. Der Grund dafür sagt mehr über die Natur des Problems als über dessen Schwere aus. Es handelte sich nicht um einen klassischen Programmierfehler, sondern um ein Workflow-Designproblem: Eine Automatisierung lief in zwei Durchgängen, die sich eine einzige ausgecheckte Kopie des Repositorys teilten. Ein erster Durchgang ließ sich, wieder über Anweisungen, die in den Text eines externen Beitragenden geschmuggelt wurden, dazu bringen, eine bösartige AGENTS.md-Datei zu schreiben – eine Instruktionsdatei, die eigentlich das Verhalten des Agenten steuern soll. Ein zweiter Durchgang lud diese Datei anschließend und folgte ihr, ohne dass an irgendeiner Stelle der Kette besondere Rechte nötig gewesen wären.

Codex – OpenAIs Coding-Agent für Software-Engineering-Aufgaben, verfügbar über CLI und ChatGPT.

OpenAIs Antwort war, die beiden Durchgänge in unabhängige Jobs mit unabhängigen, nicht geteilten Checkouts zu trennen und Instruktionsdateien wie AGENTS.md offiziell als nicht vertrauenswürdige Eingabefläche zu dokumentieren – etwas, dem der Agent mit derselben Skepsis begegnen sollte wie einem Kommentar von Fremden, nicht wie einer vertrauenswürdigen Konfiguration. Es gab keine neue Versionsnummer und keine CVE, weil es sich nach Einschätzung der Forscher um bereits bestehendes, dokumentiertes Verhalten handelte, das neu als riskant erkannt wurde – nicht um einen ausgelieferten Defekt, der gepatcht werden musste. Der Unterschied wiegt mehr, als er zunächst klingt: Eine CVE nummeriert einen konkreten Bug in einem konkreten Produkt. Was die Black Hat tatsächlich zutage förderte, war ein Designmuster, das in jedem gleich gebauten Werkzeug wieder auftauchen kann, ob es je eine Nummer bekommt oder nicht.

Wie eine verantwortungsvolle Offenlegung hier aussah

Die Cybersecurity and Infrastructure Security Agency (CISA), die US-Behörde, die Sicherheitslücken verfolgt und die Reaktion darauf koordiniert, verzeichnete laut Berichterstattung von The Hacker News zum Stand 7. August 2026 keine Hinweise auf reale Ausnutzung weder der Claude-Code- noch der Gemini-CLI-Schwachstelle. Es waren Forscher, die das Muster zuerst fanden und verantwortungsvoll offenlegten – kein bereits laufender Angriff. Alle drei Hersteller patchten oder entschärften die Probleme innerhalb des üblichen Offenlegungsfensters, und keiner der Fälle setzte einen Fehler seitens der Endnutzer voraus. Das Risiko entstand aus dem ganz gewöhnlichen Standardverhalten, Coding-Agenten an Pipelines anzuschließen, die öffentliche, nicht authentifizierte Eingaben verarbeiten – genau das, was die meisten Teams tun, wenn sie GitHub-Issues automatisch sortieren lassen.

Was das für den Anschluss eines Agenten an deine Pipeline bedeutet

Die konkreten CVE-Nummern, CVSS-Werte und Patch-Versionen in diesem Artikel werden schnell veralten, wie das immer der Fall ist. Was nicht veraltet, ist die Frage, auf die sie hindeuten: Wer einen Coding-Agenten an Automatisierung anschließt, trifft eine Entscheidung über eine Vertrauensgrenze, nicht bloß eine Bequemlichkeitsinstallation. Die Software liest, was ihr die Pipeline vorsetzt, und solange Tool und Workflow nicht ausdrücklich darauf ausgelegt sind, vertrauenswürdige Anweisungen von nicht vertrauenswürdigem Inhalt zu trennen, kann fremder Text sie steuern. Es ist dasselbe Grenzproblem, das hinter dem breiteren Muster der Angriffe auf die Software-Lieferkette steckt, wo die Gefahr selten daher kommt, dass ein System von außen aufgebrochen wird, sondern daher, dass etwas, das ohnehin schon in der Pipeline sitzt, mehr Vertrauen genießt, als ihm zusteht. Die Frage, welches Framework diese Vertrauensgrenze eigentlich regelt und in welcher Reihenfolge, lässt sich separat vertiefen: siehe, wie OWASP, MITRE und NIST die Verantwortung für KI-Sicherheit aufteilen.

Die praktische Konsequenz ist nicht, auf KI-Coding-Agenten in CI zu verzichten. Sie lautet, jeden Inhalt, der von außerhalb der eigenen Organisation erreichbar ist – ein Issue, ein Kommentar, eine Konfigurationsdatei – als Eingabe zu behandeln, die sorgfältig verarbeitet werden muss, nicht als Anweisung, der man gehorcht, und konkret zu prüfen, ob der eigene Workflow diese Trennung tatsächlich durchsetzt, statt sie einfach vorauszusetzen.

Häufig gestellte Fragen

Was ist ein Coding-Agent, einfach erklärt? Ein Coding-Agent ist Software, die eine Anfrage liest, selbst entscheidet, welcher Code oder welche Befehle nötig sind, und das automatisch ausführt – oft innerhalb einer Pipeline, die ohne Aufsicht läuft. Claude Code, Gemini CLI und Codex sind alle so gebaut, und genau deshalb spielt es eine Rolle, wenn nicht vertrauenswürdige Eingaben sie erreichen.

Was ist Prompt Injection, und warum ist das hier wichtig? Prompt Injection bedeutet, dass versteckte oder getarnte Anweisungen innerhalb harmlos wirkender Inhalte, etwa eines GitHub-Issues, von einem KI-System als zu befolgende Befehle behandelt werden statt als zu lesender Text. Das ist wichtig, weil es einem Angreifer ohne jede Kontoberechtigung erlaubt, das Verhalten eines automatisierten Tools zu beeinflussen, indem er einfach die richtigen Worte an der richtigen Stelle platziert.

Muss ich aufhören, Claude Code, Gemini CLI oder Codex in Automatisierung einzusetzen? Nein, keines der drei Tools ist grundlegend kaputter als die anderen; alle drei Hersteller haben die gefundenen Probleme gepatcht oder entschärft, und die CISA fand keine Hinweise auf reale Ausnutzung. Sinnvoll ist es, das eigene Setup zu prüfen, statt die ganze Kategorie zu meiden, denn das zugrunde liegende Muster kann in jedem gleich angebundenen Agenten wieder auftauchen.

Warum bekam Codex keine CVE, obwohl das Problem genauso real war? Eine CVE nummeriert einen konkreten Bug in einer konkreten Produktversion. Das Codex-Problem war ein Workflow-Designfehler – ein gemeinsamer Checkout über zwei Automatisierungsdurchgänge hinweg – und kein Programmierfehler, weshalb OpenAI den Workflow reparierte und das Risiko dokumentierte, statt einen an eine Versionsnummer gebundenen Patch zu veröffentlichen.

Was sollte ich konkret prüfen, wenn ich einen dieser Agenten in CI einsetze? Bestätige, dass du eine gepatchte Version des jeweiligen Produkts nutzt, prüfe, ob Instruktionsdateien und nicht vertrauenswürdige Inhalte in deiner Pipeline von privilegierten Schritten getrennt sind, und vermeide Architekturen, in denen ein einziger Durchgang sowohl öffentliche Eingaben empfängt als auch im selben Lauf mit Rechten handelt.

Das Fazit

Drei Hersteller, drei unterschiedliche technische Ursachen, eine identische Einfallsstelle: ein Coding-Agent innerhalb einer automatisierten Pipeline, der den Text eines Fremden nicht von einem legitimen Befehl unterscheiden konnte. Das ist die Lehre, die bleibt, und sie überdauert jede Patch-Version in diesem Artikel. Wer einen KI-Coding-Agenten in CI betreibt, sollte die Grenze zwischen “Inhalt, den die Software liest” und “Anweisung, der sie gehorcht” als etwas behandeln, das man überprüft, nicht voraussetzt – denn genau diese Grenze, nicht der Bug eines einzelnen Herstellers, war es, durch die ein völlig Fremder gleich dreimal hindurchspazierte.