PRT-Scan and the Five-Year Window: How AI Weaponized a Vulnerability GitHub Refused to Kill

On April 2, 2026, a threat actor operating under the GitHub handle ezmtebo opened 475 malicious pull requests in 26 hours. The campaign exploited pull_request_target, a GitHub Actions workflow trigger that grants forked PRs access to base repository secrets. Security researchers branded it "prt-scan" and sounded alarms across the industry. But prt-scan was not a new attack. It was the automated, AI-accelerated rerun of a vulnerability class that has been publicly documented, repeatedly exploited, and structurally unresolved for five years. The flaw was reported to GitHub via HackerOne in December 2021. It earned the reporter two hundred dollars and a t-shirt. In the years since, the same architectural weakness has enabled the compromise of thousands of repositories, the trojanization of security scanners used by Fortune 500 companies, and the theft of credentials from organizations that believed their pipelines were hardened. Prt-scan is not the beginning of a new threat. It is the moment the old one learned to scale.

Every article covering prt-scan focuses on the same thing: an AI-powered bot opened hundreds of malicious pull requests on GitHub. The framing is understandable. Autonomous agents conducting supply chain attacks at machine speed is a compelling headline. But that framing misses the deeper, more uncomfortable story. The vulnerability that prt-scan exploits, pull_request_target, has been a known and documented risk since GitHub introduced it. Researchers have flagged it publicly. GitHub has acknowledged it. Platform changes have been announced, partially implemented, and then rendered insufficient by the next wave of exploitation. The real question is not whether AI-assisted attackers can compromise CI/CD pipelines. The answer to that has been obvious for years. The real question is why the ecosystem spent half a decade watching this exact failure mode play out in escalating severity and still did not close the window before autonomous agents climbed through it.

The Architecture of a Five-Year-Old Flaw

To understand why prt-scan worked, and why it will continue to work against unpatched targets, you need to understand what pull_request_target actually does and how it diverges from the safer pull_request trigger. In standard GitHub Actions, the pull_request event runs a workflow in the context of the fork. The fork does not get access to the base repository's secrets, tokens, or environment variables. This is a deliberate security boundary. External contributors can submit code, but that code does not execute with the permissions of the repository it targets.

The pull_request_target trigger inverts that boundary. It runs the workflow in the context of the base repository, not the fork. The original design intent was to enable maintainers to label, comment on, or triage incoming pull requests without requiring the fork to have elevated permissions. The problem is what happens when a pull_request_target workflow also checks out the code from the incoming pull request. In that scenario, attacker-controlled code from a fork executes with full access to the base repository's secrets. The GITHUB_TOKEN, any stored API keys, cloud credentials, npm publishing tokens, and anything else configured as a workflow secret all become accessible to the attacker's payload.

This is not a subtle misconfiguration. It is a well-documented architectural gap between the intended use of the trigger and how developers commonly implement it. A workflow that uses pull_request_target and performs actions/checkout with the pull request's head SHA is, by design, giving an unauthenticated external party the ability to run arbitrary code with the repository's full credential set. The security research community has a name for this class of vulnerability: a "pwn request."

A researcher reported exactly this behavior to GitHub via HackerOne in December 2021. The payout was $200. GitHub acknowledged the issue but did not change the default behavior of the trigger. The reasoning, as communicated in various community discussions, was that pull_request_target was working as designed and that maintainers were responsible for using it safely. Boost Security's year-end retrospective put the pattern bluntly: the vulnerability mechanics "stayed boring" while they were "operationalized with worms." That position held for years. It held through incidents that compromised thousands of repositories. It held through full supply chain takeovers of widely used security tools. It held until December 2025, when GitHub finally announced behavioral changes to reduce the trigger's attack surface. By then, the AI agents had already learned the pattern.

The Incident Timeline: 2024 Through Early 2026

The exploitation of pull_request_target is not a 2026 phenomenon. It is a cascade that has been accelerating for years, with each incident demonstrating a higher level of sophistication and a larger blast radius than the one before it.

