On April 2, 2026, security researcher Charlie Eriksen publicly identified an automated campaign exploiting GitHub's pull_request_target workflow trigger. The attacker, operating under the account ezmtebo, opened over 475 malicious PRs in 26 hours targeting repositories belonging to both prominent organizations and hobbyists. This attacker is reminiscent of hackerbot-claw, the AI powered CI/CD attacker that used five different exploitation methods across seven successful high profile attacks. 

But public reports on prt-scan missed the beginning of the story. Wiz Research has identified six total waves of activity from the same threat actor, starting on March 11, 2026 - three weeks before public disclosure. Across all six waves, the attacker opened well over 500 malicious PRs, successfully compromised at least two npm packages, and evolved from crude bash scripts to AI-generated, language-aware payloads. However, despite elaborate multi-phase payloads, the attack reveals fundamental misunderstandings of GitHub’s threat model, significantly limiting their success. 

The Attack in Brief

The campaign exploits a well-documented but still widespread misconfiguration: GitHub's pull_request_target trigger. Unlike pull_request, this trigger runs in the context of the base repository, granting access to repository secrets even when the PR originates from a fork. The attacker's playbook:

1. Search for repositories using pull_request_target within GitHub Actions  

2. Fork the target repository

3. Create a branch named prt-scan-{12-hex-chars}

4. Inject a malicious payload into a file that executes during CI (conftest.py, package.json, Makefile, build.rs, etc.)

5. Open a PR with the innocuous title "ci: update build configuration"

6. If the malicious workflow triggers: steal GITHUB_TOKEN, enumerate secrets, probe cloud metadata (AWS/Azure/GCP), and exfiltrate credentials via base64-encoded workflow log markers and PR comments

7. If NPM_TOKEN found: publish a malicious package version

Six Waves, One Actor

Phase 1: Probing

Wave 1a: testedbefore  (March 11–13)
Email: testedbefore@proton.me

The earliest campaign activity dates to March 11, 2026 around 08:00 UTC, when a now-deleted GitHub account began opening malicious PRs. Across 10 PRs we see small repositories targeted. All PRs present consistent TTPs: the prt-scan- branch prefix, the same title and body text, and pull_request_target exploitation.

The attacker was already testing multiple injection vectors. These include setup.py using Python's os.system() and Makefile targets with .PHONY: __prt_exfil. As early as this first wave, we can see the attacker building complex payloads featuring encoded stages across the RECON/DISPATCH patterns that will be traced throughout the campaign. 

Wave 1b: beforetested-boop (March 13–16)
Email: testedbefore+89@proton.me

Eleven hours after testedbefore’s last PR, we see this new account continue the raw shell approach, targeting larger projects. This account managed 47 PRs, as the attacker began to scale up their efforts. Payloads continued the prior pattern with package.json and Makefile injections.

Phase 2: Deployment

Wave 2a: 420tb (March 28)
Email: testedbefore+55@proton.me

After a two week gap in observed activity, a new account picks up the action. Across 11 PRs in 37 minutes, we see the attacker begin to polish their approach. 

Wave 2b: 69tf420 (March 28-29)
Email: testedbefore+99@proton.me

Two hours later, 69tf420 (GitHub ID 271847720) continued with identical attacks. Consistent TTPs were present: branch naming convention, PR title, and python-requests/2.32.5 user agent. 
The payload in this wave was a consistent raw 351-line bash script (.github/prt_exfil.sh) dropped directly into the workflow directory with no obfuscation. 

Phase 3: AI-Augmented Scale (April 2-3)

Wave 3a: elzotebo (April 2)
Email: elzotebo@proton.me

This account began experimenting with "smart" file placement, and targeted high-profile repositories. It managed 13 PRs before activity ceased. This included strange hallucinations like pip.py, as well as frequently falling back to the prt_exfil.sh bash payload. 

Wave 3b: ezmtebo (April 2-3)
Email: elzotebo+88@proton.me

That brings us to the publicly reported wave. The account was created April 2 at 20:59 UTC, with the first malicious PR opened just two minutes later. Over the next 26 hours, the attacker opened over 475 PRs.

By this point, the attacker had evolved significantly: AI-generated, repository-aware wrappers that adapt to each target's tech stack. Go test files for Go repos, npm scripts for JavaScript projects, conftest.py for Python. Better crafted payloads, with more obfuscation, and heavy stages (RECON, DISPATCH, DELAYED) are base64-encoded.

Payload Analysis: Ambitious Design, Sloppy Execution

Despite the campaign's AI-assisted targeting, the payloads reveal a gap between ambition and execution. The attacker attempted a sophisticated multi-phase payload, but filled it with techniques that feel illogical to an expert and would rarely work in practice.

General Shape

For a full breakdown of the payload, see the Appendix. 

Every payload follows the same five-phase structure, regardless of injection point:

The attacker also generates language-appropriate wrappers: 

Signs of Low Sophistication

Despite the elaborate payload, several design choices reveal the attacker's misunderstanding of GitHub's permission model:

1. Label bypass is dead code: attempting to bypass label-gated workflows by creating and applying labels via API is circular, and unlikely given GITHUB_TOKEN defaults in pull_request_target workflows. 

