New GitHub Actions attack chain hides in fake CI updates to steal secrets and tokens

A large GitHub attack campaign is abusing a common Actions misconfiguration to steal secrets from open source projects through pull requests that look like routine CI updates. Wiz says the campaign, tracked as prt-scan, used more than 500 malicious pull requests across six waves and at least six GitHub accounts, with the most visible burst arriving on April 2, 2026.

The attacker relied on pull requests titled ci: update build configuration, a bland label that can blend into normal maintenance work. According to Wiz, the actor successfully compromised at least two npm packages and adapted payloads to different repository types, including Node.js, Python, and Go projects.

BEST SPRING 2026 DEALS

Editor's Choice

Private Internet Access

Access content across the globe at the highest speed rate.

70% of our readers choose Private Internet Access

70% of our readers choose ExpressVPN

ExpressVPN

Browse the web from multiple devices with industry-standard security protocols.

Nord VPN

Faster dedicated servers for specific actions (currently at summer discounts)

The key weakness sits in GitHub Actions itself, or more precisely, in how some repositories use it. GitHub’s own documentation warns that pull_request_target workflows can expose secrets and write permissions if they check out untrusted fork code, and says these patterns can lead to full repository compromise.

How the attack works

Wiz says the campaign targets repositories that use pull_request_target, then submits a fork-based pull request with a malicious change placed in the right file for that project. The attacker’s tooling appears to inspect the repo, choose a fitting payload location, and rely on maintainers or automation to run the workflow in the context of the base repository.

That distinction matters. GitHub says pull_request_target runs with the privileges of the base repository, not the attacker’s fork, which means a bad workflow can expose repository secrets or write-enabled tokens if it checks out untrusted code. GitHub explicitly advises maintainers to avoid using pull_request_target with untrusted pull requests or code content.

SafeDep’s technical analysis says the main payload dumped environment data and Git authentication headers into workflow logs, then used the stolen token for reconnaissance. It also looked for cloud metadata, workflow files, secret names, and other useful targets, while using markers like ==PRT_EXFIL_START_<hex>== to make the stolen output easy to locate later.

What researchers found

Wiz says the campaign started on March 11, 2026, and unfolded in six separate waves before public reporting caught up. The researchers linked the activity to one actor using multiple accounts and said the campaign evolved from simple scripts into AI-generated, language-aware payloads.

Dark Reading, citing Wiz, says the attacker succeeded in fewer than 10% of more than 450 exploitation attempts. Even so, the campaign did compromise at least two npm packages, and that shows how a low success rate can still produce real supply chain damage at scale.

SafeDep adds useful indicators of compromise. It identified the branch pattern prt-scan-<12-char-hex>, the recurring commit message ci: update build configuration, payload files such as .github/prt_exfil.sh, and exfiltration markers including ==PRT_EXFIL_START_<hex>== and ==PRT_RECON_START_<hex>==.

Why this campaign stands out

This campaign did not depend on a novel GitHub zero-day. It weaponized a known workflow risk that GitHub, GitHub Security Lab, and OpenSSF have warned about for years. What changed here was scale, automation, and adaptation across different codebases.

Wiz describes prt-scan as another AI-powered CI/CD attack campaign, following the earlier hackerbot-claw activity. Dark Reading says the attacker appears to have used automation to target repositories in bulk, which made it easier to spray hundreds of malicious pull requests at both major projects and small hobby repos.

The broader lesson is uncomfortable but clear. Security teams do not need a brand new exploit to lose secrets in CI. A trusted-looking pull request, a permissive workflow, and one careless checkout step can be enough. GitHub now says organizations can reduce this risk by prohibiting pull_request_target entirely for external contributions and using pull_request instead, which runs without repository secrets or write permissions.

Indicators and impact at a glance

What maintainers should do now

• Audit every workflow that uses pull_request_target and remove any step that checks out fork PR head code. GitHub says workflows using this trigger must not explicitly check out untrusted code.
• Prefer pull_request for external contributions unless a privileged workflow is absolutely necessary. GitHub says this avoids exposing repository secrets and write permissions to external PR workflows.
• Search for indicators such as prt-scan- branches, PRs titled ci: update build configuration, and log markers like PRT_EXFIL_START or PRT_RECON_START. SafeDep says these are directly tied to the campaign.
• Rotate secrets immediately if a suspicious workflow ran. SafeDep says the payload can expose GITHUB_TOKEN, environment secrets, and cloud-related credentials through logs and API follow-on actions.
• Review package publishing history if your repository can ship artifacts or npm releases through CI. Wiz says the campaign already led to real npm package compromises.

FAQ