KI-gestützte GitHub Actions können mit einem einzigen Kommentar gekapert werden, wodurch API-Keys, Cloud-Token und andere Secrets geleakt werden. Ein Sicherheitsforscher hat 22 Open-Source-Repositories aufgedeckt, bei denen ein öffentlicher Trigger, ein KI-Tool, das mit einem „skip prompts“-Flag ausgeführt wird, und offengelegte Secrets einen direkten Pfad zur Datenexfiltration schaffen.

So funktioniert die Schwachstelle

Projekte betten mittlerweile KI-Agenten – Claude Code, das GitHub Copilot CLI und ähnliche Tools – direkt in CI-Pipelines ein. Ein Workflow-Schritt führt einen Shell-Befehl aus und fügt oft ein Flag hinzu, das dem Tool sagt, interaktive Berechtigungsanfragen zu ignorieren. Wenn der Workflow durch eine öffentliche Eingabe gestartet wird – ein Issue, ein Kommentar oder ein Pull-Request-Titel –, muss der Angreifer nur eine Textzeile posten, die die KI als Befehl behandelt.

Die KI, der durch das „skip prompts“-Flag bereits uneingeschränkter Shell-Zugriff gewährt wurde, liest jede Umgebungsvariable oder Datei aus, die der Workflow offenlegt. Wenn der Job zusätzlich Secrets lädt – API-Keys, Cloud-Service-Token oder vollständige Service-Account-Anmeldedaten –, leitet die KI diese Werte an einen vom Angreifer kontrollierten Server weiter. Keine Code-Änderung, keine neue Abhängigkeit, nur ein harmlos aussehender Kommentar.

Praxisbeispiele

Der Forscher bestätigte drei verwundbare Repositories, die bereits gepatcht wurden:

  • pymc-labs/pymc-marketing – ein öffentliches Issue konnte genutzt werden, um durch Prompt Injection an einen Anthropic API-Key zu gelangen.
  • MadAppGang/dingo – der Workflow gab Claude Code vollen Bash-Zugriff und legte zwei Secrets im selben Job offen.
  • MadAppGang/claudish – verwendete dieselbe verwundbare Vorlage wie das dingo-Projekt.

Ein Befund betraf einen aktiven Cloud-Service-Account-Key, den der Forscher direkt an das Sicherheitsteam eines großen KI-Anbieters meldete. Zwölf weitere Berichte liegen den Maintainern vor; ihre Namen werden zurückgehalten, bis die Fixes live gehen.

Was auf dem Spiel steht

Wenn ein Angreifer ein Secret extrahiert, kann der Schaden unmittelbar und kostspielig sein. Ein Cloud-Service-Account-Key gewährt uneingeschränkten Zugriff auf Rechenressourcen, Storage Buckets und andere kostenpflichtige Dienste. Ein API-Key eines Large-Language-Model-Anbieters kann unbegrenzte Abfragen durchführen und potenziell Kosten in Höhe von Tausenden von Dollar verursachen. Da der Exploit innerhalb der CI-Umgebung ausgeführt wird, kann sich die Sicherheitsverletzung nachgelagert ausbreiten: Jedes Artefakt, das auf dem kompromittierten Runner erstellt wird, kann bösartigen Code enthalten, wodurch ein einzelnes Repository zu einem Supply-Chain-Vektor wird.

Für Teams, die auf KI-gestützte CI angewiesen sind, ist der Kompromiss drastisch. Der Komfort von automatisch generiertem Code, Linting oder Dokumentation muss gegen das Risiko abgewogen werden, dass ein öffentlicher Kommentar zu einem verdeckten Backdoor wird.

Warum die Schwachstelle leicht zu übersehen ist

Der Forscher reichte zunächst sechs Berichte ein, die später zurückgezogen wurden. Die Rückzüge resultierten aus Annahmen über die Berechtigungsprüfungen von GitHub Actions, nicht aus einer Zeile-für-Zeile-Überprüfung des Quellcodes der Action. Dokumentation und Intuition können irreführend sein; der einzige zuverlässige Weg, die Sicherheitslage eines KI-gestützten Schritts zu bestätigen, besteht darin, den Code zu inspizieren, der das Tool ausführt, sowie das Workflow-YAML, das alles miteinander verbindet.

