ANALYSEN
GitHub Actions, 23.000 Repositories: wenn die Pipeline die Schlüssel offenlegt
Am 14. und 15. März 2025 wurde die von mehr als 23.000 Repositories genutzte Komponente tj-actions/changed-files so verändert, dass sie CI/CD-Geheimnisse in die Logs schrieb; erstes Ziel war ein Projekt von Coinbase. Die Analyse: Kosten ohne Diebstahl, die Pipeline als Lieferant, Haftung, Kumul und Fragen für die Vertragsverlängerung.
Archiv: Rekonstruktion, geschrieben im November 2026
Thema des Monats März 2025 · von cybercoverinsurance
Am 14. und 15. März 2025 wurde tj-actions/changed-files, eine von mehr als 23.000 Repositories genutzte Komponente von GitHub Actions, so verändert, dass sie die Geheimnisse der nutzenden Projekte in die Build-Logs schrieb: Cloud-Schlüssel, Zugriffstoken, private Schlüssel. Wenige Tage zuvor war eine andere Komponente, reviewdog/action-setup, kompromittiert worden. Spätere Analysen nannten ein Open-Source-Projekt von Coinbase als erstes Ziel.
Für Cyber-Risikoträger ist der Fall nützlich, auch wenn keine großen bekannten Schäden entstanden sind. Er zeigt, wie eine einzige Komponente der Build-Kette binnen Stunden die Zugangsdaten tausender Organisationen offenlegen kann, und wirft drei Fragen auf: Was geschieht, wenn Geheimnisse austreten, aber niemand sie nutzt? Wer haftet, wenn manipulierter Code die Pipeline verlässt? Und wie misst man einen Kumul, der über Entwicklerwerkzeuge läuft?
Was bekannt ist
Die Komponente. tj-actions/changed-files ist eine GitHub Action, die erkennt, welche Dateien sich in einem Projekt geändert haben. Laut StepSecurity nutzten sie mehr als 23.000 Repositories. Der veränderte Code führte ein Skript aus, das CI/CD-Geheimnisse (API-Schlüssel, Passwörter, Token) aus dem Speicher des Build-Prozesses las und in die Logs schrieb. Bei Projekten mit öffentlichen Logs waren die Geheimnisse für jeden lesbar. Wiz fand Dutzende öffentliche Repositories mit offengelegten Geheimnissen, darunter gültige AWS-Schlüssel, GitHub- und npm-Token und private RSA-Schlüssel (The Register).
Die Ursache. Der Angriff lief über ein persönliches Zugriffstoken des automatisierten Kontos @tj-actions-bot. GitHub erklärte, nicht feststellen zu können, wie es kompromittiert wurde. Die Komponente wird als CVE-2025-30066 mit einem Wert von 8,6 geführt (The Register). Die CISA nahm sie mit einer Warnung vom 18. März in ihren Katalog ausgenutzter Schwachstellen auf (Cybersecurity Dive).
Die Kette. Am 11. März war reviewdog/action-setup (CVE-2025-30154) kompromittiert worden, laut Wiz für rund zwei Stunden und bei rund 1.500 Repositories. Die Kompromittierung von tj-actions dauerte rund 22 Stunden und betraf rund 14.000 Repositories. Endor Labs zählte rund 218 Repositories, die tatsächlich Geheimnisse offenlegten, überwiegend GitHub-Token, die mit Ende des Jobs ablaufen (Cybersecurity Dive).
Das Ziel. Nach Unit 42 von Palo Alto Networks, später von Wiz bestätigt, zielte der Angreifer zunächst auf den öffentlichen CI/CD-Ablauf von agentkit, einem Open-Source-Projekt von Coinbase. Am 14. März hatte er ein Token mit Schreibrechten auf das Repository erlangt, konnte aber weder auf Geheimnisse von Coinbase zugreifen noch Pakete veröffentlichen. Nach der Reaktion von Coinbase ging er zum breiten Angriff auf alle Versionen von tj-actions über (Cybersecurity Dive).
Was nicht bekannt ist. Öffentlich sind keine Datendiebstähle oder Betrugsfälle bekannt, die auf die offengelegten Geheimnisse zurückgehen. Es gibt keinen Beleg, dass Geheimnisse aus öffentlichen Repositories an externe Server gesendet wurden (The Register). Wie viele Organisationen Bereinigungskosten hatten, und in welcher Höhe, ist nicht bekannt.
Ein offengelegtes Geheimnis ist bereits ein Vorfall
Kein bekannter Diebstahl, viele sichere Kosten. Die Empfehlungen von GitHub, Wiz und Sysdig waren gleich: Projekte als kompromittiert behandeln, alle Geheimnisse rotieren, die am 14. und 15. März ausgeführten Abläufe prüfen (The Register, Cybersecurity Dive). Für ein Unternehmen mit Dutzenden Pipelines bedeutet das Tage für Log-Analyse, Schlüsselrotation und Prüfung der Cloud-Zugriffe.
Die Police muss sagen, ob sie greift. Viele Cyberpolicen decken Reaktionskosten nach einem Sicherheitsereignis, doch die Definition variiert: unbefugter Zugriff, vermutete Verletzung, kompromittierte Zugangsdaten. Ein in einem öffentlichen Log ausgegebenes Geheimnis ohne Nachweis der Nutzung liegt an der Grenze. Für Risikoträger lohnt es sich, vorab zu klären, ob Analyse- und Rotationskosten auch ohne nachgewiesenen Zugriff gedeckt sind.
Der Wert eines Geheimnisses hängt davon ab, was es öffnet. Ein GitHub-Token, das mit Ende des Jobs abläuft, ist wenig wert. Ein gültiger AWS-Schlüssel öffnet die produktive Cloud-Umgebung. Die Schwere des Vorfalls, und eines möglichen Schadens, hängt mehr von den Rechten des Geheimnisses ab als von der kompromittierten Komponente.
Die Pipeline ist ein Lieferant
Fremder Code läuft mit den Schlüsseln des Versicherten. Eine GitHub Action ist Code eines Dritten, der bei jedem Lauf heruntergeladen wird und mit den Geheimnissen des Projekts arbeitet. Es ist dasselbe Muster wie bei Polymarket 2026 und Bybit 2025: externer Code an der empfindlichsten Stelle. In der Pipeline sind das die Schlüssel für Veröffentlichung und Cloud-Zugriff.
Der Verweis per Version schützt nicht. Der Angreifer verschob alle Versions-Tags von tj-actions auf den Schadcode. Wer die Komponente per Version einband, erhielt den neuen Code unbemerkt. GitHub empfiehlt, jede Action auf die vollständige Commit-Kennung festzulegen (The Register). Das ist eine einfache, überprüfbare und wenig verbreitete Kontrolle.
Automatisierte Konten sind privilegierte Identitäten. Der Zugang lief über das Token eines Bot-Kontos. Solche Konten haben oft weitreichende Rechte, keine Multi-Faktor-Authentifizierung und Token ohne Ablauf. Nach dem Vorfall reduzierte tj-actions die Rechte, führte Passkeys ein und verlangte signierte Commits (The Register).
Haftung und Kumul
Das größere Risiko ist der Code, der hinausgeht, nicht der, der hereinkommt. Hier suchte der Angreifer Geheimnisse. Mit einem Schreib-Token hätte er Code in die von einem Projekt veröffentlichten Pakete einfügen können. Für ein Softwareunternehmen ist ein an Kunden ausgeliefertes manipuliertes Paket ein Haftpflichtschaden gegenüber Dritten, mit möglichen Folgen für viele nachgelagerte Opfer.
Der Kumul läuft über Werkzeuge, nicht über Branchen. Dieselben Actions nutzen Banken, Softwarehäuser, Versicherer und Behörden. Ein nach Branchen diversifiziertes Portfolio kann auf dieselben Entwicklungswerkzeuge konzentriert sein. Die Angabe taucht in klassischen Fragebögen nicht auf.
Ein Ereignis, viele Zeitpunkte. Die Kompromittierung dauerte Stunden, doch offengelegte Geheimnisse können Wochen später genutzt werden, wenn niemand sie rotiert. Ein Ereignis mit einer einzigen Ursache kann zeitlich verteilte Schäden erzeugen, mit Aggregationsfragen wie bei Cleo und MOVEit.
Was in die Vertragsverlängerung gehört
Auswirkung für VersichererMittel
Eine von mehr als 23.000 Repositories genutzte Komponente von GitHub Actions legte rund 22 Stunden lang CI/CD-Geheimnisse offen, ohne große bekannte Schäden, aber mit verbreiteten Bereinigungskosten.
Auf Portfolioebene lautet die nützliche Frage, wie viele Versicherte GitHub Actions oder ähnliche Werkzeuge mit nicht festgelegten Fremdkomponenten nutzen. Bei Softwareunternehmen ist die Haftung gegenüber Kunden für manipulierten Code zusammen mit der eigenen Cyber-Exposition zu bewerten.