`tj-actions/changed-files`-GitHub-Action kompromittiert – 23.000 Repos nutzen sie

• Eine populäre GitHub Action zur Nachverfolgung von Änderungen in jedem Branch wurde kompromittiert; über einen manipulierten Commit wurde versucht, CI/CD-Secrets offenzulegen
• 23.000 Repos sind betroffen, GitHub hat diese Action entfernt und sie ist nicht mehr nutzbar
• Durch eine alternative Action ersetzen und prüfen, ob Secrets in öffentlichen Workflow-Logs offengelegt wurden; danach ist eine Schlüsselrotation zwingend erforderlich
• Harden-Runner von StepSecurity entdeckte den Vorfall, und die sicherheitsgehärtete Alternative step-security/changed-files wird kostenlos bereitgestellt

Zusammenfassung des Vorfalls

• tj-actions/changed-files wird in über 23.000 Repositories verwendet und wurde kompromittiert
  • Die Angreifer änderten den Action-Code und verwiesen Version-Tags auf einen bösartigen Commit um
  • Dadurch wurden CI/CD-Secrets in GitHub-Actions-Build-Logs ausgegeben
• In öffentlichen Workflow-Logs könnten Secrets offengelegt worden sein
• Harden-Runner entdeckte das Problem nach der Erkennung eines unerwarteten Endpunkts
• Ein bösartiges Python-Skript sorgte dafür, dass Secrets aus dem Runner-Worker-Prozess ausgelesen wurden
• Alle Tags wurden auf denselben bösartigen Commit-Hash gesetzt (0e58ed8671d6b60d0890c21b07f8835ace038e67)

Maßnahmen von GitHub

• GitHub hat die Action tj-actions/changed-files entfernt und ihre Nutzung gestoppt
• Die offizielle CVE ist CVE-2025-30066

So geht die Wiederherstellung

• 1. Die von StepSecurity bereitgestellte sichere Ersatz-Action verwenden

  • Die Action tj-actions/changed-files durch step-security/changed-files@v45 ersetzen

• 2. Alle Verweise auf tj-actions/changed-files entfernen

  • Im Codebestand nach Verweisen auf tj-actions/changed-files suchen und sie entfernen:

    git grep -l "tj-actions/changed-files"  
    

• 3. Ausführungs-Logs von GitHub-Actions-Workflows prüfen

  • In den jüngsten Ausführungs-Logs prüfen, ob Secrets abgeflossen sind
  • Wenn offengelegte Secrets gefunden werden, müssen sie sofort rotiert (zurückgesetzt) werden

• 4. Allowlist für GitHub Actions einrichten

• Eine Allowlist so konfigurieren, dass nur vertrauenswürdige GitHub Actions ausgeführt werden:
  • Die Option kann in den GitHub-Einstellungen aktiviert werden:
    • Settings → Actions → Allow select actions

• 5. StepSecurity Harden-Runner konfigurieren

  • In Harden-Runner kann die Überwachung von Netzwerkverkehr und Workflow-Ausführungen eingerichtet werden

Nächste Schritte

• Problem an GitHub gemeldet → GitHub-Issue: #2463
• Das Repository tj-actions/changed-files wurde gelöscht
• Offiziell als CVE-2025-30066 erfasst
• Mit StepSecurity Harden-Runner lassen sich ähnliche Sicherheitsprobleme erkennen und verhindern
• Zur Stärkung des Sicherheitsstatus und für Echtzeitüberwachung wird die Konfiguration von Harden-Runner empfohlen

[dl57934]

Gestern Nacht funktionierte es nicht, aber jetzt geht es wieder.

[GN⁺]

Hacker-News-Kommentare

• Der Autor und Maintainer von Renovate erklärt das Angriffsszenario

  • Der Angreifer hatte Schreibzugriff auf das Repository tj-actions/changed-files
  • Der Angreifer hat einen Renovate-Commit gespooft, um einen aktuellen Commit zu tarnen
  • Dieses Spoofing diente nicht dazu, den PR zu täuschen, sondern sollte einfach Verwirrung stiften
  • Der Commit wurde als Unverified angezeigt, und die meisten Leute erzwingen nicht ausschließlich signierte Commits
  • Der eigentliche Renovate Bot schlägt PRs zur Aktualisierung von Abhängigkeiten vor
  • Einige Leute hatten Auto-Merge aktiviert, aber das ist nicht die Standardeinstellung
  • Der Vorfall erinnert daran, dass viele fälschlicherweise glauben, Git-Tags seien unveränderlich

• In den letzten Jahren ist das Vertrauen in Abhängigkeiten und Erweiterungen von Drittanbietern gesunken

  • Wenn ein npm-Paket viele Abhängigkeiten hat, wird es nicht installiert
  • Es werden keine Erweiterungen für vscode oder Chrome installiert
  • Häufig wird Schadcode hinzugefügt oder die Lizenz geändert
  • Wenn man sich den Dependency-Tree von eslint ansieht, fragt man sich, ob man allem vertrauen kann

• Das Repository ist wieder online, und der Entwickler hat eine Erklärung geliefert

  • Der Angriff ging von dem PAT-Token des Accounts @tj-actions-bot aus
  • Die Sicherheit des Accounts wurde verbessert, und GitHub hat den kompromittierten PAT widerrufen

• In ClickHouse wurden github_events untersucht, um die beim Angriff verwendeten Accounts zu identifizieren

  • Die Accounts "2ft2dKo28UazTZ" und "mmvojwip" sind verdächtig

• Es ist schockierend, dass CI/CD offenbar so ausgeführt wird, dass beliebige GitHub-Repositories eingebunden werden

  • Durch die Zunahme von LLMs wird das Problem noch gravierender
  • Wichtige Aufgaben sollten manuell ausgeführt werden

• Der Mitgründer von StepSecurity erklärt, wie der Sicherheitsvorfall erkannt wurde

  • Harden-Runner überwacht Netzwerkaufrufe in GitHub-Actions-Workflows und erkannte dadurch Auffälligkeiten

• Problematisch ist, dass GitHub Actions standardmäßig mit nicht unveränderlichen Git-Tags verwendet werden

  • Da der Hashing-Algorithmus SHA-1 Kollisionen verursachen kann, wird Unterstützung für SHA-256 benötigt

• Unveränderliche GitHub Actions sollen eingeführt werden

  • Man sollte Actions forken oder Commit-Hashes verwenden

• Das Projekt maven-lockfile erklärt den automatisch gemergten PR

  • Der echte Renovate Bot hat den Commit des gefälschten Renovate Bot automatisch gemergt

• GitHub Actions sollten für Abhängigkeiten ein Lockfile verwenden

  • Die Semver-Notation ist eine gute Lösung für dieses Problem