Coding Agents als Angriffsfläche: Wenn der PR-Titel den Agenten kapert

100 Dollar. So viel zahlte Anthropic im November 2025 für die Meldung einer Schwachstelle, die das Unternehmen zu diesem Zeitpunkt selbst mit CVSS 9,4 eingestuft hatte. Die Lücke steckte in Claude Code Security Review, einer GitHub Action, die Pull Requests automatisch auf Sicherheitsprobleme prüft. Ein präparierter PR-Titel genügte, damit der Agent Shell-Befehle ausführte und den ANTHROPIC_API_KEY samt GITHUB_TOKEN in einen PR-Kommentar schrieb. So steht es in der Veröffentlichung des Sicherheitsforschers Aonan Guan vom 15. April 2026, über die SecurityWeek am 16. April berichtete.

Ein Werkzeug, das Sicherheitslücken finden soll, wird über die Überschrift des zu prüfenden Pull Requests übernommen. Ich finde, das beschreibt den Stand der Dinge bei Coding-Agenten in der Pipeline recht gut.

Drei Agenten, drei Hersteller, ein Muster

Guan hat die Arbeit zusammen mit Zhengyu Liu und Gavin Zhong von der Johns Hopkins University veröffentlicht und "Comment and Control" genannt. Betroffen waren drei Produkte von drei Herstellern. Der Weg hinein war jedes Mal Text, den ein beliebiger GitHub-Nutzer schreiben darf.

Quelle für alle Zeilen: Guan, 15.04.2026.

Der Copilot-Fall ist der lehrreichste, weil GitHub dort bereits drei Schutzschichten eingebaut hatte. Die Umgebungsvariablen des Agenten waren gefiltert, also las der eingeschleuste Befehl per ps auxeww die Umgebung der Elternprozesse aus, in der die Tokens noch standen. Das Secret Scanning sucht nach bekannten Präfixen wie ghs_, also wurde die Ausgabe vorher Base64-kodiert. Die Netzwerk-Firewall lässt nur freigegebene Ziele zu, also ging die Beute per git push an github.com, das naturgemäß freigegeben ist. Der Mitarbeiter, der das Issue dem Agenten zuwies, sah von alldem nichts, denn HTML-Kommentare rendert GitHub nicht.

Wie Prompt Injection grundsätzlich funktioniert und warum sich das Problem nicht wegpatchen lässt, habe ich in Prompt Injection: Das Risiko, das nicht gepatcht werden kann beschrieben. Das wiederhole ich hier nicht. Mich interessiert, was passiert, wenn das Opfer der Injection ein Prozess mit Shell, Schreibrechten und Zugangsdaten ist.

Wie die Hersteller reagiert haben

