pull_request_target 将于 12 月 2 日默认被阻止
2026-11-02
从 2026 年 12 月 2 日起,GitHub Actions 将在所有公共仓库中默认阻止 pull_request_target 事件,除非适用的 Actions 事件策略明确允许它们。强制执行此前原定于 2026 年 11 月 2 日。GitHub 通过工作流执行保护引入了这条默认规则。该规则最初以评估模式运行,因此你可以在强制执行开始前看到它将会阻止哪些工作流运行。私有仓库和内部仓库不受影响。pull_request_target 在基础仓库的上下文中运行,并可以访问其机密。如果工作流执行来自复刻的不可信代码,该代码可能危及你的流水线或窃取机密。默认规则有助于降低这一风险,同时让你明确允许依赖该触发器的工作流。在 2026 年 12 月 2 日永久强制执行开始之前,我们将在两个预定的临时中断窗口期间临时执行默认保护。这些窗口将帮助你在强制执行永久化之前识别受影响的工作流并更新你的策略。在每个窗口期间,受影响公共仓库中被默认规则阻止的 pull_request_target 工作流尝试将创建带有错误注释的失败运行;这些工作流不会执行。每个窗口之后,默认规则将返回评估模式,允许工作流在带有警告的情况下运行。私有仓库和内部仓库不受影响。在 11 月 9 日第一个临时中断窗口之前,使用 Insights 查看该规则将会阻止哪些工作流运行。由此,你有两个选择:保留默认规则以阻止 pull_request_target。如果你的工作流依赖它,在适用的 Actions 事件策略中明确允许 pull_request_target。使用工作流文件定向来允许特定工作流。了解如何控制工作流执行以配置你的策略。此变更适用于 GitHub Free、GitHub Team 和 GitHub Enterprise Cloud 上的公共仓库,不适用于 GitHub Enterprise Server。
GitHub 宣布从 2026 年 12 月 2 日起在所有公共仓库默认阻止 pull_request_target 事件,除非 Actions 事件策略显式放行;规则先以评估模式运行,并安排两次临时中断窗口帮助排查受影响工作流。私有仓库、内部仓库和 GitHub Enterprise Server 不受影响。
- GitHub 宣布从 2026 年 12 月 2 日起在所有公共仓库默认阻止 pull_request_target 事件,除非 Actions 事件策略显式放行;规则先以评估模式运行,并安排两次临时中断窗口帮助排查受影响工作流。私有仓库、内部仓库和 GitHub Enterprise Server 不受影响。
- 原贴提到:Starting December 2, 2026, GitHub Actions will block pull_request_target
- 来源:github.blog
这是什么信号:GitHub 把 pull_request_target 从“默认可用、风险自担”改成“默认阻断、显式放行”。这不是披露某个新漏洞,而是平台对已知高危触发器收紧默认权限:公共仓库里只要没有在 Actions 事件策略中明确允许,该事件就不会触发工作流。原定执行时间是 2026 年 11 月 2 日,现改为 2026 年 12 月 2 日,说明 GitHub 给了额外缓冲期,但方向没有变。
为什么重要:pull_request_target 在基础仓库上下文中运行,能访问基础仓库的机密。一旦工作流在提权上下文里 checkout 并执行 fork 带来的不可信代码,攻击者就可能窃取令牌、污染流水线,甚至借助 CI 身份横向移动。公共仓库尤其是开源项目,长期是这类供应链攻击的高发场景。默认阻断把“每个仓库自行记得关掉危险触发器”变成“平台先关、你要用再开”,显著缩小默认风险面。
对谁有价值:直接受影响的是维护公共仓库、使用 GitHub Actions 的团队,包括开源维护者、在 GitHub Free、Team 和 Enterprise Cloud 上跑公共仓库 CI 的工程团队,以及负责平台安全的同学。私有仓库、内部仓库和 GitHub Enterprise Server 不在本次范围内,所以纯内网用户不需要改配置;但如果你有公共仓库或开源依赖链,这条信号必须进入排查清单。
可以怎么行动:第一,在 11 月 9 日第一次临时中断窗口之前,用 Insights 查看评估模式下规则会阻断哪些运行,先拿到受影响工作流清单。第二,逐个审计使用 pull_request_target 的工作流,判断是否真的需要该触发器;能用 pull_request 替代的优先替代。第三,确需保留的,在适用的 Actions 事件策略中显式允许,并尽量用工作流文件定向只放行特定工作流,不要一刀切放开整个仓库。第四,检查这些工作流是否在提权上下文里执行 fork 代码,配合最小权限令牌、限制 secrets 暴露面。第五,把两次临时中断窗口提前告知研发团队,避免失败运行和错误注释造成误判。
风险或限制:临时中断窗口期间,被规则阻断的尝试会生成失败运行并带错误注释,工作流不会执行,可能影响合并节奏和告警噪音;窗口结束后规则回到评估模式,只警告不阻断,容易被团队忽视,直到 12 月 2 日永久执行才暴露问题。显式放行并不消除风险,只是把责任交回仓库配置,放行后仍需控制不可信代码的执行路径。另外,该规则只覆盖公共仓库,私有仓库里的同类触发器风险依然存在,不能因为“不受影响”就放松审计。
这条内容的真正价值,不只是“有人发布了一个新功能”,而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说,这种信息可以转化成持续追踪的栏目选题。
如果把《pull_request_target 将于 12 月 2 日默认被阻止》放到你的内容系统里,它最大的价值在于帮助读者更快看懂“为什么值得关注”,而不是只看到一条碎片化动态。