2. Permissions-blind exploitation: the attempts in the DISPATCH phase to create a new workflow using stolen tokens is ignorant to the permissions context being exploited. 

3. Mismatched injection files: despite the targeting, the attack frequently pairs the wrong payload and repository, like injecting build.rs in a Python SDK repo. 

4. Blind metadata-probing: attempting to access IMDS on self-hosted runners is doomed to fail and likely to drive detection. 

The attack shows automation, not understanding. The attacker built multi-language wrappers, modular base64 stages, and unique nonces per target. But they failed to validate whether techniques would work against GitHub's permission model.

Supply Chain Impact: Low Success Rate, but npm Compromise Confirmed

Across over 450 analyzed exploit attempts, we have observed a <10% success rate. In most cases, successful attacks were against small hobbyist projects, and only exposed ephemeral GitHub credentials for the workflow. For the most part, this campaign did not grant the attacker access to production infrastructure, cloud credentials, or persistent API keys, barring minor exceptions. High-value targets including Sentry, OpenSearch, IPFS, NixOS, Jina AI, and recharts all successfully blocked the attack through a combination of first-time contributor approval gates, actor-restricted workflows, and path-based trigger conditions. The campaign demonstrates that while pull_request_target vulnerabilities remain exploitable at scale, modern CI/CD security practices, particularly contributor approval requirements, are effective at protecting high-profile repositories.

However, the attacker successfully compromised at least two npm packages with a shared maintainer, across 106 versions: across @codfish/eslint-config and @codfish/actions, versions like 0.0.0-PR-{PR#}--{commit}

AI-Enabled Attack Indicators

Several characteristics suggest this campaign leverages AI/LLM capabilities:

1. Velocity: ~7 PRs per hour sustained over 22+ hours

2. Adaptive targeting: Dynamically identifies language, framework, test runner, and CI configuration

3. Idiomatic payloads: Generated code matches repository conventions (Go test file structure, pytest conftest patterns, npm script hooks)

This represents an evolution in attacker capability: agentic tooling that can fork, analyze, inject, and submit at machine speed.

Recommendations

Review your GitHub organization for Indicators of Compromise (listed below). Wiz customers should refer to our Threat Center Advisory. For preventative guidance, you can refer to our blog post on GitHub hardening.

Conclusion

The prt-scan campaign demonstrates how AI-assisted automation is lowering the barrier to large-scale supply chain attacks. Identifying vulnerable workflows, crafting plausible  injection points, and adapting to different tech stacks previously required expertise and manual orchestration. It can now be executed at machine speed across hundreds of targets by low-sophistication attackers.

The campaign's 10% success rate may seem low, but at ~500 attempts, that adds up to dozens of successful compromises. Verified credential theft was observed impacting AWS keys, Cloudflare API tokens, and Netlify auth tokens. Further, the attacker is learning: each wave showed improved evasion, more sophisticated payloads, and better operational security.

This is supply chain security's new adversary: automated, adaptive, and operating faster than manual review can catch.

Indicators of Compromise 

GitHub Accounts

• testedbefore <testedbefore@proton.me>

• beforetested-boop <testedbefore+89@proton.me>

• 420tb <testedbefore+55@proton.me>

• 69tf420 <testedbefore+99@proton.me>

• elzotebo <elzotebo@proton.me>

• ezmtebo <elzotebo+88@proton.me>

Malicious Branch Pattern: prt-scan-[12-character-hex]

PR Signatures

• Title: 'ci: update build configuration'

• Body: 'Automated build configuration update.'

• User-Agent: python-requests/2.32.5

Payload Markers in Workflow Logs

Appendix: Payload Analysis

Phase 1 - EXFIL: Immediately dump environment variables and extract the GitHub token from git config, exfiltrate by printing gzipped and base64-encoded to workflow logs where the attacker can retrieve it.

Phase 2 - RECON: Using the stolen token, enumerate secret names via GitHub API, list deployment environments and workflow files, and probe cloud metadata endpoints for SSRF opportunities.

Prereqs: Token needs actions:read or metadata:read (default in most workflows).

Phase 3 - DISPATCH: If the token has write access, create a temporary workflow file on the default branch that references all discovered secret names, then trigger it via workflow_dispatch to capture actual secret values in logs.

Prereqs: Token needs contents:write + actions:write.

Phase 4 - LABEL_BYPASS: Parse repository workflow files for label-gated conditions (e.g., if: github.event.label.name == 'safe to test'), then create and apply the required label to the malicious PR to trigger additional privileged workflows.

Prereqs: Token needs issues:write or pull_requests:write to apply labels.

Phase 5 - DELAYED: Launch a background Python daemon that scans /proc/*/environ every 2 seconds for 10 minutes, catching secrets loaded by later job steps, then exfiltrate via PR comments which persist even if workflow logs are deleted. For example, in one case we observed the initial EXFIL captured only the GitHub token, but the DELAYED daemon caught AWS_SECRET_ACCESS_KEY when it was loaded minutes later by an e2e test step, posting it to PR comments. However, other secrets like the associated AWS_ACCESS_KEY_ID were not captured. 

Prereqs: Token needs pull_requests:write or issues:write to post comments; Linux /proc filesystem required.