Checkliste zur Risikominderung

Wenn Sie ein KI-CLI oder ein ähnliches Tool innerhalb eines GitHub Actions Workflows ausführen, beantworten Sie diese zwei Fragen vor dem Mergen:

  1. Wer kann den Workflow auslösen? Beschränken Sie Trigger auf vertrauenswürdige Ereignisse (z. B. Pushes auf geschützte Branches) oder erfordern Sie eine explizite Genehmigung für Durchläufe, die von externen Mitwirkenden gestartet werden. Vermeiden Sie on: issue_comment oder on: issues ohne zusätzliche Kontrollmechanismen.

  2. Welche Secrets werden im selben Job geladen? Legen Sie niemals API-Keys, Cloud-Token oder Service-Account-Anmeldedaten in einem Job offen, der auch einen KI-Agenten mit uneingeschränktem Shell-Zugriff ausführt. Trennen Sie schlüsselintensive Schritte in isolierte Jobs oder Runner, die keine KI-Tools aufrufen.

Zusätzliche Härtungsschritte:

  • Entfernen Sie das Flag, das Berechtigungsabfragen überspringt, um das KI-Tool zu zwingen, vor der Ausführung von Shell-Befehlen eine explizite Bestätigung anzufordern.
  • Fügen Sie einen Schritt hinzu, der alle Umgebungsvariablen, die das KI-Tool lesen könnte, bereinigt oder unkenntlich macht.
  • Verwenden Sie Self-hosted Runner mit Netzwerk-Egress-Kontrollen, um die Exfiltration an beliebige Endpunkte zu blockieren.

Gegenargument: Der Nutzen von KI in der CI

Befürworter argumentieren, dass die Produktivitätsgewinne das Risiko überwiegen. Automatisierte Code-Vorschläge verkürzen die Review-Zeit, und KI-gestütztes Testen deckt Bugs früher auf. Doch derselbe Komfort vergrößert die Angriffsfläche. Der Schlüssel liegt nicht darin, die KI aufzugeben, sondern jedes Tool mit Privilegien auf Shell-Ebene als potenziellen Vektor zu behandeln.

Worauf man als Nächstes achten sollte

Die Ergebnisse haben bereits Diskussionen in den Sicherheitsforen von GitHub über strengere Standardberechtigungen für KI-gestützte Actions ausgelöst. Zukünftige Plattform-Updates könnten Folgendes beinhalten:

  • Ein Flag, das KI-Tools dazu zwingt, in einer Sandbox-Umgebung ohne direkten Shell-Zugriff zu laufen.
  • Integrierte Erkennung von Prompt-Injection-Mustern in Issue-Beschreibungen oder Kommentaren.
  • Automatisierte Warnmeldungen, wenn ein Workflow öffentliche Trigger mit Jobs kombiniert, die Secrets enthalten.

Vorerst liegt die Verantwortung bei den Repository-Maintainern. Die 22 identifizierten Repositories zeigen, dass das Problem kein Einzelfall ist; jedes Projekt, das dasselbe Workflow-Muster aufweist, ist anfällig. Ein kurzer Audit der CI-Konfigurationen kann das Problem aufdecken, bevor es ein Angreifer tut.

Fazit: Eine einzige Textzeile in einem öffentlichen GitHub-Issue kann einem KI-Agenten die volle Kontrolle über Ihre CI-Umgebung geben und die dort gespeicherten Secrets stehlen. Überprüfen Sie, wer Ihre Workflows auslösen kann, halten Sie Secrets von KI-gesteuerten Schritten fern und prüfen Sie jedes Flag genau, das ungeprüfte Berechtigungen gewährt. Die Kosten einer Sicherheitsverletzung übersteigen den Aufwand einer disziplinierten Überprüfung bei weitem.