GitHub Actions Now Blocks Untrusted Workflow Triggers

The TanStack attack — 84 malicious npm packages pushed in six minutes via a poisoned GitHub Actions workflow — happened last month. On June 18, GitHub shipped two features that would have stopped it: workflow execution protections that block untrusted actors before they trigger a run, and a safer default in actions/checkout that refuses to fetch fork pull request code. If your CI/CD runs on GitHub Actions, you need both of these enabled now.

Why pull_request_target Has Been a Loaded Gun

pull_request_target was designed for legitimate use: labeling PRs from forks, posting coverage comments, running status checks. The problem is that it runs with the target repository’s secrets and permissions, not the fork’s. An attacker forks your repo, submits a pull request, and — if your workflow checks out the fork’s code alongside those elevated permissions — their code runs with your credentials.

This is not a theoretical concern. The tj-actions/changed-files incident compromised 23,000 repositories in March 2025, contributing to a Coinbase breach that affected 70,000 customers. The prt-scan campaign (March–April 2026) hit 50+ repos with AI-generated payloads, exfiltrating AWS keys, Cloudflare tokens, and Netlify credentials. The TanStack attack combined the same pull_request_target pattern with Actions cache poisoning to push 84 malicious packages in under six minutes. Wiz Research found that 38% of GitHub Actions workflows are exposed to script injection risks. The pattern is well understood; what was missing was a platform-level fix.

Feature 1: Workflow Execution Protections

GitHub’s new workflow execution protections let organization and repository admins define rules that GitHub evaluates before any workflow run starts. An unauthorized actor or prohibited event never gets to execute a single step. The feature is in public preview and built on GitHub’s existing rulesets system, so targeting by repository custom property already works.

Two rule types are available at launch. Actor rules control which entities can trigger workflows — individual users, repository roles (Read, Maintain, Admin), GitHub Apps, Copilot, or Dependabot. Event rules control which events are allowed to fire: push, pull_request, pull_request_target, workflow_dispatch, and others. A rule that denies pull_request_target for all non-Maintain contributors would have blocked every attack listed above.

Find these settings in the new “Policies” section under Settings → Actions — separate from the existing “General” settings. Start with evaluate mode, which runs your rules in shadow and surfaces what would have been blocked in Policy Insights without stopping any workflows. After a day or two of reviewing the insights, flip to enforce mode.

Feature 2: actions/checkout v7 Refuses the Pwn Request Pattern

actions/checkout v7 now fails by default when a pull_request_target workflow attempts to check out fork pull request code. The specific pattern blocked: any workflow where the ref resolves to the fork’s commit SHA or merge reference. This is the exact pattern that let attackers run arbitrary code with your repository’s secrets.

# Audit your workflows right now
grep -r "pull_request_target" .github/workflows/

Any match that also contains actions/checkout with a fork-origin ref is a live vulnerability. Upgrade to v7 and the checkout step now throws an explicit error rather than silently running attacker code.

If you have a legitimate reason to check out fork code in a pull_request_target context — a coverage reporting workflow that genuinely needs the PR’s changes — you can opt out with a deliberately verbose flag:

- uses: actions/checkout@v7
  with:
    ref: ${{ github.event.pull_request.head.sha }}
    allow-unsafe-pr-checkout: true  # This shows up clearly in code review

The name is intentional. Anyone reviewing this diff will immediately see that the behavior is explicitly unsafe, which is the point.

Mark July 16 on Your Calendar

On July 16, 2026, GitHub backports the safer checkout defaults to all currently supported major versions of actions/checkout. Workflows using floating tags — actions/checkout@v4, @v5, @v6 — will automatically pick up the change. Workflows pinned to a specific SHA or patch version will not auto-update and must be manually upgraded. Run Dependabot or grep for uses: actions/checkout@ followed by a SHA to find these before July 16 finds them for you.

What to Do Right Now

• Audit: Run grep -r "pull_request_target" .github/workflows/ across every repository
• Upgrade: Bump actions/checkout to v7 in any workflow that uses pull_request_target
• Configure: As an org admin, go to Settings → Actions → Policies and add an actor rule blocking external contributors from triggering pull_request_target
• Evaluate first: Use evaluate mode for 24–48 hours before enforcing to avoid breaking legitimate workflows
• Find SHA-pinned checkouts: These will not auto-update on July 16 — find them now with Dependabot or manual grep

Part of a Larger Effort

These two features are the second layer of GitHub’s three-layer 2026 security roadmap. Layer one — dependency locking for Actions, similar to go.sum — is in public preview within the next three to six months. Layer three — a Layer 7 egress firewall for hosted runners and Actions Data Stream telemetry — is six to nine months out. The June 18 releases are the most immediately actionable piece of the plan.

GitHub took years to ship platform-level defenses for a vulnerability class that was documented and actively exploited since 2021. That is frustrating. But the controls are here now, and the attack patterns that burned TanStack, tj-actions, and Trivy are blockable with a settings toggle and a version bump. There is no good reason to leave them disabled.