These were not theoretical findings. They were active exploitation demonstrations against three of the largest technology companies on the planet, all using the same vulnerability class that had been reported to GitHub five years earlier for $200.

Hackerbot-Claw: The Autonomous Agent That Changed the Threat Model

On February 20, 2026, a GitHub account named hackerbot-claw was created. Its profile described it as an autonomous security research agent, claiming to be powered by Claude Opus 4.5. It maintained a vulnerability pattern index with 9 classes and 47 sub-patterns, a GitHub Actions automation pipeline, and a Gist-based scoreboard that logged results after each exploitation attempt. Its operator has never been publicly identified, though metadata analysis by Repello AI attributed the campaign to a single-person operation known as TeamPCP.

Between February 21 and March 2, 2026, hackerbot-claw systematically scanned public repositories for exploitable GitHub Actions workflows. According to StepSecurity's detailed analysis, it targeted Microsoft, DataDog, the Cloud Native Computing Foundation, Aqua Security, and several popular open-source projects including avelino/awesome-go (with over 140,000 GitHub stars) and RustPython/RustPython. What made the campaign unprecedented was not the vulnerability it targeted, which was the same pull_request_target misconfiguration, but the way it operated. The bot used five distinct exploitation techniques, automatically adapting its approach based on the target repository's configuration. It opened pull requests, triggered CI pipelines, exfiltrated tokens, and moved to the next target with minimal or no human intervention. According to StepSecurity's analysis, it achieved remote code execution in at least five of the seven targets.

The campaign's signature victim was Aqua Security's Trivy, a vulnerability scanner with over 32,000 GitHub stars, embedded in CI/CD pipelines across thousands of organizations. Trivy had a vulnerable pull_request_target workflow that had been present since October 2025. Boost Security's poutine tool had flagged it on November 29, 2025, over three months before hackerbot-claw exploited it. On February 28, the bot exfiltrated an org-scoped personal access token belonging to the aqua-bot service account. That token was used across at least 33 workflows in Aqua Security's GitHub organization.

What followed was a full organizational compromise. The attacker privatized and renamed the Trivy repository, pushed an empty repository to replace the original 32,000-star codebase, deleted all 178 releases including every binary asset, stripped all stars, and published a malicious Trivy VS Code extension via OpenVSX. That extension attempted to abuse local AI coding agents on developer machines by spawning them with permission-bypassing flags. The attacker left a calling card: "TeamPCP Owns Aqua Security." The compromise was assigned CVE-2026-28353 with a CVSS score near maximum.

But the damage was not over. The initial breach had not been fully remediated. On March 19, 2026, the attacker leveraged credentials obtained during the first incident to execute a second, more sophisticated compromise. According to analysis published by Snyk, the attacker rewrote 75 of 76 version tags in aquasecurity/trivy-action, the official GitHub Action used by thousands of CI/CD pipelines. Each rewritten tag pointed to a malicious commit that silently harvested credentials before executing the legitimate Trivy scan, so affected workflows appeared to function normally. The attack simultaneously targeted setup-trivy and pushed an infected Trivy binary (v0.69.4) to official distribution channels. According to Microsoft's security blog, the malware cloned the original commit metadata, including author names, commit messages, and timestamps, making detection extremely difficult. The compromised tags were active for approximately 12 hours before Trivy maintainers detected and restored them. A separate CVE, CVE-2026-33634, was assigned with a near-maximum CVSS4B score of 9.4.

There is one detail from the hackerbot-claw campaign that deserves more attention than it has received. DataDog, one of the targeted organizations, had deployed a Claude-based AI workflow reviewer on its repositories. When hackerbot-claw attempted to inject a prompt that would manipulate the AI reviewer into labeling all open issues and ignoring its safety instructions, the Claude invocation refused. As StepSecurity reported, the only defense that universally held was "Claude's prompt injection detection." The defense worked. But the attempt itself was novel: an AI attacker trying to socially engineer an AI defender through a pull request. It was a glimpse of where this threat category is headed.

Prt-Scan: Volume, Adaptation, and Machine-Speed Exploitation

