GitHub Actions blocks pull_request_target by default on 2 December

GitHub Actions will block the pull_request_target event by default in all public repositories on 2 December. GitHub announced the change in a changelog post today. The first date was 2 November, so this is a one-month extension.

The event runs with the base repository's secrets and write access. A workflow using it can read those secrets, GitHub writes in the post. If the workflow runs untrusted code from a fork, that code could steal them. The event sits behind many supply-chain write-ups of the past year.

What the rule does

From 2 December, Actions will not run pull_request_target jobs in public repositories unless an Actions event policy allows them. The rule applies to GitHub Free, GitHub Team and GitHub Enterprise Cloud. GitHub Enterprise Server, private repositories and internal repositories are not affected.

Two brownout windows come first. The first is on 9 November, from 16:00 to 18:00 UTC. The second is on 16 November, same hours. The block is enforced early during each window. A maintainer can see which workflows will stop next month and plan the fix.

What a maintainer does

GitHub gives two paths. One is to keep the default block in place. The other is to write an Actions event policy that explicitly allows pull_request_target for the workflow files that need it. The post asks maintainers to check Insights before the first brownout, "to see which workflow runs the rule would block."

Many open-source projects use the event to post a comment on a pull request from a fork. Others use it to label the pull request or run a check that needs write access. Each of those workflows needs a decision in the next four weeks. Keep the write access and add it to a policy, or drop the event and move the step somewhere else.

Why this is only in public repositories

Public repositories carry the risk. A fork is a stranger's code. In a private or internal repository the forks come from colleagues who already have access. GitHub Enterprise Server is a self-hosted product. A buyer there sets their own policy.

The post names the time of the first brownout to the minute. An open-source team can run a push test under the new rule and not wait for the real cutover. Six days separate the two brownouts. That is enough time to patch a workflow between them.

What this means for a team

The announcement comes from GitHub, so the facts are its own. The move is one more step toward making secrets reach workflows only when a human maintainer has said yes. For teams that run public forks of other people's projects, the fix is cheap. For a maintainer who inherited a workflow from a template years ago, 9 November is a cheap test. It shows whether anyone is still watching the Actions tab.

Source

GitHub Actions changelog.