`pull_request_target` Without Regret: Secure Fork PRs in GitHub Actions

pull_request_target Without Regret: Secure Fork PRs in GitHub Actions If you maintain a public repo, you eventually hit this tradeoff: You want CI + automation on contributions from forks. You don’t want to leak secrets or run untrusted code with elevated permissions. A lot of teams switch to pull_request_target to get access to secrets and write permissions (for labels/comments), then accidentally check out and execute fork code in the same job. That’s one of the fastest ways to create a supply-chain incident in your own repo. In this post, I’ll show a safer pattern I use in real repos: Split untrusted validation from trusted automation . Avoid checking out attacker-controlled code in privileged contexts. Use explicit permissions and OIDC (where relevant). Add guardrails so regressions are caught automatically. Why pull_request_target is risky pull_request_target runs in the context of the base repository , not the fork. That means it can access repo secrets and can get elevated GITHU