Prt-scan entered the public record on April 2, 2026, when security researcher Charlie Eriksen identified a surge of automated malicious pull requests from the GitHub account ezmtebo. But according to Wiz Research, the campaign actually began three weeks earlier, on March 11, 2026, and operated across six distinct waves using six different GitHub accounts.

Wave Progression

Wiz Research traced the campaign across six waves, each operating under a different GitHub account but linked by consistent TTPs: the prt-scan- branch prefix, identical PR titles, and Proton Mail plus-addressing on all commit emails. The attacker's operational security improved between waves, but the email trail connected them. The account ezmtebo used ezmtebo+88@proton.me; earlier accounts used variants of testedbefore@proton.me with numeric suffixes. As SafeDep's analysis noted, the +88 suffix alone "implies other suffixes exist or have existed."

The progression from Wave 1 to Wave 3 reveals the AI-assisted learning loop in real time. Early payloads were crude bash scripts with no obfuscation. By the third wave, the campaign produced modular, language-aware injection files with base64-encoded stages labeled RECON, DISPATCH, and DELAYED. The five-phase payload architecture, as documented by SafeDep's technical analysis, operated entirely through the GitHub API with no external command-and-control infrastructure. All exfiltration happened through workflow log markers and PR comments, making network-based detection impossible.

Success Rate and Impact

Across more than 450 analyzed exploitation attempts, the campaign achieved a success rate below 10%. The failures tell an important story about the state of CI/CD defenses. High-value targets including Sentry, OpenSearch, IPFS, NixOS, Jina AI, and recharts all blocked the attack through combinations of first-time contributor approval gates, actor-restricted workflows, and path-based trigger conditions. The organizations that had hardened their configurations after the 2025 incidents were protected.

But at over 500 total attempts, even a 10% success rate means dozens of compromises. Confirmed credential theft included AWS keys, Cloudflare API tokens, and Netlify authentication tokens. At least two npm packages were successfully compromised. The attacker also successfully published at least one malicious package version using a stolen NPM_TOKEN.

Automation Without Understanding

For all its AI-generated sophistication, prt-scan revealed a gap between automation capability and actual technical understanding. The Wiz Research analysis identified multiple dead-code patterns in the payloads. Attempts to bypass label-gated workflows by creating and applying labels via API are circular logic that cannot work with the default GITHUB_TOKEN permissions in pull_request_target contexts. Attempts to create new workflows using stolen tokens were ignorant of the permissions model being exploited. The campaign frequently paired the wrong payload with the wrong repository type, like injecting build.rs into a Python SDK repository. Blind metadata probes for cloud instance metadata (IMDS) on GitHub-hosted runners that do not have cloud metadata endpoints were guaranteed to fail and likely to trigger detection.

This is a critical observation for defenders. Prt-scan was not an expert-level attack automated by AI. It was a low-sophistication attacker given enormous reach by AI tooling. The payloads were ambitious but flawed. The targeting was broad but imprecise. The operational security improved between waves but never reached the level of a disciplined threat actor. And yet it still compromised real targets and stole real credentials, because the underlying vulnerability gave it enough room to stumble forward successfully.

GitHub's December 2025 Patch and Why It Was Not Enough

In November 2025, GitHub announced behavioral changes to pull_request_target scheduled to take effect on December 8, 2025. The changes were significant. The workflow file and checkout commit would always be taken from the repository's default branch, regardless of the pull request's base branch. This closed a known class of vulnerabilities where attackers could exploit outdated or still-vulnerable workflow definitions lingering on non-default branches. The change also aligned GITHUB_REF and GITHUB_SHA to the default branch, preventing attackers from manipulating reference values.

These were important mitigations. But they addressed a specific edge case, not the core vulnerability. The fundamental risk of pull_request_target remains: if a workflow running under this trigger checks out code from the incoming pull request and executes it, the fork's code runs with the base repository's secrets. GitHub's December patch did not change this behavior. It could not, without breaking the legitimate use cases the trigger was designed for.

