Angriffe, die bei Tools rund um KI-gestützte Coding Agents starten, müssen nicht unbedingt mit „Social Engineering“ beginnen. Laut einem Bericht von Novee Security reichte in mehreren Fällen schon ein GitHub Issue, das von einem Konto ohne Repository-Berechtigungen erstellt wurde, um auf CI Runner einzuwirken – also auf die Infrastruktur, die im Hintergrund Code ausführt und dabei oft sensible Daten verarbeitet. Im Kern ging es dabei um CI-Workflow-Schwachstellen: Um Code-„Hüllen“ (Harnesses), Validierungslogik und Ablaufdetails zwischen dem Modell und der realen Welt.
Für Gemini CLI und Claude Code wurden Schwachstellen mit eindeutigen Behebungen veröffentlicht. Zusätzlich gab es Erkenntnisse zu einem weiteren Codex-bezogenen Befund, bei dem weniger das konkrete Produkt im Mittelpunkt stand, sondern die Art, wie Workflows die Ausführung strukturieren.
Warum ein GitHub Issue zum Risiko werden kann
Der Ausgangspunkt war jeweils ähnlich: Ein Angreifer konnte über eine von außen erreichbare Stelle die Ausführung in CI-Umgebungen so beeinflussen, dass Code oder Daten abfließen konnten. Entscheidend dabei: In Agent-Setups laufen mehrere Komponenten zusammen – das Modell, Werkzeug-Definitionen, Validierer, Container-Launcher und schließlich das, was wirklich ausgeführt wird.
Wenn eine Komponente eine Annahme „als sicher“ markiert, diese aber in späteren Schritten mit höherer Autorität weiterverwendet wird, kann aus einem scheinbar harmlosen Input ein echter System-Eingriff werden. Genau diese Lücke in der Kette wird im Bericht als wiederkehrendes Muster beschrieben: Eine Stelle sorgt für scheinbare Sicherheit, während eine spätere Stelle dem Wert die echte Durchschlagskraft gibt.
Gemini CLI: OS-Command-Injection über eine manipulierte .env-Datei
Die gravierendste der beiden CVEs betrifft Gemini CLI: CVE-2026-12537 (CVSS 4: 10.0). Dabei handelt es sich um eine OS Command Injection im Container-Launcher. Der Angriff kann über eine speziell präparierte Datei im Pfad .gemini/.env erfolgen.
Das Risiko: Ein unprivilegierter Angreifer kann Code auf dem Host einer Headless-CI-Plattform ausführen, und zwar bevor die eigentliche Sandbox startet. In anderen Worten: Der Ablauf wird so weit „vorverlegt“, dass die Isolation zu spät greift.
Die Behebung ist konkret:
- Gemini CLI 0.39.1 behebt die Schwachstelle.
- run-gemini-cli 0.1.22 ist ebenfalls zu aktualisieren.
Claude Code: API-Key-Leck durch eine Exfiltrations-Umleitung
Bei Claude Code ist die zugehörige Schwachstelle CVE-2026-54316. Hier drehten die Forscher die öffentliche Download-Zählung von Hugging Face in einen möglichen Exfiltrationskanal um.
Im beschriebenen Szenario kann ein API-Schlüssel zeichenweise geleakt werden. Wichtig: Dieses Verhalten betrifft eine Versionsspanne. Der Bericht nennt, dass alle Veröffentlichungen von 0.2.54 bis einschließlich 2.1.163 betroffen sind.
Die Korrektur erfolgt mit:
- Claude Code 2.1.163
Was zur Ausnutzung gesagt wurde
Anthropic weist darauf hin, dass eine erfolgreiche Ausnutzung voraussetzte, untrusted content in einen Claude-Code-Kontext zu bekommen. Der Fokus des Berichts liegt damit nicht nur auf der Existenz der Schwachstelle, sondern auch auf den realen Voraussetzungen, wie sie im praktischen Betrieb überhaupt relevant wird.
Codex-Fund: Keine Produkt-CVE, aber ein Workflow-Problem
Ein weiterer Punkt betrifft „Codex“: Die Findings führen zu keiner direkt benannten Produkt-Version-Absicherung und auch nicht zu einer klassischen CVE. Trotzdem liefern die Beobachtungen konkrete Ansatzpunkte für das Vorgehen der Betreiber.
Laut Novee führte das Repository openai/codex zwei Codex-Passes in demselben Job durch, der eine Checkout-Freigabe besaß. Dadurch konnte ein erster Pass Dateien wie AGENTS.md schreiben, die der zweite Pass anschließend als eigene Instruktionen nutzte. Der Auslöser war, dass die JSON-Validierung zwischen den Passes versagte, wodurch die zweite Ausführungsrunde startete.
OpenAI reagierte dem Bericht zufolge mit Änderungen auf Workflow-Ebene: Die beiden Passes werden getrennt in unterschiedliche Jobs ausgeführt. Zusätzlich wird Codex mit drop-sudo und einem read-only Sandbox-Konzept betrieben. Außerdem zählt OpenAI Repository-Instruktionsdateien als Teil der „untrusted input surface“ und empfiehlt, Codex als letzten Schritt im Job zu laufen – mit dem Hinweis, dass sonst Dateien für spätere, privilegiertere Schritte übrig bleiben könnten.
Kurz gesagt: Hier geht es weniger darum, „Codex selbst ist kaputt“ zu sagen, sondern darum, wie die Ausführung in CI richtig verkabelt wird.
Validierung ist nicht gleich Sicherheit: Der zentrale Harness-Fehler
Ein besonders lehrreicher Teil der Recherche betrifft den „Harness“, also die Softwarestrecke zwischen dem Modell und der realen Ausführung. Der Bericht betont: Genau diese Schicht entscheidet, was am Ende tatsächlich läuft.
Im Claude-Code-Kontext nennen die Forscher einen Validator-Mechanismus, der Single-Quoted Text entfernt, bevor mehrere Prüfpunkte (23 Checks) laufen. Das sei grundsätzlich korrekte Bash-Verarbeitung. Der Knackpunkt: Ein Payload konnte so über einen Konstruktionsteil („git push –receive-pack“ als Parameterfluss) bis zum Runner gelangen, ohne durch die späteren Schritte weiter entschärft zu werden. Für diese konkrete Kette wird im Bericht keine separate CVE genannt, und es wird auch kein öffentlich fixes Versionsziel als Standardbehebung beschrieben.
Für Betreiber bedeutet das: Selbst „richtige“ Validierung in einem Teil kann reichen, wenn später doch eine Stelle mit mehr Autorität agiert, die den Kontext nicht mehr ausreichend absichert.
Was Google bei Gemini CLI zusätzlich adressierte
Im Gemini-CLI-Fall gibt es neben dem Container-Launcher-Problem auch eine Frage der Tool-Autorisierung. Die Recherche beschreibt, dass eine Tool-Allowlist lediglich beim Registrieren der Werkzeuge beachtet wurde. Zur Laufzeit selbst gab es jedoch keine entsprechende Durchsetzung. Unter einem Modus namens –yolo wurden Befehle, die das Modell anfragte, automatisch freigegeben.
Die damit verbundenen Punkte wurden in einer gemeinsamen Empfehlung aufgegriffen. Diese Advisory nennt, dass die Korrektur alle Gemini CLI GitHub Actions betrifft. Interessant ist auch, wie die Identifizierung gehandhabt wurde: Die Advisory selbst weist noch keine CVE aus, während Google die Kennung separat als CNA veröffentlicht hat.
Bewertung der Kritikalität: CVSS-Werte im Blick behalten
Die Schwere wird in unterschiedlichen Standards ausgewiesen. Anthropic ordnet die Claude-Code-Schwachstelle als Moderate ein, mit einem CVSS v4 Wert von 6.0. NVD weist für dieselbe Schwachstelle einen CVSS v3.1 Wert von 9.1 aus. Da NVD für v4 noch keine Bewertung hinterlegt hat, sind die Zahlen nicht 1:1 vergleichbar.
Für die Praxis bleibt jedoch entscheidend: Selbst wenn der CVSS-Wert variiert, geht es um realen Zugriff in CI-Umgebungen – und die enthalten häufig Tokens, Secrets oder andere vertrauliche Informationen.
Aktueller Status: Ausnutzung und „Known Exploited“
In den CISA-Einträgen zu den beiden genannten CVE-Records wird jeweils als Ausnutzungsstatus „none“ angegeben. Zudem bestätigte die Berichterstattung am 7. August, dass weder der Gemini- noch der Claude-Code-Fall im Known Exploited Vulnerabilities-Katalog auftaucht.
Gleichzeitig existiert laut Bericht bereits ein öffentliches GitHub-Repository, das sich als Reproduktionslabor für die Claude-Code-Schwachstelle versteht. Der Start dieses Repos wird auf den 18. Juni datiert. Das bedeutet nicht automatisch, dass es gegen Ziele eingesetzt wurde – der Bericht nennt aber auch keine konkreten Hinweise, dass die beschriebenen Ketten bereits in freier Wildbahn erfolgreich gegen Opfer eingesetzt wurden.
Konkrete Empfehlungen für Teams mit Agent-Workflows
Aus Betreiber-Sicht lassen sich die wichtigsten Schritte klar ableiten. Ein wiederkehrender Appell lautet: prüft die Workflows, die von außen ausgelöst werden können, und nehmt dabei jede Annahme zu Validierung und Sandbox-Startzeit ernst.
Der Bericht nennt explizit:
- Gemini CLI aktualisieren auf 0.39.1.
- run-gemini-cli aktualisieren auf 0.1.22.
- Claude Code aktualisieren auf 2.1.163.
Außerdem empfiehlt sich ein Audit von Workflows: Sobald ein externer Nutzer eine Aktion auslösen kann, sollte das Setup so gestaltet sein, dass untrusted input nicht in privilegierte Verarbeitungsschritte „durchrutscht“. Besonders relevant ist dabei der Ablauf: Wenn gefährliche Artefakte vor der Sandbox-Absicherung landen oder wenn zwischen Passes Dateien unbeabsichtigt weitergereicht werden, steigt das Risiko.
Fazit: CI-Workflow-Schwachstellen schließen Lücken in der Ausführungskette
Die Recherche zu CI-Workflow-Schwachstellen zeigt ein deutliches Muster: Nicht nur das „Modell“, sondern der gesamte Ausführungsweg entscheidet, ob ein System sicher bleibt. Bei Gemini CLI waren Container-Launcher und fehlende Durchsetzung zur Laufzeit zentrale Themen. Bei Claude Code stand ein möglicher Exfiltrationsweg über externe Zähler im Vordergrund, verbunden mit Validierungsdetails, die im Harness-Kontext zu einer unerwünschten Wirkung führen konnten.
Wer Agent-Workflows nutzt, sollte jetzt handeln: Versionen aktualisieren, Workflows mit extern getriggerten Eingaben überprüfen und insbesondere auf die Reihenfolge achten, in der Sandboxen starten und Artefakte zwischen Job-Schritten geteilt werden. So reduzieren Sie das Risiko, dass ein scheinbar harmloser Input den Weg zu sensiblen CI-Daten findet.
Quelle: https://thehackernews.com/2026/08/claude-code-and-gemini-cli-flaws-let.html
