Full Report
The compromise of GitHub Action tj-actions/changed-files has impacted only a small percentage of the 23,000 projects using it, with it estimated that only 218 repositories exposed secrets due to the supply chain attack. [...]
Analysis Summary
# Incident Report: GitHub Action Supply Chain Compromise Exposes Secrets
## Executive Summary
A supply chain attack targeted and compromised GitHub Actions published by the `tj-actions` developer, leading to the exposure of sensitive credentials in 218 customer repositories. Attackers successfully poisoned vulnerable workflows, resulting in the printing of secrets, primarily GitHub Personal Access Tokens, to public workflow logs. While many affected repositories were partially protected by security best practices (pinning to commit SHA), the incident highlights the severe risk of embedding third-party, unpinned actions into CI/CD pipelines.
## Incident Details
- **Discovery Date:** Not explicitly stated, but analysis/reporting occurred after the compromise was in effect.
- **Incident Date:** The timeframe during which the malicious action variants were executed and secrets were exposed.
- **Affected Organization:** Various organizations utilizing compromised `tj-actions` within their GitHub Workflows.
- **Sector:** Software Development/Technology (Supply Chain Impact).
- **Geography:** Global (GitHub platform).
## Timeline of Events
### Initial Access
- **Date/Time:** Preceded the discovery of exposed secrets.
- **Vector:** Compromise of the `tj-actions` GitHub repository, allowing the attacker to push malicious code updates to the GitHub Actions published there.
- **Details:** The attacker tampered with version tags associated with available GitHub Actions, redirecting users to malicious code commits.
### Lateral Movement
- The incident analysis focused on the immediate exposure of secrets during workflow runs, as opposed to traditional network lateral movement. The "movement" was the attacker's ability to inject malicious code that utilized the permissions granted to the running workflow.
### Data Exfiltration/Impact
- **Details:** Workflow runs containing the malicious action printed secrets directly to the console log, which became publicly accessible. Exposed secrets included GitHub installation access tokens (expiring within 24 hours), DockerHub credentials, npm credentials, and AWS credentials.
### Detection & Response
- **How it was discovered:** Analysis conducted by security researchers (Endor Labs).
- **Response actions taken:** Users were strongly recommended to review GitHub's security hardening advice and restrict access to files/folders within their workflows.
## Attack Methodology
- **Initial Access:** Compromise of the third-party GitHub Action package (`tj-actions`).
- **Persistence:** Not clearly defined, as the impact was through running poisoned workflows.
- **Privilege Escalation:** The attack relied on the inherent permissions granted to the GitHub Action runner environment at the time of execution.
- **Defense Evasion:** The use of mutable version tags (e.g., using `:master` or version tags) rather than specific commit SHAs, which allowed standard updates to pull the malicious code.
- **Credential Access:** Reading secrets passed to the workflow context (e.g., `${{ secrets.API_KEY }}`) and outputting them to the logging mechanism.
- **Discovery:** Not explicitly detailed, but occurred during the normal execution of CI/CD pipelines.
- **Lateral Movement:** N/A (Focus was on secret exposure during build/CI).
- **Collection:** Reading secrets from the runtime environment.
- **Exfiltration:** Printing secrets to the standard output/console log, which is accessible for GitHub Actions runs.
- **Impact:** Unauthorized exposure of sensitive organizational credentials.
## Impact Assessment
- **Financial:** Not specified, but costs associated with credential rotation, incident investigation, and potential secondary compromises.
- **Data Breach:** Exposure of credentials for multiple services, including GitHub, DockerHub, npm, and AWS. 218 distinct repositories had secrets logged.
- **Operational:** Disruption stemming from the need to immediately rotate compromised tokens and review workflow configurations.
- **Reputational:** Negative impact on trust regarding the security of third-party dependencies used within CI/CD on GitHub.
## Indicators of Compromise
- **Network indicators - defanged:** N/A (Focus was on log contamination).
- **File indicators:** Malicious commits within the `tj-actions` repository tags/branches.
- **Behavioral indicators:** Workflow runs printing tokens/secrets to the console output when they should have remained masked.
## Response Actions
- **Containment measures:** Users utilizing the affected actions should immediately rotate any exposed secrets (GitHub tokens, AWS keys, etc.).
- **Eradication steps:** Reviewing linked repositories and removing references to the compromised action OR updating references to use locked commit SHAs instead of mutable tags.
- **Recovery actions:** Implementing GitHub security hardening guidelines to prevent future direct logging of secrets.
## Lessons Learned
- **Key takeaways:** Relying on mutable tags for third-party GitHub Actions introduces significant supply chain risk. Any dependency that runs with elevated permissions (via secrets) must be treated with extreme scrutiny.
- **What could have been done better:** Many victims were protected because they followed best practices by referencing commit SHAs. This emphasizes that pinning dependencies prevents poisoning via mutable tag updates.
## Recommendations
- **Prevention measures for similar incidents:** Always pin GitHub Action dependencies to a specific commit SHA rather than using mutable tags (e.g., `@v1` or `main branch`).
- **Prevention measures for similar incidents:** Review GitHub's security hardening advice and ensure that organization secrets are never unintentionally logged or echoed during workflow execution.
- **Prevention measures for similar incidents:** Minimize the scope of permissions granted to all automated workflows.