Veröffentlicht am

4.837 GitHub-Konten, ein einziger Pull Request: Der CI-Geheimnisdieb

Autoren

Listen in English · 4.837 GitHub-Konten, ein einziger Pull Request: Der CI-Geheimnisdieb

0:00 / 0:00

Watch in English · 4.837 GitHub-Konten, ein einziger Pull Request: Der CI-Geheimnisdieb

Ein Angreifer nutzte den Schreibzugriff von 4.837 kompromittierten GitHub-Konten, testete ihn mit einem Pull Request mit dem Titel „docs: dependency audit notes“ und führte in mindestens 1.806 Repositorys einen Zugangsdaten-Stealer aus. Die Secrets, auf die er es abgesehen hatte, sind genau die, die Ihre CI bereits vorhält.

Ab Dienstag nutzte ein Angreifer gestohlene Zugangsdaten für 4.837 GitHub-Konten, um einen Secret-Stealer in Repositories einzuschleusen, auf die diese Konten Schreibzugriff hatten. Aikido Security zählte mindestens 1.806 Repositories, in denen der Stealer lief. SafeDep zählte bei unabhängiger Analyse 8.093 Repositories, die innerhalb eines 16-Stunden-Zeitraums bösartige Commits erhielten – nur Default-Branches öffentlicher Repositories, die tatsächliche Zahl ist also höher.

Die Methode war monoton und effektiv. Jeder Angriff begann mit einem Pull Request mit dem Titel docs: dependency audit notes, der von einem Branch namens wfx-docs aus geöffnet wurde, allein um zu testen, ob das Konto in das Repository schreiben konnte. Diese Test-Pull-Requests erschienen in 61.764 Repositories.

Der CI-Secret-Stealer, gezeichnet für ABN Asia

4,837
kompromittierte Konten
61,764
Test-Pull-Requests
8,093
Repositories mit bösartigen Commits

Neun Minuten Zugriff sind genug

In 7.309 Repositorys wurde der Stealer an einen bestehenden Workflow angehängt. In 771 Fällen kam er als npm-postinstall-Hook – der auch auf dem Laptop eines Entwicklers während npm install ausgeführt wird. Der Angreifer machte den Commit üblicherweise innerhalb von Minuten rückgängig und löschte die Ausführungsprotokolle, weshalb das Fehlen einer Laufnummer beim bösartigen Commit ein besserer Indikator ist als jedes zurückgelassene Artefakt.

  1. Schreibzugriff ausleihen

    4.837 gestohlene Konten, mit einem Wegwerf-PR getestet

  2. Den Stealer anhängen

    ein zusätzlicher Schritt in einem bestehenden Workflow oder ein npm-Postinstall-Hook

  3. Abgreifen

    Actions-Secrets, GITHUB_TOKEN, OIDC-Tokens, Cloud-Schlüssel, Runner-Speicher

  4. Zurückrollen und bereinigen

    Commit in Minuten verschwunden, Logs gelöscht

Vier Schritte, und keiner davon ist ein Exploit.

Was nötig war und was zurückblieb

Der Stealer sammelte GitHub-Actions-Secrets und -Variablen, das GITHUB_TOKEN des Workflows, OIDC- und Actions-Laufzeittokens, Schlüssel für KI-Dienste sowie Credential-Dateien für AWS, Azure, GCP, Kubernetes, npm, PyPI und SSH. Auf selbst gehosteten Runnern las er außerdem Cloud-Anmeldedaten aus Instanzmetadaten, Docker-Zustand und systemd-Units.

Einiges davon wurde so gebaut, dass es eine Rotation überdauert: Es kann die Trust-Policy einer AWS-Rolle umschreiben, um die Rolle für jedes AWS-Konto zu öffnen, und föderierte Identitätsanmeldeinformationen mit dem Präfix wfx-ci- zu Azure-AD-Anwendungen hinzufügen, sodass ein kompromittiertes Repository sich bei Azure anmelden kann, ohne dass ein gespeichertes Secret erforderlich ist. Deshalb lautet die Reaktion nicht „Token rotieren“, sondern „davon ausgehen, dass der gesamte Workflow von Angreifern kontrolliert wurde“.

Dummköpfig und vollständig vermeidbar

Nichts davon war ein Zero-Day. Es war Schreibzugriff plus ein Workflow-Runner – die beiden Dinge, die jedes Repository ohnehin schon hat.

Aikidos Empfehlung ist eindeutig: Jedes Konto, das einen der Test-Pull-Requests eröffnet hat, ist kompromittiert, selbst wenn der Stealer nie ausgeführt wurde; daher sollten dessen Tokens, OAuth-Grants, SSH-Schlüssel und Sitzungen widerrufen, 2FA aktiviert und jedes Secret und jede Variable, auf die das Repository zugreifen kann, rotiert werden. Jeder, der npm install auf einem betroffenen Commit ausgeführt hat, sollte diesen Rechner als kompromittiert behandeln.

ABN Asia entwickelt Software für Organisationen, die es sich nicht leisten können, selbst zur Fallstudie zu werden. Das bedeutet: Workflow-Dateien werden wie Produktionscode geprüft, Secrets sind auf den Job beschränkt, der sie benötigt, statt auf das gesamte Repository, kurzlebige OIDC-Anmeldedaten statt langlebiger Cloud-Schlüssel, Pinning und Prüfung bei jeder Abhängigkeit und Erkennung, bei der zu jeder Warnung ein Name gehört.

Sie erhalten nicht nur Software – Sie erhalten sichere Software. Wenn Ihre CI Zugangsdaten für irgendetwas Wichtiges enthält, sprechen Sie mit uns: [email protected].

The Hacker News, 12. November 2026, unter Berufung auf Analysen von Aikido Security und SafeDep.

Bitte beachten Sie, dass die deutsche Version von Ai unterstützt wird und daher geringfügige Fehler auftreten können.

AUTOR

Über ABN Asia: Ai-Banking-NetworkSecurity (ABN), ABN Asia wurde im Jahr 2012 gegründet und ist ein Unternehmen mit akademischem Hintergrund, das von Lehrkräften und ehemaligen Studierenden aus Ungarn, den Niederlanden, Russland, Deutschland und Japan gegründet wurde. Wir teilen eine gemeinsame Leidenschaft und eine klare Vision für Technologie, die Innovation und erstklassige Qualität für unsere Kunden bringt. Unser Motto lautet: Besser. Schneller. Sicherer. In vielen Fällen: Günstiger.

Zögern Sie nicht, uns zu kontaktieren, wenn Sie IT-Dienstleistungen, digitale Beratung, Standardsoftwarelösungen benötigen oder uns Angebotsanfragen (RFPs) senden möchten. Sie können uns unter [email protected] kontaktieren. Wir sind bereit, Ihnen bei all Ihren Technologiebedürfnissen zu helfen.

ABNAsia.org

© ABN ASIA