Full Report
A supply chain attack on popular GitHub Action tj-actions/changed-files caused many repositories to leak their secrets. Discover how it unfolded and the steps to mitigate the risk.
Analysis Summary
# Incident Report: Compromise of GitHub Action `tj-actions/changed-files` Leads to Secret Leakage
## Executive Summary
The widely used GitHub Action `tj-actions/changed-files` was compromised, resulting in a malicious payload being injected into workflows utilizing it. This payload successfully dumped CI runner memory, leaking sensitive secrets (AWS keys, PATs, etc.) into public workflow logs as double-encoded base64 payloads. The affected repository owner took the action offline on March 15, 2024, but organizations must urgently rotate exposed secrets.
## Incident Details
- **Discovery Date:** March 15, 2024 (When the underlying component was taken down/publicly disclosed)
- **Incident Date:** Unknown exploitation window leading up to March 15, 2024
- **Affected Organization:** Multiple enterprises using the compromised action
- **Sector:** Technology/Software Development (CI/CD Supply Chain)
- **Geography:** Global (Affects all users of the GitHub Action)
## Timeline of Events
### Initial Access
- **Date/Time:** Timeline of attacker injection is ongoing/unknown, but exploitation occurred prior to March 15, 2024.
- **Vector:** Supply chain attack targeting the trusted third-party GitHub Action `tj-actions/changed-files`. The attacker likely updated tags to point to malicious code hosted on a fork.
- **Details:** The impersonation resembled the Renovate bot user, but commitment authenticity via GitHub verification was not compromised, suggesting an elevation of privileges or control over the publishing process on the main repository.
### Lateral Movement
- **Details:** Not applicable in the traditional sense. The malicious code executed within the compromised CI/CD runner environment, utilizing the permissions granted to the workflow itself to access and dump runner memory containing secrets.
### Data Exfiltration/Impact
- **Details:** The malicious payload triggered the dumping of CI runner memory. Secrets were publicly leaked in the workflow logs, visible to anyone viewing the public repository logs, formatted as double-encoded base64 strings. No observed exfiltration to external attacker-controlled infrastructure.
### Detection & Response
- **Details:** The affected repository was taken down around 10:30 AM UTC, March 15, 2024. Detection involved threat hunting identifying memory dumping scripts and analysis by researchers (Wiz Threat Research, Step Security).
- **Response Actions:** The repository owning the action was taken offline. Customers were immediately urged to search their environments for usage of the action.
## Attack Methodology
- **Initial Access:** Supply chain compromise of a trusted third-party GitHub Action repository, leading to malicious code injection across all existing version tags.
- **Persistence:** Not explicitly noted via traditional methods, but persistence was gained via the continuous execution of the compromised action in subsequent CI/CD runs.
- **Privilege Escalation:** Unclear; the attacker gained the ability to push malicious updates linked to version tags.
- **Defense Evasion:** The malicious script executed within the context of a standard CI/CD job, using techniques like dumping runner memory and obfuscating leaked secrets (double-encoded base64).
- **Credential Access:** Dumping of CI runner memory containing environment variables accessible to the workflow (secrets).
- **Discovery:** The impact of the payload itself served as discovery (memory dumping).
- **Lateral Movement:** Limited to the scope of the executing runner environment.
- **Collection:** CI runner memory dump, targeting workflow secrets.
- **Exfiltration:** Local log leakage (public visibility within GitHub Actions runs), not external C2.
- **Impact:** Public exposure of sensitive organizational secrets.
## Impact Assessment
- **Financial:** Unknown, dependent on the sensitivity and subsequent misuse of leaked keys/tokens.
- **Data Breach:** Highly sensitive credentials, including AWS Access Keys, GitHub Personal Access Tokens (PATs), NPM Tokens, and Private RSA Keys belonging to impacted enterprises.
- **Operational:** Potential for immediate compromise of cloud production environments or source code repositories if leaked keys were scoped broadly.
- **Reputational:** Damage to trust in third-party tool supply chains (GitHub Actions).
## Indicators of Compromise
- **Network indicators:** None explicitly listed, as data remained within GitHub logs, not external C2.
- **File indicators:** Scripts designed to dump secrets executed during workflow runs.
- **Behavioral indicators:** Presence of a double-encoded base64 payload within the step logs of actions using `tj-actions/changed-files`. Memory dumping activity within CI runners.
## Response Actions
- **Containment:** Stop using `tj-actions/changed-files` immediately; remove all references across all branches; delete workflow runs that exposed secrets (while backing up logs first).
- **Eradication:** Not applicable to the action itself, but critical for affected users: Rotate all leaked secrets immediately.
- **Recovery:** Implement stronger pinning strategies for third-party dependencies (use commit hashes).
## Lessons Learned
- **Key Takeaways:** Relying on version tags instead of fixed hashes for third-party dependencies introduces catastrophic supply chain risk, as an attacker can upload malicious code to a tag that CI systems automatically pull.
- **What could have been done better:** Organizations should have pinned dependencies to specific commit hashes to prevent this vulnerability from affecting them. Reliance on short-lived tokens ($\text{ghs}\_$) reduces long-term risk but does not eliminate immediate exposure.
## Recommendations
- Pin all GitHub Actions usage to specific commit hashes, not version tags, to avoid supply chain injection vulnerabilities.
- Configure GitHub Organizations to use allow-listing features to restrict which third-party actions can be executed.
- Perform regular audits of CI workflow runs for unusual network activity or suspicious log entries (like base64 artifacts).
- Review and retire any custom secrets referenced in workflows that used the compromised action during the exploitation window.