Die Reaktionen sagen mehr über die Lage als die Exploits selbst. Laut Guans Zeitleiste hat Anthropic den Fund am 25. November 2025 als kritisch bewertet und als Gegenmaßnahme das Werkzeug ps gesperrt. Guan merkt trocken an, dass cat /proc/*/environ dasselbe leistet, und nennt Sperrlisten "whack-a-mole".

Google zahlte 1.337 Dollar und ergänzte nach Darstellung von SecurityWeek den System-Prompt um neue Guardrail-Anweisungen. GitHub schloss die Meldung zunächst als "Informative", öffnete sie nach Widerspruch der Forscher wieder, zahlte 500 Dollar und sprach von einer bereits bekannten Architekturgrenze, an deren Einschränkung man arbeite.

Ein gesperrter Befehl, ein paar zusätzliche Sätze im System-Prompt, eine bekannte Architekturgrenze. Keine der drei Antworten ändert etwas daran, dass der Agent fremden Text liest und gleichzeitig Werkzeuge und Zugangsdaten in der Hand hat. Ich lese daraus: Das Modell wird eingeschleusten Text weiterhin gelegentlich für eine Anweisung halten, und die Absicherung liegt beim Betreiber der Pipeline. Wer einen solchen Agenten in seine Workflows einbaut, übernimmt diese Verantwortung, ob er das Kleingedruckte gelesen hat oder nicht.

Der Agent ist ein privilegierter Workload

Ein Review-Agent in der Pipeline liest Pull Requests, Issues und Kommentare. Das ist seine Aufgabe, und all das ist Eingabe von Fremden. Gleichzeitig läuft er in einem Job, der ein GITHUB_TOKEN besitzt, häufig einen API-Schlüssel für das Modell und nicht selten weitere Secrets, weil der Workflow aus einer bestehenden Vorlage kopiert wurde. Dazu kommen Werkzeuge wie Bash, Dateizugriff und Netzwerk.

In klassischer Pipeline-Sicherheit gibt es dafür eine etablierte Regel. GitHub gibt bei Workflows, die durch Pull Requests aus Forks ausgelöst werden, außer dem GITHUB_TOKEN keine Secrets an den Runner weiter, und das Token ist dort nur lesend. Für pull_request_target, das im Kontext des Basis-Repositories läuft, warnt dieselbe Dokumentation ausdrücklich vor Cache Poisoning und ungewolltem Zugriff auf Schreibrechte und Secrets, sobald dort nicht vertrauenswürdiger Code ausgeführt wird.

Diese Regel schützt vor fremdem Code. Bei einem Agenten ist der fremde Text der Code. Ein Issue-Titel wird durch die Interpretation des Modells zu einem Shell-Befehl, und Workflows, die auf issues oder issue_comment reagieren, laufen ohnehin mit den Rechten des eigenen Repositories. In Projekten sehe ich oft, dass Teams die Fork-Regel für Build-Jobs sauber umgesetzt haben und den Agenten-Workflow daneben als harmlosen Helfer betrachten, weil er ja "nur kommentiert".

Vom Issue-Titel zum npm-Paket

Dass daraus mehr wird als ein Forschungsbefund, zeigen zwei Fälle aus den Monaten davor.

Am 4. Dezember 2025 veröffentlichte Aikido Security unter dem Namen PromptPwnd dasselbe Muster für Gemini CLI, Claude Code Actions, OpenAI Codex Actions und GitHub AI Inference. Nach Angaben von Aikido waren mindestens fünf Fortune-500-Unternehmen betroffen. Im Repository von Gemini CLI selbst brachte ein präpariertes Issue den Agenten dazu, per gh issue edit den GEMINI_API_KEY, das GITHUB_TOKEN und ein Google-Cloud-Zugriffstoken in den Issue-Text zu schreiben. Google hat das laut Aikido innerhalb von vier Tagen behoben.

Der zweite Fall ging bis in die Lieferkette. Der Sicherheitsforscher Adnan Khan beschrieb am 9. Februar 2026 unter dem Titel Clinejection, wie sich die Releases des Coding-Assistenten Cline kompromittieren ließen. Cline hatte am 21. Dezember 2025 einen Workflow zur automatischen Issue-Triage eingeführt. Er nutzte claude-code-action mit Bash, Write, Edit und Webzugriff, und die Einstellung allowed_non_write_users: "*" erlaubte jedem GitHub-Konto, ihn auszulösen. Ein Issue-Titel brachte den Agenten dazu, ein npm install aus einem Fork des Angreifers auszuführen. Über ein Preinstall-Skript und Cache Poisoning gelangte der Angreifer an den Cache des nächtlichen Release-Workflows und damit an NPM_RELEASE_TOKEN, VSCE_PAT und OVSX_PAT.

Khan hatte das am 1. Januar gemeldet und mehrfach nachgefasst. Behoben wurde es am 9. Februar, etwa eine halbe Stunde nach der öffentlichen Beschreibung. Am 17. Februar um 3:26 Uhr Pazifikzeit erschien trotzdem ein nicht autorisiertes [email protected] auf npm, das per Postinstall-Skript global openclaw installierte. Laut Post-mortem von Cline war die Version rund acht Stunden verfügbar, das eigentliche CLI-Binary war unverändert. Cline hat danach die KI-gestützten Triage-Workflows vollständig entfernt, den Actions-Cache aus Workflows mit Zugangsdaten verbannt und das npm-Publishing auf OIDC umgestellt.

Der Schaden blieb überschaubar, weil der Angreifer offenbar nur zeigen wollte, dass es geht. Darauf würde ich mich beim nächsten Mal nicht verlassen.

Schutzmaßnahmen, die tatsächlich tragen

Filter im Prompt und Sperrlisten für einzelne Befehle haben in allen beschriebenen Fällen versagt. Was hilft, ist langweilige Berechtigungsarbeit. Die Forscher empfehlen, Agenten wie neue Mitarbeiter zu behandeln und ihnen per Allowlist nur die Werkzeuge zu geben, die die Aufgabe braucht. Snyk formuliert es in seiner Analyse des Cline-Falls noch direkter: Ein Agent für Issue-Triage braucht weder Bash noch Write noch Edit.

Für den Agentenlauf selbst reicht oft schon ein sehr schlichter Kopf im Workflow:

on: pull_request          # nicht pull_request_target
permissions:
  contents: read          # der Agent liest, mehr nicht

Zwei Grenzen gehören dazu. Egress-Kontrolle ist sinnvoll, aber der Copilot-Fall zeigt, dass ein Agent mit Schreibrecht im Repository gar keinen fremden Server braucht, um Daten hinauszutragen. Und die menschliche Freigabe hilft nur, wenn der Mensch sieht, was der Agent gesehen hat. Ein Issue mit unsichtbarem HTML-Kommentar sieht in der Oberfläche völlig harmlos aus. Ich würde deshalb Secrets und Rechte zuerst angehen und alles andere als zweite Schicht betrachten.

Organisatorisch gehört das Token des Agenten in Ihr Inventar für Non-Human Identities, mit Owner, Rechten und Rotation wie jeder andere Service Account. Und der Agenten-Workflow gehört in die Bedrohungsmodellierung Ihres SSDLC, so wie jeder andere Job mit Zugriff auf Release-Artefakte.

Was CISO und CTO entscheiden müssen

Technisch ist das meiste davon in Tagen erledigt. Offen bleiben Entscheidungen, die ein Entwicklungsteam nicht allein treffen kann und die deshalb gern liegen bleiben.

1. Wer darf Agenten in Pipelines einbauen? Heute genügt dafür ein Entwickler mit Schreibrecht auf .github/workflows und eine halbe Stunde Zeit. Ich würde Agenten-Workflows wie neue Service Accounts behandeln: meldepflichtig, mit Owner, mit Review durch Security. Aufwand: eine Regelung auf einer Seite und ein CODEOWNERS-Eintrag für das Workflow-Verzeichnis.
2. Dürfen Agenten auf Eingaben von außen reagieren? Für öffentliche Repositories würde ich das nur ohne Secrets und ohne Schreibrechte zulassen. Für interne Repositories ist das Risiko kleiner, aber vorhanden, denn ein kompromittiertes Entwicklerkonto oder ein übernommener Dependency-Bot schreibt ebenfalls PR-Texte.
3. Wo liegt die Grenze zwischen Review und Release? Legen Sie fest, dass kein Workflow mit Agent Zugriff auf Publishing-Tokens, Deploy-Schlüssel oder einen gemeinsam genutzten Cache hat. Das ist eine Architekturvorgabe und braucht Ihre Rückendeckung, weil sie Bequemlichkeit kostet.
4. Wer prüft die Hersteller? Fragen Sie Ihre Anbieter schriftlich, wie ihre Agenten-Actions mit nicht vertrauenswürdigem Input umgehen. GitHub spricht bei Copilot von einer bekannten Architekturgrenze. Das ist eine legitime Position, und sie gehört in Ihre Risikobewertung.

Eine Grenze meiner eigenen Einschätzung: Wie viele Unternehmen in DACH solche Workflows produktiv betreiben, weiß ich nicht, und belastbare Zahlen dazu habe ich nicht gefunden. Aus Gesprächen habe ich den Eindruck, dass es mehr sind, als die jeweilige Security-Abteilung annimmt.

Ein Schritt für diese Woche

Lassen Sie in Ihrer GitHub-Organisation alle Workflow-Dateien nach Agenten-Actions durchsuchen, also nach claude-code-action, claude-code-security-review, run-gemini-cli, Codex-Actions und zugewiesenen Copilot-Agenten. Notieren Sie pro Treffer drei Dinge: welcher Auslöser, welche Secrets, welche permissions. Das ist ein Nachmittag Arbeit für eine Person mit Organisationsrechten. Jeder Treffer, bei dem ein Fremder den Lauf auslösen kann und ein Secret im Job liegt, wird noch in derselben Woche abgeschaltet oder entschärft.

Nachtrag (September 2026)

Zuerst eine Ergänzung zum Aufhänger. Guan hat seinen Beitrag am 4. Mai 2026 aktualisiert: Anthropic habe die Einstufung des Funds am 20. April von "Critical" auf "None" geändert. Er zitiert den Hersteller mit dem Satz "The action is not designed to be hardened against prompt injection." Das passt zur Linie dieses Artikels. Die Härtung ist Sache des Betreibers.

Am 1. September 2026 hat Manifold Security unter dem Namen GitSpawn acht Funde in sieben Coding-Agenten veröffentlicht, nämlich Claude Code, Codex, Cursor, goose, Hermes, Qwen Code und Grok Build. Vier davon waren zum Zeitpunkt der Veröffentlichung nicht behoben. Der Hebel ist die Git-Einstellung core.fsmonitor in der .git/config eines Repositories. Ihr Wert ist ein Befehl, den Git bei git status oder git diff ausführt. Coding-Agenten rufen genau diese Befehle beim Öffnen eines Ordners im Hintergrund auf, laut The Hacker News vom 2. September außerhalb der Sandbox und bei Claude Code und Hermes noch bevor der Vertrauensdialog bestätigt ist.

Zur Einordnung der CVE-Nummern, weil das in der Berichterstattung durcheinandergeht: CVE-2026-72718 betrifft goose, CVE-2026-71963 Hermes. CVE-2026-55607 ist nach Darstellung von The Hacker News ein früheres Advisory von Anthropic aus dem Juni zu fsmonitor-Ausführung bei Worktree-Operationen. Für die beiden GitSpawn-Funde in Claude Code hat Anthropic demnach kein eigenes Advisory veröffentlicht. Der core.fsmonitor-Pfad wurde am 26. Juni gemeldet und ist seit Version 2.1.196 behoben, ein zweiter Pfad über claude ultrareview war laut Manifold am 1. September in Version 2.1.252 noch offen.

Für Pipelines ist die Lage hier ausnahmsweise entspannter. Git überträgt .git/config weder bei clone noch bei fetch oder pull. Das präparierte Repository muss als Dateien ankommen, etwa als ZIP, über ein Netzlaufwerk, einen Sync-Ordner oder einen USB-Stick. Betroffen ist also vor allem der Entwickler, der ein zugeschicktes Projektarchiv "kurz mal vom Agenten anschauen lässt". Manifold empfiehlt git config --global core.fsmonitor false und einen Blick in .git/config, bevor ein Agent einen erhaltenen Ordner öffnet. Am Befund dieses Artikels ändert GitSpawn nichts, es fügt einen Eingabekanal hinzu: Auch die Konfiguration eines Repositories ist Input von Fremden.

Weiterführend

• Prompt Injection: Das Risiko, das nicht gepatcht werden kann
• Non-Human Identity Management für AI-Systeme
• Secure Software Development Lifecycle (SSDLC)

Quellen

• Aonan Guan, Zhengyu Liu, Gavin Zhong: "Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent", 15.04.2026, aktualisiert 04.05.2026, https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/
• SecurityWeek (Eduard Kovacs): "Claude Code, Gemini CLI, GitHub Copilot Agents Vulnerable to Prompt Injection via Comments", 16.04.2026, aktualisiert 21.04.2026, https://www.securityweek.com/claude-code-gemini-cli-github-copilot-agents-vulnerable-to-prompt-injection-via-comments/
• Aikido Security (Rein Daelman): "PromptPwnd: Prompt Injection Vulnerabilities in GitHub Actions Using AI Agents", 04.12.2025, https://www.aikido.dev/blog/promptpwnd-github-actions-ai-agents
• Adnan Khan: "Clinejection. Compromising Cline's Production Releases just by Prompting an Issue Triager", 09.02.2026, https://adnanthekhan.com/posts/clinejection/
• Cline: "Post-mortem: Unauthorized Cline CLI npm publish", 24.02.2026, https://cline.bot/blog/post-mortem-unauthorized-cline-cli-npm
• Snyk (Stephen Thoemmes): "How Clinejection Turned an AI Bot into a Supply Chain Attack", 19.02.2026, https://snyk.io/blog/cline-supply-chain-attack-prompt-injection-github-actions/
• GitHub Docs: "Events that trigger workflows", Abschnitte zu pull_request aus Forks und pull_request_target, fortlaufend aktualisierte Referenz ohne Datum, https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
• Nachtrag: Manifold Security: "GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok", 01.09.2026, https://www.manifold.security/blog/ai-coding-agents-git-hijack
• Nachtrag: The Hacker News (Swati Khandelwal): "Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code", 02.09.2026, https://thehackernews.com/2026/09/malicious-git-configs-can-make-claude.html