💡 actions/checkout v7 Org-Wide Migration & Pwn-Request Defense Standard

[github-actions[bot]]

Summary

GitHub's actions/checkout v7 (released Jun 18, 2026) introduces a breaking security change: it blocks fork PR checkouts in privileged workflow contexts (pull_request_target, workflow_run) by default. The Jul 16 backport to all supported major versions (v4+) means any org workflow using these triggers with fork checkout will break unless explicitly opted in with allow-unsafe-pr-checkout. This standard defines the org-wide audit, migration, and compliance enforcement approach to meet the deadline.

Market Signal

The pwn-request attack vector is now actively exploited:

• CVE-2025-66032 (Jun 2026): Claude Code GitHub Action authorization bypass (CVSS 7.8) via pwn-request pattern — attacker injects prompt via issue title, leaks ACTIONS_ID_TOKEN_REQUEST_TOKEN, pushes malicious code
• Clinejection (Feb 2026): Malicious issue title exploited chained vulnerabilities in Cline AI tool, compromising its npm package for ~8 hours
• actions/checkout v7 directly addresses this: refuses fork checkout in privileged contexts by default
• Jul 16 backport deadline: This enforcement will be backported to v4+ via floating tags — SHA-pinned workflows must be upgraded manually

User Signal

• Org already merged actions/checkout 7.0.0 bump (PR chore(deps): Bump actions/checkout from 6.0.3 to 7.0.0 #512, Jun 21) but per-workflow audit for pwn-request exposure has not been performed
• Compliance audit checks SHA pinning (closed Compliance Category: Action SHA Pinning (3 findings) #360) but not fork-checkout safety
• Multiple fleet-monitor health-check issues ([Fleet Monitor] petry-projects/.github — .github/workflows/claude-code-reusable.yml #462, [Fleet Monitor] petry-projects/.github — .github/workflows/claude.yml #449, [Fleet Monitor] petry-projects/.github — claude.yml #427) suggest workflow configuration gaps that could include unsafe checkout patterns
• The org's defense-in-depth philosophy (per AGENTS.md) demands hardening even against unlikely-seeming attack vectors

Technical Opportunity

The compliance audit framework already validates workflow files across repos. Extend it with a pwn-request exposure check:

1. Grep for pull_request_target and workflow_run triggers
2. Check if the workflow checks out fork code (uses actions/checkout with ref: ${{ github.event.pull_request.head.sha }} or similar)
3. Verify the allow-unsafe-pr-checkout flag is explicitly set if fork checkout is intentional
4. Emit compliance findings for unsafe patterns

Assessment

Dimension	Score	Rationale
Feasibility	high	Compliance audit extension — grep-based checker, no new infrastructure
Impact	high	Closes a known, actively-exploited attack vector before the backport deadline
Urgency	high	Jul 16 backport will break workflows retroactively — proactive audit needed

Adversarial Review

Strongest objection: The org doesn't accept fork PRs from external contributors — all repos are internal. Pwn-request defense is less critical when there are no untrusted forks.

Rebuttal: Even internal-only repos should be hardened: a compromised org member account, a supply chain attack on a reused action, or future open-sourcing could exploit pwn-request patterns. The compliance audit already checks less-critical items (CODEOWNERS ordering, label colors) — fork-checkout safety is higher severity. The backport will break workflows regardless of whether the org considers the risk relevant.

Suggested Next Step

1. Audit all org workflows for pull_request_target and workflow_run triggers that check out fork PR code
2. Add a pwn-request-exposure check to the compliance audit script
3. Document the allow-unsafe-pr-checkout exemption policy in ci-standards.md
4. Set a deadline of Jul 14 (2 days before backport) for all repos to be compliant