pull_request_target Checkout Defaults: A Safe GitHub Actions Migration Checklist

GitHub changed the default behavior for actions/checkout when a workflow uses pull_request_target. GitHub’s changelog says the safer default is being backported to supported major versions, with enforcement applying on July 16, 2026. Workflows pinned to a floating major tag such as actions/checkout@v4 can receive the change automatically.

This article separates what GitHub documents from what CodeRiskTools recommends as operational guidance. The changelog describes the default change; GitHub’s security reference warns against using pull_request_target or workflow_run with untrusted pull-request code. CodeRiskTools did not test GitHub’s hosted runner implementation and this checklist is not a guarantee that a workflow is safe.

What changed and what did not

The important distinction is between checking out a repository and executing content from that checkout. GitHub’s announcement concerns checkout defaults for the pull_request_target context. It does not turn an untrusted pull request into trusted code, remove the need to review workflow permissions, or make arbitrary build commands safe.

A checkout step can place files on disk without executing them. Risk rises when later steps run package managers, repository scripts, generated configuration, test targets, Makefiles, or action code derived from the pull request. Treat the new default as a safer starting point, not as a complete threat model.

Why pull_request_target needs a separate review

pull_request_target runs in the context of the base repository. That context can expose more permissions and secrets than a normal pull_request workflow. GitHub’s security documentation therefore says to avoid the trigger with untrusted pull requests or code content. If a workflow must use it, the exact trust boundary should be explicit and narrowly enforced.

Migration checklist for existing workflows

1. Inventory triggers. Search every workflow for pull_request_target, workflow_run, and reusable workflows that receive pull-request inputs.
2. Pin the action deliberately. Review the official actions/checkout repository and decide whether a major tag, immutable commit, or reviewed organization pin matches your maintenance policy.
3. Record the checkout identity. Capture the event, base SHA, head SHA, repository, and ref for each job. Do not rely on a branch name when the security decision is about an exact commit.
4. Reduce permissions. Set an explicit top-level permissions: block, then grant job-level exceptions only where evidence shows they are needed.
5. Separate metadata from execution. A privileged job can label or comment using trusted metadata, while an isolated job evaluates untrusted code with no sensitive credentials.
6. Review every command. Expand scripts, package lifecycle hooks, action inputs, and generated files before allowing them to run in a privileged context.
7. Exercise failure paths. Test forked pull requests, renamed branches, deleted refs, failed checkout, cancellation, and a malicious-looking fixture without using real credentials.

Red flags after the default change

• A workflow checks out a pull-request head and then runs npm install, make, or a repository test command while holding write permissions.
• A pull-request value is interpolated into a shell command, path, label, or action input without a constrained representation.
• The job uses a broad GITHUB_TOKEN permission because a later step might need it.
• A third-party action is selected by a mutable tag and receives secrets or write access.
• A workflow assumes that successful checkout means the code has been reviewed or that no attacker-controlled command can run.

A bounded validation workflow

Use a disposable repository or a redacted fixture to validate the migration. First, run a static inventory and record the workflow graph. Next, execute only the metadata and checkout portions with read-only permissions. Then test the untrusted-code path in a job with no secrets and no write token. Finally, compare the observed logs and permissions with the intended design.

Label each result as tested, documented, inferred, or vendor claim. A green workflow run is not proof that a repository is secure; it only shows that one scenario completed under one configuration.

FAQ

Does the new checkout default make pull_request_target safe?

No. GitHub documents a safer checkout default, but the trigger still runs in the base repository context. Review permissions, secrets, inputs, and all commands that can execute pull-request-controlled content.

Should every workflow stop using pull_request_target?

Not automatically. GitHub documents safer patterns for cases that need trusted context, but a workflow should use the least-privileged event and isolate untrusted execution. Replacing the trigger without understanding why it exists can break required automation.

Is an immutable action pin enough?

No. Pinning improves action supply-chain reproducibility, but it does not make repository scripts, package hooks, shell interpolation, or excessive token permissions safe.

What should reviewers record?

Record the exact event, commit identities, action versions, permissions, secrets exposure, executed commands, test fixtures, and rollback path. Keep private source and tokens out of the evidence package.

Official sources and next step

• GitHub Changelog: Safer pull_request_target defaults for GitHub Actions checkout — documented rollout and default behavior.
• GitHub Docs: Secure use reference — documented workflow security practices and trigger warnings.
• GitHub Docs: Securely using pull_request_target — guidance for workflows that require this event.
• actions/checkout repository — official action source and supported inputs.

For a broader exact-change review, use the single CodeRiskTools comparison hub. Start with the free 5-point AI code review checklist. For a local intent-bound review workflow paired with secret scanning, see the documented scope of the AI Change Firewall; it does not replace GitHub’s controls or human review.

Continue the workflow review with the AI code security hub, the safe merge workflow, and the secret-scanning guide. These pages cover adjacent controls; none is a substitute for validating the exact workflow.