💡 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

[github-actions[bot]]

Weekly Update

What Changed

CRITICAL: July 16 backport deadline (6 days away). Since this idea was proposed on June 26:

1. actions/checkout v7 GA (June 18, 2026): Now generally available with secure-by-default pwn-request blocking. v7 refuses to fetch fork pull request code in pull_request_target and workflow_run workflows when the PR is from a fork. (Changelog)

2. July 16 backport to v3/v4/v5/v6: On July 16, 2026, the enforcement will be backported to ALL supported major versions. Workflows pinned to floating major tags (e.g., actions/checkout@v4) will automatically pick up the breaking change. SHA-pinned workflows are safe from auto-breakage but remain on vulnerable old versions until manually upgraded. (HackerNews report)

3. Read-only cache for untrusted triggers (June 26): GitHub now issues read-only cache tokens when the triggering event is untrusted (fork PRs, issue_comment, etc.). This prevents cache poisoning attacks where external actors write to the default-branch cache. (Changelog)

4. Companion security context: The MCP supply chain crisis (April 2026 — 9/11 MCP registries successfully poisoned, SDK RCE vulnerability affecting 150M+ downloads) and Microsoft's June 2026 warning about tool description poisoning reinforce the urgency of hardening all supply chain surfaces, including CI checkout patterns.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	high	high	→
Impact	high	high	→
Urgency	high	critical	↑ The July 16 backport creates a hard deadline. After that date, any floating-tag checkout@v3-v6 workflows using pull_request_target with fork PRs will break.

Recommendation

Advance immediately. Recommended actions before July 16:

1. Fleet audit: grep -rn 'actions/checkout' .github/workflows/ standards/workflows/ across all org repos. Classify each ref as SHA-pinned (safe from backport, needs manual v7 upgrade) or floating-tag (will auto-break July 16).
2. Prioritize pull_request_target workflows: pr-review-mention, claude-code, and agent-shield workflows handle fork PRs and may need explicit allow-fork-checkout: true opt-in if they legitimately need fork code.
3. Test read-only cache impact: Verify that workflows triggered by fork PRs (the agent-shield scanning path) still function correctly with read-only cache tokens.
4. Update ci-standards.md: Add v7 as the minimum recommended checkout version. Add the read-only cache behavior to the security section.