GitHub 今天起默认封禁 pull_request_target：公开仓库的 Fork PR 不再自带密钥跑流程，Wiz 提醒绕过路子还在

GitHub 今天（11 月 2 日）起正式执行一项默认安全策略：公开仓库里没有单独配置事件策略的工作流，将默认被禁止使用 pull_request_target 触发器。也就是说，来自 Fork 的 Pull Request 再也不能默认带着主仓库的密钥和写权限跑流程，想继续用必须在设置里显式放行。GitHub 官方文档写明了这个执行日期，这是 9 月 17 日工作流执行保护功能正式上线时就定下的时间表。

这个触发器一直是 GitHub Actions 里最经典的“pwn request”攻击面：它在主仓库的上下文里运行，能拿到密钥和写权限，一旦工作流把 Fork 提交的代码检出来执行，攻击者就能顺走密钥。今年 7 月 AsyncAPI 生成器仓库就因此被盗走高权限 Token、冒出 4 个恶意 npm 包；Wiz 披露的 Gheist 行动里，攻击者用被盗 Token 在 850 多个账号下种了 1.3 万多个 ci-sync-* 分支，把密钥藏进工作流日志里偷走。10 月中旬的一项统计还显示，GitHub 星数前 200 的仓库里有 76 个在用这个触发器，包括 React、Next.js、PyTorch 这些大项目。

但默认封禁不等于漏洞就此消失。Wiz 在 10 月 25 日、26 日连续发表的两篇研究指出，这次加固只堵住了默认情况，绕过路子还在：把 actions/checkout 固定在 7 月 20 日回溯补丁之前的旧版本就能绕过 Fork 检出保护；不走检出、直接用 PR 标题做脚本注入也行；直接 git clone Fork 代码、以及 issue_comment、workflow_run 等触发器同样不在封禁范围内。Wiz 的结论是，GitHub 的改动把攻击门槛抬高了，但没有消灭这一整类问题。

对仓库维护者来说，今天该做的事是先去 Settings → Actions → Policies → Policy insights 看一眼，确认自家仓库哪些工作流会被拦下；确实需要这个触发器的，按单个工作流文件放行，而不是图省事全站放开，更不要用 allow-unsafe-pr-checkout 一键绕过。跑 Fork 代码优先用普通的 pull_request 触发器。这件事和 AI 编程也直接相关：GitHub 10 月 28 日的 Octoverse 报告说，9 月份全站超过 40% 的 PR 是由 AI 智能体起草的，Fork 来的 PR 越多，这类带密钥跑流程的触发器就越值得盯紧。站内此前报道的 Cursor 扩展市场后门事件与 Wiz 密钥被盗调查，讲的都是同一条供应链攻击链上的不同环节。

来源：GitHub Docs、Wiz，原文：https://docs.github.com/en/actions/concepts/about-actions-policies、https://www.wiz.io/blog/github-actions-security-pwn-request-reckoning