GitHub Actions Security: The July Checkout Change Most Teams Missed

On 20 July 2026, GitHub quietly changed what actions/checkout will do. In any workflow triggered by pull_request_target or workflow_run, it now refuses to check out code from a fork's pull request. It is the biggest GitHub Actions security change in years, and it arrived without a headline: GitHub decided to stop the most common way a CI pipeline gets turned against its owner by default, rather than keep writing warnings nobody read.

If your fintech deploys to AWS from GitHub Actions, one of three things is true. Nothing changed because you never used the pattern. Something broke in late July and someone fixed it. Or someone added allow-unsafe-pr-checkout: true to make the red go away, and the pipeline is exactly as exposed as it was in June.

Most CTOs do not want to think about CI security, and the change is two months old. That is the point. Two months is the window in which the opt-out gets added and forgotten.

What did GitHub change in actions/checkout?

The changelog entry of 18 June is short. In pull_request_target workflows, and in workflow_run workflows where the original event was a pull request, actions/checkout refuses to fetch fork pull request code when the checkout resolves to the fork repository, the PR head or merge ref, or the fork PR's head or merge commit SHA.

The three patterns it now blocks are the three everyone copied from somewhere: ref: refs/pull/${{ github.event.pull_request.number }}/merge, ref: ${{ github.event.pull_request.head.sha }}, and repository: ${{ github.event.pull_request.head.repo.full_name }}.

It shipped in v7 on 18 June and was backported to v4, v5 and v6, with enforcement from Monday 20 July. If your workflows pin to a floating major tag such as @v4, you got the change without doing anything. If you pin to a full commit SHA, which is what the hardening guide has told you to do for years, you did not get it and your old SHA still checks out the fork.

There is a way out: an input called allow-unsafe-pr-checkout. The name is doing honest work.

What is a pwn request, without the exploit?

A normal pull_request workflow runs with a read-only token and no secrets when the PR comes from a fork. That is safe and it is also why it cannot do much: it cannot comment on the PR, cannot label it, cannot publish a preview.

pull_request_target exists to fix that. It runs in the context of the base repository, with the base repository's secrets and a token that can write. GitHub's own security hardening guide says workflows on that trigger must not explicitly check out untrusted code, including from forks.

The failure is obvious once you say it out loud. A workflow checks out the fork's code, then runs npm install, or make, or a linter that loads a config file from the repo. The fork controls those files. So the fork controls what runs, with your secrets in the environment. No vulnerability in GitHub, no vulnerability in your app. A stranger opens a PR and your deploy credentials leave the building.

We have written before about the shape of this problem in a very different setting: a write path that accepts input from anyone, with nobody watching. CI is one of the surfaces on that list, and it is the one with the AWS keys.

Did it break your pipeline, or did someone opt out?

Ten minutes, from the root of each repository that deploys anything:

grep -rn "pull_request_target\|workflow_run" .github/workflows/
grep -rn "allow-unsafe-pr-checkout" .github/workflows/
grep -rnE "uses: actions/checkout@" .github/workflows/

The first line tells you which workflows run with elevated context. The second tells you whether anyone took the exit. The third shows you what each checkout is pinned to: a floating tag that got the protection, a SHA from before June that did not, or v7.

Then, for each pull_request_target workflow, ask the only question that matters: does it check out the PR's code at all? If it only reads the event payload to label or comment, it is fine and always was. If it checks out and then runs anything from the checkout, it is the pattern, whether or not GitHub's block has caught it yet.

The version we see most often is not malicious and not clever. A workflow that labelled PRs, written years ago, has at some point grown a step that runs a script from the checkout, because that was the easiest place to put it. Nobody exploited it. It was also not fine.

What did the September updates add?

The 3 September changelog has three smaller changes, and two of them matter for the same reason.

A new vulnerability-alerts permission on GITHUB_TOKEN, values read and none, gives a workflow read access to Dependabot alerts without the broader scopes people used to grant to get at them. One more thing you can stop giving write for.

