GitHub Actions Just Closed the Pwn Request Window: What actions/checkout v7 Changes

If your CI pipeline uses actions/checkout and you haven’t touched it in months, it changed underneath you this week anyway. As of Monday, July 20, 2026, GitHub finished rolling out enforcement that makes actions/checkout refuse to fetch pull request code from a fork when it’s running inside a pull_request_target or workflow_run workflow. That’s the exact pattern behind the AsyncAPI Generator compromise six days earlier, and it’s not a coincidence that the enforcement date sits right after it.

The attack this closes

pull_request_target is a GitHub Actions trigger built for a real need: workflows that need to comment on a pull request, apply labels, or run a privileged check against a PR from a fork, without giving that fork’s code direct access to secrets. To make that work, the trigger runs with the target repository’s GITHUB_TOKEN and any configured secrets, even though the PR itself might come from an untrusted stranger.

The trouble starts when a workflow does both things at once: trigger on pull_request_target, and then check out and execute the PR’s actual code, whether directly or through a build step, a test runner, or a dependency install. At that point the fork’s code is running with the target branch’s privileges. That combination has a name in the security community, a pwn request, and it’s been the root cause of a string of real incidents, most recently the July 14 AsyncAPI attack, where a pull_request_target misconfiguration let an attacker steal a privileged bot token and push malicious packages to npm under a namespace with millions of weekly downloads.

What changed in checkout v7

actions/checkout v7 became generally available on June 18, 2026, and it changed the default behavior for exactly this case: when it detects it’s running inside a pull_request_target workflow (or a workflow_run workflow triggered by a pull request event), it now refuses to check out the fork’s head commit unless the workflow explicitly opts back in.

# Before: silently checks out the fork's PR code under target-branch privileges
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha }}

# After v7's default: this now fails the checkout step, by design
      - uses: actions/checkout@v7
        with:
          ref: ${{ github.event.pull_request.head.sha }}

# The explicit opt-out, for workflows that genuinely need this
      - uses: actions/checkout@v7
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          allow-unsafe-pr-checkout: true

The important part isn’t the new flag, it’s that the unsafe path now requires a line of code a reviewer can flag. Before, a workflow could ship this misconfiguration silently in a file most contributors never read closely. Now it takes a deliberate, visible opt-out.

Who this actually affects

GitHub backported the protection to every currently supported major version of actions/checkout except v1. The rollout has two very different outcomes depending on how your workflows pin the action:

How you pin actions/checkout	What happens
Floating major tag (@v4, @v5, @v6, @v7)	You already have the fix. No action needed.
Pinned to a specific SHA	Not affected automatically. Needs a manual bump to a patched SHA.
Pinned to an exact minor or patch version	Not affected automatically. Needs a version bump through Dependabot or your normal update process.
Still on actions/checkout@v1	Not covered by the backport at all. If you’re on v1 for any reason, that’s worth fixing regardless of this specific change.

Most teams use the floating major tag pattern, uses: actions/checkout@v4 and similar, specifically because it’s the convention GitHub’s own docs and templates use. If that’s you, you got this fix automatically, likely without noticing. If your organization pins to exact SHAs for supply-chain reasons, which is otherwise good practice, this is the one case where that pinning discipline means you have to go get a fix rather than receive it passively. Check your Dependabot or Renovate configuration is actually tracking actions/checkout version bumps, not just ignoring them because “it’s just a checkout step.”

What to actually check this week

1. Search your workflows for pull_request_target and workflow_run. grep -rn "pull_request_target" .github/workflows/ in any repo you maintain. Each match is a workflow that runs with elevated privileges against untrusted input by design.
2. For each match, check whether it also checks out the PR’s head ref. Look for ref: ${{ github.event.pull_request.head.sha }} or similar inside the same job. If it’s there, that job was checking out fork code with target-branch secrets before this week, and either the update fixed it silently or you’ll see a checkout failure that tells you the workflow needs allow-unsafe-pr-checkout and a closer look.
3. If you find allow-unsafe-pr-checkout after upgrading, treat it as a flag for review, not a fix. The opt-out restores the old behavior. That might be correct for a workflow that only builds a PR preview and never touches a real secret, and it might be exactly the misconfiguration this whole change exists to prevent. Read the rest of that job before deciding.
4. Confirm which secrets a pull_request_target job actually has access to. The checkout fix closes the specific step where fork code executes with those secrets. It doesn’t audit what those secrets can do. A job with id-token: write and a publish permission is worth a second look regardless of how it checks out code, following the same logic we covered in setting up npm trusted publishing to remove standing credentials in the first place.

The gap between “GitHub shipped a fix” and “your workflows actually use it” is exactly where the AsyncAPI attack happened. If your team runs any CI/CD pipeline audit as part of routine infrastructure work, this is a fifteen-minute check worth adding to it this week rather than assuming a floating version tag already covered you.