AI PR campaign abuses pull_request_target to steal CI secrets

TL;DR — The “prt-scan” campaign mass-targeted open-source repos by submitting malicious PRs that exploit pull_request_target workflow misconfigurations to exfiltrate CI secrets and publish compromised npm packages.

What happened

GitHub Actions is GitHub’s CI/CD system, and pull_request_target is a workflow trigger intended to run PR-related workflows using the base repository’s context. Wiz reports that, unlike pull_request, pull_request_target runs with access to the base repo’s secrets even when the PR comes from a fork — a common misconfiguration that turns “untrusted contributor code” into a secrets-exfil path.

On April 2, 2026, researcher Charlie Eriksen publicly identified an automated campaign exploiting pull_request_target. Wiz’s analysis attributes the activity to a single actor operating across multiple GitHub accounts, with the most visible wave using the account ezmtebo to open 475+ malicious PRs in ~26 hours. Wiz reports the actor executed six waves starting March 11, 2026, totaling well over 500 malicious PRs.

Per Wiz, the attacker’s playbook was to fork repos, create a prt-scan-* branch, inject payloads into files that execute during CI (e.g., conftest.py, package.json, Makefile, build.rs), and then open PRs designed to trigger workflows. If triggered, payloads attempted to steal GITHUB_TOKEN, enumerate secret names, probe cloud metadata endpoints (AWS/Azure/GCP), and exfiltrate via workflow logs and PR comments.

This is a concrete example of the broader trend: CI/CD and “repo automation” remain a high-leverage supply-chain choke point, and AI-assisted automation is making mass exploitation of workflow misconfigurations operationally cheap and fast.

Who is impacted

• Organizations and maintainers running GitHub Actions workflows that use pull_request_target in ways that allow untrusted PR content to execute while secrets are available.
• Repositories targeted by “first-time contributor” PRs titled like the campaign’s signature PRs (see IoCs below).
• npm consumers of the compromised packages Wiz calls out:
  • @codfish/eslint-config
  • @codfish/actions

What to do now

• Follow the investigation guidance as stated in the report.

  • "Review your GitHub organization for Indicators of Compromise (listed below)."

• Hunt for campaign artifacts in your org:
  • PRs matching the signature title/body.
  • Branches matching prt-scan-[12-character-hex].
  • Workflow logs containing the ==PRT_*== markers.
  • Activity from the listed GitHub accounts.
• If you find evidence that secrets may have been exposed in runner logs or PR comments, treat this as a CI secrets exposure scenario and scope your response around the credentials that could have been reachable by the workflow (e.g., cloud keys, deploy tokens, npm publish tokens).
• Validate your pull_request_target usage against your threat model; Wiz points to GitHub hardening guidance for preventative controls.

  • "For preventative guidance, you can refer to our blog post on GitHub hardening."