New GitHub Actions Attack Chain Exploits Fake CI Updates to Steal Developer Secrets
A sophisticated attack campaign has emerged, targeting open-source repositories on GitHub by masquerading malicious code as routine continuous integration (CI) build configuration updates. This campaign exploits vulnerabilities in GitHub Actions workflows to exfiltrate sensitive tokens, credentials, and cloud secrets from developers who inadvertently trigger these deceptive pull requests.
Attack Overview
The campaign, identified as prt-scan, was first detected on March 11, 2026, when a threat actor using the GitHub account testedbefore began submitting malicious pull requests (PRs) to smaller repositories. Over the subsequent weeks, the attacker cycled through six different GitHub accounts, collectively opening over 500 malicious PRs. Each PR was misleadingly titled ci: update build configuration, a tactic designed to appear innocuous and blend seamlessly with legitimate updates.
The attack intensified on April 2, 2026, when security researcher Charlie Eriksen publicly reported the activity after the account ezmtebo submitted more than 475 malicious PRs within a 26-hour period. Analysts from Wiz Research traced the campaign back three weeks prior to its public disclosure, identifying six distinct waves of activity from the same threat actor.
Technical Execution
The attackers leveraged the `pull_request_target` trigger in GitHub Actions, which, unlike the standard `pull_request` trigger, executes workflows in the context of the base repository. This grants full access to repository secrets even when the PR originates from an untrusted external fork. Repositories that fail to restrict this trigger to verified contributors are particularly vulnerable.
Upon execution, the malicious workflow initiates a multi-phase operation:
1. Token Extraction: The workflow extracts the `GITHUB_TOKEN` from the git configuration, compresses it, and encodes it in base64, writing the output to workflow logs for the attacker to retrieve.
2. API Enumeration: Using the stolen token, the workflow calls GitHub’s API to enumerate secret names, deployment environments, and workflow files.
3. Cloud Credential Harvesting: The workflow probes cloud metadata endpoints for credentials associated with AWS, Azure, and Google Cloud.
4. Secret Monitoring: A background process monitors the Linux `/proc` filesystem every two seconds for ten minutes, capturing any secrets loaded by subsequent job steps.
5. Data Exfiltration: Captured data is posted directly to PR comments, where it remains even if the PR is closed, allowing the attacker to access the information at their convenience.
Impact and Implications
The campaign successfully compromised at least two npm packages—`@codfish/eslint-config` and `@codfish/actions`—across 106 package versions. Verified theft of AWS keys, Cloudflare API tokens, and Netlify authentication tokens was also confirmed. High-profile targets, including Sentry, OpenSearch, and NixOS, managed to block the attacks through stringent contributor approval controls.
What distinguishes this campaign is its deliberate use of AI-powered automation to adapt to each target. The attacker’s tooling forks repositories, analyzes their tech stack, and injects payloads into appropriate files for each language—such as Go test files for Go repositories, `conftest.py` for Python projects, and `package.json` scripts for Node.js. This level of adaptability, facilitated by AI-driven tooling, enables even low-sophistication attackers to launch large-scale supply chain attacks rapidly.
Despite its broad reach, the campaign’s overall success rate remained below 10% across more than 450 analyzed exploit attempts. Most successful attacks targeted small hobbyist projects, exposing only temporary GitHub workflow tokens. However, with over 500 total attempts, even a 10% success rate can result in dozens of real compromises. Notably, the attacker continuously refined their payloads, improving evasion techniques with each new wave.
Protective Measures
To mitigate the risk of such attacks, repository maintainers and developers are advised to:
– Restrict Workflow Triggers: Limit the use of `pull_request_target` triggers to verified contributors only.
– Review PRs Thoroughly: Carefully examine pull requests, especially those related to CI/CD configurations, for any signs of malicious code.
– Implement Least Privilege Principles: Ensure that workflows have the minimum necessary permissions and access to secrets.
– Monitor for Suspicious Activity: Regularly audit repository activity and logs for unusual patterns or unauthorized access attempts.
– Educate Contributors: Raise awareness among contributors about the risks of supply chain attacks and the importance of security best practices.
By adopting these measures, the open-source community can enhance its resilience against sophisticated supply chain attacks that exploit CI/CD pipeline vulnerabilities.
