GitHub Actions Attack Chain Exposes Secrets and Tokens
Key Takeaways A new attack campaign, dubbed “prt-scan,” is exploiting GitHub Actions’ pull_request_target trigger to steal sensitive credentials and tokens from open-source...
Key Takeaways
- A new attack campaign, dubbed “prt-scan,” is exploiting GitHub Actions’
pull_request_targettrigger to steal sensitive credentials and tokens from open-source repositories. - The attacker uses AI-powered automation to craft highly targeted, malicious pull requests disguised as routine CI build configuration updates.
- Over 500 malicious pull requests have been observed, leading to the confirmed compromise of at least two npm packages and the theft of AWS keys, Cloudflare API tokens, and Netlify authentication tokens.
- The vulnerability lies in the improper configuration of the
pull_request_targettrigger, which, if unrestricted, grants full access to repository secrets even from untrusted forks. - Immediate action is required for repository maintainers to audit their workflows, restrict trigger access, and rotate any potentially exposed credentials.
A sophisticated new attack campaign is actively targeting open-source projects hosted on GitHub, leveraging a misconfigured GitHub Actions workflow trigger to exfiltrate sensitive data. Dubbed “prt-scan,” this campaign injects malicious code under the guise of benign CI build configuration updates, compromising developer secrets, tokens, and cloud credentials.
Table Of Content
The campaign exploits the pull_request_target trigger in GitHub Actions. Unlike the standard pull_request trigger, which operates within the context of the forked repository, pull_request_target executes in the base repository’s context. This critical distinction means that if not properly restricted, workflows triggered by external pull requests can gain full access to the base repository’s secrets, even when originating from an untrusted source.
Campaign Evolution and Scope
The “prt-scan” campaign was first detected on March 11, 2026, when a threat actor operating under the GitHub account testedbefore initiated a series of malicious pull requests targeting smaller repositories. Over subsequent weeks, the same actor cycled through six distinct GitHub accounts, collectively submitting more than 500 fraudulent pull requests. Each of these malicious PRs bore the identical, unassuming title: “ci: update build configuration,” a tactic designed to blend in with legitimate development activity and evade scrutiny.
The activity escalated significantly on April 2, 2026, drawing public attention when security researcher Charlie Eriksen flagged the campaign after the account ezmtebo alone submitted over 475 malicious PRs within a 26-hour period. Analysts at Wiz Research subsequently traced the campaign back three weeks prior to its public disclosure, identifying six distinct waves of activity orchestrated by the same threat actor.
Through these attacks, researchers Rami McCarthy, Hila Ramati, Scott Piper, and Benjamin Read confirmed the successful compromise of at least two npm packages, @codfish/eslint-config and @codfish/actions, across 106 different package versions. The confirmed theft included AWS keys, Cloudflare API tokens, and Netlify authentication tokens. Notably, high-profile targets such as Sentry, OpenSearch, and NixOS successfully thwarted these attacks by implementing robust contributor approval controls, preventing the malicious workflows from executing.
AI-Powered Automation in Action
A defining characteristic of this campaign is its sophisticated use of AI-powered automation, allowing the attacker to adapt to each target’s specific technical environment. The attacker’s tooling automatically forks repositories, analyzes their underlying tech stack, and then tailors the malicious payload to inject it into the appropriate file type for the detected language—for instance, Go test files for Go repositories, conftest.py for Python projects, and package.json scripts for Node.js projects.
This level of adaptability significantly lowers the barrier to entry for launching large-scale supply chain attacks. It demonstrates how AI-driven tools can empower even less-sophisticated attackers to execute broad, highly targeted campaigns at machine speed. Despite the extensive reach, the campaign’s overall success rate remained below 10% across more than 450 analyzed exploit attempts. Most successful compromises affected smaller, hobbyist projects, often exposing only temporary GitHub workflow tokens. However, with over 500 attempts, even a 10% success rate translates to dozens of genuine compromises, and the attacker continuously refined payloads and evasion techniques with each new wave, indicating an active learning process.
How the Attack Unfolds
The attack chain begins when a vulnerable GitHub Actions workflow, configured with the pull_request_target trigger, executes on a malicious pull request. The payload then initiates a five-phase exfiltration process:
- It first extracts the
GITHUB_TOKENfrom the git configuration, compresses it, and encodes the output in base64, writing it to workflow logs for later retrieval by the attacker. - Using the stolen token, the payload queries GitHub’s API to map out secret names, deployment environments, and workflow files. Concurrently, it probes cloud metadata endpoints for AWS, Azure, and Google Cloud credentials.
- A background daemon monitors the Linux
/procfilesystem every two seconds for ten minutes, capturing any secrets loaded by subsequent job steps. - Crucially, captured data is then posted directly to PR comments, ensuring its persistence even if workflow logs are cleared.
What You Should Do
- Immediately audit all GitHub repositories for indicators of compromise, including branches matching the pattern
prt-scan-[12-character-hex], pull requests titled “ci: update build configuration,” and workflow log markers such as==PRT_EXFIL_START_[nonce]==. - Restrict the
pull_request_targettrigger to approved contributors only. Implement strict first-time contributor approval gates for all repositories. - Apply actor-restricted or path-based workflow trigger conditions to limit when and by whom workflows can be executed.
- Rotate any potentially exposed credentials without delay. This includes AWS keys, NPM tokens, Cloudflare API tokens, Netlify authentication tokens, and any other cloud API tokens.
- Review and harden existing GitHub Actions workflows, ensuring that secrets are handled securely and that triggers are configured with the principle of least privilege.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.