A community discussion thread about the changes captures the tension. One commenter noted that they had reported the same core issue via HackerOne in December 2021, received $200 and a t-shirt, and was watching the same vulnerability still being exploited at scale four years later. Another pointed out that repositories created before February 2023 likely still have overprivileged GITHUB_TOKEN defaults with read/write permissions, while newer repositories default to read-only. Legacy configurations dating back years are still live, still vulnerable, and still undiscovered by the teams running them.

The December 2025 patch was a necessary step. But the timeline between the HackerOne report and the platform change was four years. In that window, the vulnerability was exploited in at least seven major, publicly documented supply chain incidents. The prt-scan campaign arrived four months after the patch, targeting the repositories that had not updated their workflows and the configurations that the patch did not cover.

The AI Exploitation Loop That Nobody Is Talking About

There is a pattern emerging across the hackerbot-claw and prt-scan campaigns that extends beyond the pull_request_target vulnerability itself. It is a feedback loop between AI capabilities and CI/CD exploitation that creates a qualitatively different threat than manual attacks.

In a manual attack, a threat actor needs to understand the target's technology stack, craft a payload appropriate for that stack, test it, and iterate on failures. This limits the number of targets a single actor can engage simultaneously. It requires expertise. It is slow. It is expensive.

In an AI-assisted attack like prt-scan, the workflow is inverted. The AI handles reconnaissance by scanning workflow files across thousands of repositories to identify vulnerable configurations. It handles payload generation by adapting injection files to the target's language and build system. It handles iteration by modifying payloads between waves based on what failed. The human operator, if there is one, provides the objective and the initial tooling. The AI handles everything that previously required skilled manual labor.

The S1ngularity/Nx attack from August 2025 added another dimension. Once the attacker had compromised developer environments, they weaponized AI coding assistants already installed on those machines, using them as post-exploitation tools to scan file systems and exfiltrate credentials. The hackerbot-claw campaign pushed this further by publishing a malicious VS Code extension designed to activate AI agents with all safety controls disabled.

This creates a three-stage loop. Stage one: AI identifies and exploits CI/CD vulnerabilities. Stage two: stolen credentials are used to push malicious code into trusted packages and tools. Stage three: those poisoned tools activate AI agents on developer machines to exfiltrate additional credentials, which feed back into stage one. Each stage uses AI not as a novelty but as a force multiplier that converts a known, documented vulnerability into a mass exploitation event.

The defenders who stopped prt-scan did not use AI to do it. They used contributor approval gates. They used actor-restricted workflows. They used path-based trigger conditions. The defenses that worked were structural, not algorithmic. They reduced the attack surface before the AI could reach it. The organizations that were compromised were, almost universally, those that had not implemented these structural controls, often because they did not know they were needed.

Defender Playbook: What Actually Works

The incident data from five years of pull_request_target exploitation provides a clear picture of which defenses hold and which do not.

Structural Controls That Blocked Prt-Scan

First-time contributor approval gates stopped the prt-scan campaign at every target that had them enabled. Because the attacker operated through freshly created GitHub accounts, requiring maintainer approval before any workflow execution against a first-time contributor's PR prevented the malicious code from ever reaching the CI runner. This is the single highest-value defensive control against this entire class of identity-based attack.

Actor-restricted workflow triggers, where workflows only execute for PRs from contributors with a specific association to the repository (member, collaborator, owner), provided an additional layer. Path-based trigger conditions, where workflows only fire when changes touch specific file paths, reduced the attack surface by preventing generic CI update PRs from activating sensitive workflows.

How to Protect Your GitHub Actions Workflows Against pull_request_target Attacks

The following steps are listed in priority order, starting with the single highest-impact control and progressing through additional hardening measures. Organizations that complete all seven steps eliminate the attack surface exploited by prt-scan, hackerbot-claw, and every other pull_request_target campaign documented in this timeline.

