GitHub Attack Exposes CI/CD Secrets: Critical Fixes for Enterprises

Table of Contents

• Overview of the GitHub Attack
• What’s Vulnerable in Enterprises?
• Compromised GitHub Actions
• CI/CD Secrets Exposure
• How to Fix the Vulnerabilities
• Next Steps for Enterprise Resilience
  

Overview of the GitHub Attack

A sophisticated cascading supply chain attack has compromised multiple GitHub Actions, exposing critical CI/CD secrets across tens of thousands of repositories. Initially targeting the “tj-actions/changed-files” utility (used by over 23,000 repositories), the attack originated from a breach of “reviewdog/action-setup@v1,” reported on March 19, 2025. As of March 24, 2025, this incident has impacted 218 confirmed repositories, with broader risks still under investigation.

This attack exploited trusted automation tools in CI/CD pipelines, leaking sensitive credentials like API tokens and access keys into workflow logs. For enterprises relying on GitHub for software development, this is a critical wake-up call to audit and secure their workflows.

What’s Vulnerable ?

The GitHub attack reveals specific weaknesses enterprises must address urgently.

Compromised GitHub Actions

The attack began with “reviewdog/action-setup@v1,” compromised between March 11, 18:42 UTC, and 20:31 UTC, 2025. This action, used by “tj-actions/eslint-changed-files,” ran in the “tj-actions/changed-files” workflow with a Personal Access Token (PAT). Attackers hijacked this PAT to inject malicious code into “tj-actions/changed-files” on March 14–15, 2025, affecting all version tags up to v45.0.7. Enterprises using these actions—or any workflows depending on them—are at risk.

• Vulnerability: Unpinned GitHub Actions (e.g., using @v1 instead of a commit SHA) pulled malicious updates automatically.
• Impact: Over 23,000 repositories were exposed, with 5,416 across 4,072 organizations referencing “tj-actions/changed-files” during the attack window.
  

CI/CD Secrets Exposure

The malicious code dumped CI/CD secrets—such as AWS keys, GitHub PATs, npm tokens, and RSA keys—into workflow logs. In public repositories, these logs were openly accessible; in private ones, insiders with log access could see them.

• Vulnerability: Secrets passed to workflows (e.g., via {{ secrets.TOKEN }}) were logged in plaintext or base64-encoded form.
• Impact: Of the affected repositories, 218 leaked secrets, though most were short-lived tokens expiring after workflow runs. Enterprises with misconfigured logs or over-privileged PATs face higher risks.
  

How to Fix the Vulnerabilities

Enterprises can mitigate this GitHub attack with these precise, actionable steps, verified against the latest data:

1. Pin Actions to Commit SHAs
   
   1. Fix: Replace version tags (e.g., tj-actions/changed-files@v45) with specific commit SHAs (e.g., uses: tj-actions/changed-files@abc123). The patched version, v46.0.1, released by March 16, 2025, is safe—pin to its SHA.
   2. Why: Prevents automatic updates to malicious commits. Enterprises using SHAs before March 14 avoided this attack.
   3. Tool: Use GitHub’s pinning dashboard or tools like StepSecurity to automate this.
      
2. Rotate Exposed Secrets
   
   1. Fix: For public repositories running “tj-actions/changed-files” between March 12, 00:00 UTC, and March 15, 12:00 UTC, 2025, rotate all secrets immediately. For private repositories, prioritize rotation if logs were accessible.
   2. Why: Secrets in logs (e.g., AWS keys, PATs) could be exploited if accessed. No external exfiltration was confirmed, but the risk persists.
   3. Action: Regenerate tokens via AWS IAM, GitHub Settings, or npm dashboards, and scope permissions to least privilege.
      
3. Audit Workflow Logs
   
   1. Fix: Review logs for workflows using “tj-actions/changed-files” or “reviewdog/action-setup@v1.” Look for base64-encoded outputs (e.g., from memdump.py or install.sh). Delete affected logs after downloading for records.
   2. Why: Removes exposed secrets from visibility. Enterprises with public logs faced higher exposure.
   3. Query: Use https://github.com/search?q=org:<your-org>+uses:+tj-actions/changed-files+language:yaml+path:.github/ to find references.
      
4. Restrict Action Permissions
   
   1. Fix: In GitHub organization settings, set Actions permissions to “read-only” by default and create an allow-list for trusted actions (e.g., v46.0.1 of “tj-actions/changed-files”).
   2. Why: Limits damage from compromised actions. The “tj-actions-bot” PAT had excessive write access, enabling the attack.
   3. Resource: GitHub’s security hardening guide.
      
5. Monitor Runtime Behavior
   
   1. Fix: Deploy eBPF-based tools (e.g., Sysdig, Falco) on CI runners to detect memory dumps or suspicious network calls. Example Falcon rule:
      

      - rule: Inline Base64 Execution
      				  desc: Detects base64 decoding from curl/wget
      				  condition: proc.cmdline contains "base64"
      				

   2. Why: Catches malicious payloads missed by static scans, as seen with install.sh in “reviewdog.”
      

Next Steps for Enterprise Resilience

This GitHub attack, tracked as CVE-2025-30066 (tj-actions) and CVE-2025-30154 (reviewdog), exposed systemic risks in CI/CD pipelines. Enterprises must act now: update to “tj-actions/changed-files” v46.0.1 (released March 16, 2025), enforce SHA pinning, and audit all third-party actions. CISA mandates federal agencies to comply by April 4, 2025—a timeline enterprises should adopt.

Long-term, integrate runtime monitoring and adopt a zero-trust model for CI/CD. The attack’s cascade—from “reviewdog” to “tj-actions”—shows how dependencies amplify vulnerabilities. Stay vigilant; more breaches may emerge as investigations continue.