Ein Kommentar auf einem Pull Request, ein Branch-Name oder ein Fork – alles, was in klassischen GitHub-Workflows als Eingabedaten galt, kann in schlecht konfigurierten CI/CD-Pipelines zur Eskalationsstufe werden. Novee Security hat eine neue Klasse von Schwachstellen in GitHub-Actions-Workflows identifiziert, die unter dem Namen „Cordyceps" zusammengefasst wird. Der Name leitet sich vom parasitären Pilz ab, der seine Wirte übernimmt. Das technische Muster ist ähnlich: Ein externer, nicht authentifizierter Nutzer nutzt die Privilegien eines Repository-Maintainers, ohne jemals Zugriff auf das Konto selbst zu benötigen. Betroffen sind über 300 Repositories bei Organisationen wie Microsoft, Google, Apache, Cloudflare und der Python Software Foundation.
Das Praxisproblem: Vertrauensgrenzen in CI/CD-Workflows
Die grundlegende Schwachstelle ist nicht neu als Konzept, aber ihre systematische Verbreitung ist alarmierend. GitHub Actions sind YAML-Dateien, die Workflows definieren: Sie können Shell-Befehle ausführen, Cloud-Provider authentifizieren, Signing-Schlüssel verwenden und Releases veröffentlichen. Viele Projekte nutzen Trigger wie pull_request_target oder issue_comment, um automatisch auf externe Eingaben zu reagieren. Das Problem: Diese Trigger können Workflows mit den vollen Berechtigungen des Repository-Maintainers ausführen, nicht mit den stark eingeschränkten Rechten des Pull-Request-Autors.
Wenn nun ein Workflow Eingaben aus einem Pull Request oder Kommentar – also Daten, die von jedem beliebigen GitHub-Nutzer mit einem kostenlosen Account stammen können – an Orte weitergibt, die Befehle ausführen, entsteht eine Trust-Boundary-Verletzung. Ein einzelner Kommentar kann dann Code auf dem CI-Runner des Projekts ausführen, CI-Secrets exfiltrieren oder sogar einen nicht ablaufenden GitHub-App-Schlüssel stehlen. The Hacker News zitiert Elad Meged von Novee Security: „No org membership or special privileges; a free account is enough to forge approvals, push code, or steal credentials."
Technische Details der Angriffsketten
Novee Security hat rund 30.000 Repositories über die npm-, PyPI-, crates- und Go-Ökosysteme gescannt, 654 als verdächtig markiert und mehr als 300 als vollständig ausnutzbar bestätigt – mit Angriffsketten von Code-Ausführung bis zum Diebstahl dauerhafter Zugangsdaten. Die Forscher setzten KI-Agenten ein, um mehrstufige Exploit-Ketten über mehrere Workflows hinweg zu identifizieren – Ketten, die deterministische Scanner nicht erkennen, weil jede Workflow-Datei für sich als gültiges YAML gilt.
Konkrete Beispiele aus der Forschung:
Microsoft Azure Sentinel: Ein Kommentar auf einem Pull Request konnte anonymen Angreifercode auf Microsofts CI ausführen und einen nicht ablaufenden GitHub-App-Schlüssel stehlen. Persistenter Schreibzugriff auf Security-Inhalte, die Microsoft an Kunden ausliefert, wäre die Folge gewesen. Microsoft bestätigte den Befund über MSRC.
Google AI Agent Development Kit (adk-samples): Ein einzelner Pull Request konnte Angreifercode in Googles CI ausführen und authentifizierte Kontrolle über das verknüpfte Google Cloud Project erlangen – mit der höchstmöglichen Rolle roles/owner. Ein PR hätte also zu permanentem Cloud-Zugriff geführt. Google bestätigte Issue und Impact.
Apache Doris: Zwei unabhängige Zero-Click-Angriffe – ein Kommentar auf einem beliebigen PR führt Angreifercode aus und exfiltriert CI-Credentials; ein Fork-PR stiehlt ein Token mit vollen Schreibrechten. Apache Security Team bestätigte und behebte die Schwachstelle.
Cloudflare Workers SDK: Ein Pull Request mit einem manipulierten Branch-Namen führte beliebige Befehle auf Cloudflares CI-Runnern aus. Cloudflare sprach Novee Credit zu und wandte breite Härtungsmaßnahmen an.
Python Software Foundation / Black: Ein einzelner Pull Request von jedem beliebigen Nutzer konnte Angreifercode auf den Build-Systemen des Python-Codeformatters ausführen und das Automatisierungs-Token stehlen – damit hätte ein Angreifer Pull Requests als Bot genehmigen und den Weg zur Haupt-Branch öffnen können.
Warum klassische Scanner diese Schwachstellen nicht finden
Novee erklärt den Kern präzise: „The vulnerability exists only in the composition – untrusted data crossing a trust boundary that no one audited." Jede einzelne Workflow-Datei ist gültiges YAML und tut, was sie soll. Die Schwachstelle existiert nur in der Kombination: Eingangsdaten aus einem nicht vertrauenswürdigen Kanal erreichen einen privilegierten Ausführungskontext, ohne dass jemand diese Vertrauensgrenze explizit geprüft hat.
SAST- und DAST-Tools, die Einzeldateien analysieren, können diese Cross-Workflow-Muster nicht erkennen. Ein deterministischer Scanner sieht gültiges YAML; ein Angreifer sieht eine vierstufige Kette zu permanenten Credentials. Diese Ketten zu finden, erfordert Angreifer-Reasoning über mehrere Workflows und Privilegiengrenzen hinweg – eine Aufgabe, die zunehmend auf agentische Ansätze setzt.
Branchenkontext: Agentic Coding verschärft das Problem
Die Relevanz geht über den aktuellen Vorfall hinaus. Novee weist explizit darauf hin: „The nature of agentic coding means these CI/CD vulnerabilities are reproduced persistently, at scale, 'infecting' repositories at an exponential rate." KI-gestützte Coding-Tools, Template-Repositories und automatisierte CI-Orchestrierung reproduzieren Workflow-Konfigurationen in hohem Tempo. Eine unsichere Konfiguration in einem populären Template kann hunderte Nachahmer-Repositories infizieren.
Zur Einordnung passt eine zeitgleiche Meldung: GitHub hat am 18. Juni die actions/checkout-Action aktualisiert, um häufige „Pwn Request"-Angriffsmuster zu blockieren – also genau die Fälle, bei denen der pull_request_target-Trigger Code aus einem PR mit vollen Workflow-Berechtigungen ausführt. Beide Meldungen zusammen zeigen: CI/CD-Sicherheitslücken in GitHub-Workflows sind keine Einzelfälle, sondern eine strukturelle Schwachstelle.
Konkrete Implikationen für Unternehmen
Für Unternehmen ergeben sich mehrere Handlungsfelder. Erstens: Eigene Repositories prüfen. Jede Organisation, die GitHub Actions nutzt, sollte ihre Workflows auf Trigger wie pull_request_target, issue_comment und workflow_run untersuchen. Entscheidend ist, ob Eingaben aus Pull Requests oder Kommentaren – also potenziell nicht vertrauenswürdige Daten – Befehlsausführung oder Secret-Zugriff ermöglichen.
Zweitens: Minimalrechte für Workflow-Token. Der GITHUB_TOKEN sollte nur die Rechte haben, die für den spezifischen Schritt notwendig sind. permissions: read-all als Default ist gefährlich. Persistente GitHub-App-Schlüssel oder Cloud-Credentials gehören nicht in Workflows, die durch externe Eingaben triggerbar sind.
Drittens: pull_request_target vermeiden oder isolieren. Dieser Trigger ist das häufigste Einfallstor. Wenn er unverzichtbar ist, sollte der Workflow strikt zwischen Lese- und Ausführungsphase trennen. Die aktualisierte actions/checkout-Version blockiert inzwischen gängige Pwn-Request-Muster, ersetzt aber keine manuelle Workflow-Auditierung.
Viertens: Abhängigkeiten scannen. Unternehmen konsumieren hunderte Open-Source-Pakete, deren CI/CD-Pipelines potenziell kompromittierbar waren. Ein kompromittiertes Build-System bei Apache, Google oder der Python Software Foundation kann Artefakte erzeugen, die in nachgelagerten Unternehmenssystemen landen. Provenance-Verifikation und SBOM-Pflege werden wichtiger.
Fünftens: CI/CD als Teil der Angriffsfläche verstehen. Workflows sind Code. Ein Bug in Workflow-YAML ist eine Schwachstelle. Die gleiche Sorgfalt, die auf Anwendungscode angewendet wird – Code-Review, statische Analyse, Penetration Testing – muss auf CI/CD-Konfigurationen ausgeweitet werden.
Risiken und Limitierungen
Wichtig ist die nüchterne Einordnung. Novee Security ist ein kommerzielles Pen-Testing-Unternehmen, das eigene agentische Sicherheitsprodukte vertreibt. Die Forschung diente auch dem Nachweis der Leistungsfähigkeit des eigenen Produkts. Die genannte Zahl von über 300 ausnutzbaren Repositories basiert auf der Eigenmessung der Forscher. Betroffene Organisationen wurden vor der Veröffentlichung informiert; Microsoft, Google, Apache, Cloudflare und die Python Software Foundation haben laut Novee die Meldungen bestätigt oder bereits Patches angewendet. Es gibt keinen Hinweis auf aktive Ausnutzung im Feld vor der Offenlegung.
Ebenso wichtig: Die Schwachstelle liegt nicht in GitHub selbst. Novee stellt klar: „This flaw does not live in GitHub; any workflow management system is susceptible." GitHub ist lediglich der wahrscheinlichste Angriffsvektor wegen seiner Kombination aus Verbreitung und Offenheit.
Fazit
Cordyceps ist ein Weckruf für eine Schwachstellenklasse, die in vielen Security-Programmen noch nicht erfasst wird. CI/CD-Workflows werden typischerweise als Infrastruktur-Konfiguration behandelt, nicht als Code mit Angriffsfläche. Die Forschung zeigt, dass genau diese Workflows zu den einfallstorreichsten und am schwersten zu erkennenden Lieferketten-Risiken gehören. Ein nicht authentifizierter Nutzer mit einem kostenlosen GitHub-Account kann über einen Pull Request oder Kommentar die Build-Pipeline übernehmen und dauerhaften Zugriff auf Cloud-Ressourcen, Signing-Keys oder Release-Kanäle erlangen. Für Unternehmen bedeutet das: CI/CD-Workflows gehören ins Inventar der kritischen Angriffsfläche, müssen auf Trust-Boundaries geprüft werden und verdienen denselben Review-Prozess wie Anwendungscode.
Quellen: Novee Security, „Cordyceps – How We Found 300+ Exploitable CI/CD Vulnerabilities in the Open-Source Supply Chain", 24. Juni 2026; The Hacker News, „Cordyceps CI/CD Flaws Expose 300+ GitHub Repositories to Supply-Chain Attacks", 24. Juni 2026; The Hacker News, „GitHub Updates actions/checkout to Block Common Pwn Request Attack Patterns", 23. Juni 2026.