1. Step 1: Audit all workflows for pull_request_target usage. Search every repository in your organization for workflow files containing pull_request_target. If the workflow performs actions/checkout with the pull request's head SHA (${{ github.event.pull_request.head.sha }}) or merge ref, the repository is vulnerable. Either remove the pull_request_target trigger entirely or ensure the workflow never checks out or executes code from the incoming pull request.
2. Step 2: Enable first-time contributor approval gates. Require maintainer approval before any workflow executes against a first-time contributor's pull request. This single control stopped the prt-scan campaign at every target that had it enabled, because the attacker operated through freshly created GitHub accounts that had no prior contribution history.
3. Step 3: Restrict workflow triggers to approved contributors. Configure actor-restricted workflow triggers so that workflows only execute for PRs from contributors with a specific association to the repository: member, collaborator, or owner. This prevents unknown external accounts from triggering any CI pipeline.
4. Step 4: Pin all third-party GitHub Actions to commit hashes. Replace mutable version tags (e.g., @v4) with pinned commit SHAs (e.g., @a81bbbf8298c0fa03ea29cdc473d45769f953675). The tj-actions and both Trivy compromises succeeded because downstream workflows referenced actions by tag, which the attacker silently redirected to malicious code. A pinned commit hash is immutable and cannot be redirected.
5. Step 5: Set permissions to contents: read by default. Add permissions: contents: read at the top of every workflow file. Repositories created before February 2023 may still be running with read/write GITHUB_TOKEN defaults. Explicitly restricting permissions limits what a compromised workflow can do even if the initial exploitation succeeds.
6. Step 6: Enforce CODEOWNERS review for CI-executable files. Require CODEOWNERS approval for all workflow files (.github/workflows/) and any files that auto-execute during CI, including package.json scripts, setup.py, conftest.py, Makefile targets, and build.rs. These are the exact injection points that prt-scan and hackerbot-claw specifically targeted.
7. Step 7: Monitor for prt-scan indicators of compromise. Search for branches matching prt-scan-[12-character-hex], pull requests titled "ci: update build configuration," and workflow log markers containing ==PRT_EXFIL_START_ or ==PRT_DELAYED_START_. Also search default branches for .prt_tmp_*.yml files, which indicate Phase 3 workflow injection. If any are found, rotate all credentials that were accessible to the affected workflow immediately.

Key Takeaways

1. Prt-scan exploited a five-year-old vulnerability, not a new one. The pull_request_target trigger has been a documented attack vector since at least 2021. Every major supply chain incident in this timeline, including Ultralytics, tj-actions, Nx/S1ngularity, both Trivy compromises, and prt-scan, exploits the same fundamental architectural gap: fork code executing with base repository secrets.
2. AI did not create the vulnerability. It weaponized the response gap. The window between the first public disclosure and effective platform remediation was four years. AI-assisted attackers arrived during that window and converted a known-but-unpatched flaw into a mass exploitation capability. The lesson is not that AI makes new attacks possible. It is that AI makes old, unresolved vulnerabilities catastrophically more dangerous.
3. Structural defenses work. Sophisticated detection does not matter if you do not need it. Every high-profile organization that blocked prt-scan did so with contributor approval gates, actor restrictions, and path-based triggers. These are configuration changes, not product purchases. The organizations that were compromised had not implemented them.
4. The AI exploitation feedback loop is real and accelerating. From prt-scan's language-aware payload generation to hackerbot-claw's prompt injection against AI code reviewers to the S1ngularity campaign's weaponization of AI coding assistants on developer machines, the trend is clear: AI is being used at every stage of the supply chain attack lifecycle. Defenders who are not preparing for AI-on-AI conflict in their CI/CD pipelines are already behind.
5. GitHub's December 2025 patch was necessary but incomplete. The platform changes addressed specific edge cases around branch-based exploitation but did not alter the core behavior that makes pull_request_target dangerous. Organizations cannot rely on platform defaults alone. They must audit and harden their own configurations.

Sources

This article synthesizes primary research and incident reporting from the following organizations. All claims are traceable to these published sources:

1. Wiz Research: Six Accounts, One Actor: Inside the prt-scan Supply Chain Campaign (April 2026)
2. StepSecurity: hackerbot-claw: An AI-Powered Bot Actively Exploiting GitHub Actions (March 2026)
3. Snyk: Trivy GitHub Actions Supply Chain Compromise (March 2026)
4. Microsoft Security Blog: Guidance for Detecting, Investigating, and Defending Against the Trivy Supply Chain Compromise (March 2026)
5. Repello AI: ClawBot's GitHub Actions Attack (March 2026)
6. Orca Security: pull_request_nightmare Part 2 (Google, Microsoft, NVIDIA) (September 2025)
7. Wiz Research: s1ngularity Supply Chain Attack (August 2025)
8. Snyk: Ultralytics AI Pwn Request Supply Chain Attack (December 2024)
9. GitHub Changelog: Actions pull_request_target and Environment Branch Protections Changes (November 2025)
10. GitHub Security Lab: Keeping Your GitHub Actions and Workflows Secure Part 1: Preventing Pwn Requests (2021)
11. Boost Security: Defensive Research, Weaponized: The 2025 State of Pipeline Security (December 2025)
12. SafeDep: prt-scan: A 5-Phase GitHub Actions Credential Theft Campaign (April 2026)

Frequently Asked Questions

What is the prt-scan supply chain attack?

The prt-scan campaign is an AI-assisted supply chain attack that exploits the pull_request_target trigger in GitHub Actions workflows. Starting March 11, 2026, a single threat actor cycled through six GitHub accounts, opened over 500 malicious pull requests, and used AI-generated payloads that adapted to each repository's programming language and tech stack. The campaign targeted credential theft, successfully compromising at least two npm packages and stealing AWS keys, Cloudflare API tokens, and Netlify authentication tokens.

What is pull_request_target and why is it dangerous?

The pull_request_target trigger in GitHub Actions runs workflows in the context of the base repository rather than the fork. This means that when a pull request comes from an external fork, the workflow still has access to the base repository's secrets. If the workflow also checks out code from the pull request, an attacker can submit a PR containing malicious code that executes with access to those secrets. This vulnerability class has been known since at least 2021 and has been exploited in multiple major supply chain incidents.

How does prt-scan relate to hackerbot-claw and the Trivy compromise?

Both prt-scan and hackerbot-claw exploit the same underlying vulnerability class in GitHub Actions but operate differently. Hackerbot-claw, active from February 21 through March 2, 2026, described itself as an autonomous agent powered by Claude and used five distinct exploitation techniques across seven high-profile targets. It directly led to the first Trivy supply chain compromise at Aqua Security, in which the attacker stole a personal access token, deleted all 178 GitHub releases, and published a malicious VS Code extension. A second Trivy compromise followed on March 19, 2026, when the attacker leveraged credentials from the first incident to rewrite 75 of 76 version tags in trivy-action, silently harvesting CI/CD secrets from thousands of downstream pipelines. Prt-scan, which started March 11, 2026, focused on volume over precision, opening over 500 pull requests with AI-generated language-aware payloads. Together they represent the emergence of AI-automated pipeline exploitation as a persistent threat category.

What should organizations do to protect against pull_request_target attacks?

Organizations should audit all GitHub Actions workflows for pull_request_target triggers and either remove them or ensure they never check out untrusted fork code with access to secrets. Additional defenses include enforcing first-time contributor approval gates, restricting workflow triggers to approved contributors, pinning third-party actions to commit hashes rather than mutable version tags, setting permissions to contents: read by default, and monitoring CI runner environments for unauthorized outbound network connections. GitHub's December 2025 patch addressed some edge cases but does not eliminate the core risk when workflows explicitly check out PR head code.

How does AI make supply chain attacks on CI/CD pipelines more dangerous?

AI lowers the barrier to large-scale supply chain attacks by automating vulnerability scanning across thousands of repositories, generating language-aware payloads that adapt to each target's tech stack, and iterating on evasion techniques between waves. The prt-scan campaign demonstrated this by producing Go test files for Go repos, npm scripts for JavaScript projects, and conftest.py for Python projects, all without requiring the attacker to have deep expertise in each language. Even with a sub-10% success rate, the volume of attempts produces dozens of real compromises.