New GitHub Actions Attack Chain Uses Fake CI Updates to Exfiltrate Secrets and Tokens

A new attack campaign is actively targeting open-source repositories on GitHub by carefully disguising malicious code as completely routine CI build configuration updates.

The campaign, prt-scan exploits a widely misused GitHub Actions workflow trigger to steal sensitive tokens, credentials, and cloud secrets from developers who unknowingly trigger the fraudulent pull requests.

The attack first appeared on March 11, 2026, when a threat actor using the GitHub account testedbefore started submitting malicious pull requests to small repositories.

Over the following weeks, the same actor cycled through six separate GitHub accounts, collectively opening more than 500 malicious PRs. Every fake PR carried the same disarming title — “ci: update build configuration” — making it easy for developers to miss the embedded danger.

The campaign surged dramatically on April 2, 2026, when security researcher Charlie Eriksen publicly flagged the activity after the account ezmtebo submitted over 475 malicious PRs in a single 26-hour window.

Wiz Research analysts traced the full campaign back three weeks before anyone publicly reported it, identifying six distinct waves of activity from the same threat actor.

Researchers Rami McCarthy, Hila Ramati, Scott Piper, and Benjamin Read confirmed the attacker 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, though high-profile targets including Sentry, OpenSearch, and NixOS blocked the attacks through proper contributor approval controls.

What sets this campaign apart is its deliberate use of AI-powered automation to adapt to every target. The attacker’s tooling forks repositories, analyzes their tech stack, and injects a payload into the right file for each language — Go test files for Go repos, conftest.py for Python projects, and package.json scripts for Node.js.

This level of adaptability no longer requires deep technical skill; it is the product of AI-driven tooling that allows even low-sophistication attackers to launch large-scale supply chain campaigns at machine speed.

Despite its broad reach, the campaign’s overall success rate stayed below 10% across more than 450 analyzed exploit attempts.

Most successful hits were against small hobbyist projects, exposing only temporary GitHub workflow tokens. Still, at over 500 total attempts, even a 10% rate can produce dozens of real compromises — and the attacker kept actively learning and refining payloads, improving evasion with every new wave.

How the Attack Works

The campaign abuses the pull_request_target trigger in GitHub Actions. Unlike the standard pull_request trigger, this one runs entirely in the context of the base repository rather than the fork, granting full access to repository secrets even when the PR originates from an untrusted external fork account.

Repositories that fail to restrict this trigger to verified contributors are directly exposed to this type of attack. When the vulnerable workflow runs on a malicious PR, the payload immediately begins a five-phase operation.

It first extracts the GITHUB_TOKEN from git configuration, compresses it, and writes base64-encoded output to workflow logs for the attacker to retrieve later.

The second phase uses that stolen token to call GitHub’s API, mapping out secret names, deployment environments, and workflow files. It simultaneously probes cloud metadata endpoints for AWS, Azure, and Google Cloud credentials.

A background daemon then watches the Linux /proc filesystem every two seconds for ten minutes, catching any secrets loaded by later job steps, and posts captured data directly to PR comments — where it stays even after workflow logs are cleared.

Organizations should immediately audit their GitHub repositories for the following indicators of compromise: branches matching the pattern prt-scan-[12-character-hex], PRs titled “ci: update build configuration,” and workflow log markers such as ==PRT_EXFIL_START_[nonce]==.

Administrators should restrict pull_request_target to approved contributors only, enforce strict first-time contributor approval gates, and apply actor-restricted or path-based workflow trigger conditions. Any exposed credentials — including AWS keys, NPM tokens, and cloud API tokens — should be rotated without delay.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.