Four new job context properties, job.workflow_ref, job.workflow_sha, job.workflow_repository and job.workflow_file_path, let a reusable workflow know where it actually came from. For a shared deploy workflow that several repositories call, that is the difference between "this ran" and "this ran from the reviewed file at this commit", which is the sentence an auditor wants.

The third is a REST endpoint, GET /actions/runners/deprecations/{version}, that tells you when a self-hosted runner version stops being accepted. Not a security change, but if you run your own runners inside a VPC for data-residency reasons, put it in a monthly check.

What does GitHub Actions security have to do with the RBI and SOC 2?

More than it used to. SOC 2 has always asked how changes reach production and who can approve them; a pipeline that a fork can drive is the wrong answer to both. The RBI's 2026 direction for NBFCs asks, in paragraph 125, for known vulnerabilities to be fixed in a time-bound way and the fix sustained, and in paragraph 117 for supply chain risk to be assessed. The 2025 outsourcing direction, paragraph 82, wants an inventory of the third parties in your IT supply chain. We covered both in the 2026 direction post and the outsourcing contract post.

Every third-party action in your workflows is a supplier in that inventory. actions/checkout is one. So is the marketplace action somebody added to post to Slack, pinned to @main. The hardening guide's line is worth quoting because it is blunt: pinning to a full-length commit SHA is currently the only way to use an action as an immutable release. A tag can be moved. A SHA cannot.

What should a fintech's deploy workflow look like now?

Five things, and none of them are exotic.

1. Default the token to read. Repository settings, Actions, workflow permissions, read-only. Then grant write per job for the one thing that needs it. The hardening guide says the same in as many words.
2. No pull_request_target unless a human has written down why. Most repositories need it for nothing. If you need it to label or comment, it does not check out code. If you need it to build a preview from a fork, that is the case in the last section.
3. OIDC to AWS, not a stored key. A long-lived AWS_SECRET_ACCESS_KEY in repository secrets is the thing a pwn request is after. With OIDC there is nothing to steal; the workflow assumes a role for the length of the job, and the trust policy can be scoped to one repository and one branch.
4. Pin every action to a SHA, then own the upgrade. Pinning is safer and it also means you did not receive July's fix automatically. Both are true. Dependabot can raise the bump; a person merges it.
5. Put production behind an environment with required reviewers. Then a workflow that somehow runs with the wrong code still cannot deploy without a named person clicking approve, and the click is in the log.

The OIDC step is the one to do first if you only do one, because it removes the prize. The skeleton is small: permissions: id-token: write, contents: read on the job, aws-actions/configure-aws-credentials with a role-to-assume, and an IAM trust policy that checks token.actions.githubusercontent.com for your repo:org/name:ref:refs/heads/main subject. Getting the subject condition right is where people get it wrong, so test it by trying to assume the role from a branch that should fail.

When is allow-unsafe-pr-checkout the right answer?

Sometimes, and it is worth being fair about it. An open-source project that builds preview deployments for community PRs genuinely needs to run fork code with some privilege. The pattern that survives review is to split the work: a pull_request workflow with no secrets does the build, and a separate privileged workflow consumes only the artefact, never the source. That is more work than one flag. It is also the only version an auditor will accept.

For a fintech whose repositories are private and whose contributors are employees, we have not yet seen a case where the flag was right. Forks are not how your engineers work. If the flag is in your workflows, the most likely story is that a build went red on 20 July and someone made it green.

The short version

Run the three greps this week. Delete allow-unsafe-pr-checkout wherever you find it and fix the workflow properly. Move the AWS credential to OIDC so there is nothing in secrets worth taking. Pin actions to SHAs and let Dependabot propose the bumps. Put production behind a reviewer.

None of it needs a budget. All of it needs someone to own the pipeline, which is usually the part that is missing.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.