GitHub Tightens Security to Counter Pwn Request Attacks

Key points

• GitHub announced actions/checkout v7 on June 18, automatically blocking workflows that fetch unreviewed fork pull request code inside pull_request_target or workflow_run events.
• Developers who need the old behaviour must add an explicit allow-unsafe-pr-checkout to their configuration.
• On July 16, the new defaults backport to all supported major versions; workflows on floating tags like actions/checkout@v4 pick up the change automatically.
• Workflows pinned to a specific SHA, minor or patch version won't receive the backport and need a manual upgrade.
• The TeamPCP group's recent campaign compromised 170 npm packages, including the TanStack Router ecosystem, via pwn request exploits.

What is a pwn request attack?

A pwn request exploits the pull_request_target workflow trigger, which, unlike the standard pull_request trigger, grants access to repository secrets such as API keys and service tokens. That access is legitimate when the trigger is used correctly. The problem arises when developers pair it carelessly with actions/checkout to pull in code from an unreviewed fork: an attacker's code then runs with the workflow's full privileges. The weakness has been documented for years.

What has GitHub changed?

Actions/checkout v7 fails those risky workflows automatically, regardless of how the repository is configured. GitHub's changelog notes that "further hardening of additional events may be explored in future releases," so this isn't the last word. Developers who genuinely need the unsafe path must opt out explicitly rather than stumble into it by default. Our 11 June story on GitHub's npm script-blocking change shows this is part of a deliberate platform-wide tightening, not a one-off patch.

What drove the timing?

The TeamPCP hacking group compromised 170 npm packages last month using pwn request techniques. Separately, attackers breached GitHub itself and exfiltrated source code from around 3,800 of the company's internal repositories in an incident that did not involve a pwn request. Both events arriving close together clearly accelerated GitHub's hand.

Should you worry?

If your workflows use pull_request_target and you haven't audited them, yes. Floating-tag users get the fix for free on July 16. Everyone else needs to upgrade deliberately: Dependabot can handle it, but it won't run itself.

The fix is real, but the timeline is the story. A well-understood class of attack has been exploitable in the default tooling for years, and it took a wave of supply-chain compromises plus an embarrassing internal breach for the platform to ship a blocking default. Watch whether the July 16 backport lands cleanly or produces a wave of broken CI pipelines: that friction will tell you how many teams were unknowingly running the unsafe pattern.