GitHub将自12月2日起在公共仓库默认阻止pull_request_target，11月9日和16日先行限时停用

2026年11月2日，GitHub发布了一条更新日志，称GitHub Actions将在所有公共仓库中默认阻止pull_request_target事件，除非适用的Actions事件策略明确允许。日期是关键细节。日志写明，强制执行原定于2026年11月2日，现在永久强制执行的新日期是2026年12月2日。这条日志被标为“停用”类别，它给公共仓库的所有者留出一个很短的窗口，用来找出即将停止运行的工作流。在这个窗口里，最稳妥的办法是把清单、负责人和测试日期一起排出来。

原因是安全。pull_request_target事件在基础仓库的上下文中运行，可以访问该仓库的机密。如果使用它的工作流去执行来自分叉仓库的不受信任代码，这些代码就可能危害流水线或窃取机密。GitHub表示，默认规则降低了这类风险，同时仍允许所有者有意识地放行依赖这个触发器的工作流。该规则通过工作流执行保护引入，最初以评估模式运行，所有者可以在强制执行开始之前，看到它会阻止哪些工作流运行。

范围很重要，日志对此的表述很窄。这项变更适用于GitHub Free、GitHub Team和GitHub Enterprise Cloud上的公共仓库，不适用于GitHub Enterprise Server，私有仓库和内部仓库也不受影响。因此，仓库类型混合的组织应先列出自己的公共仓库，因为只有这些仓库的运行才可能被阻止。

在永久强制执行之前，GitHub会在两个预定的“限时停用”窗口里实际执行默认保护。它们分别在2026年11月9日和11月16日，每次UTC时间16:00到18:00。在这些窗口中，受影响的公共仓库里被默认规则阻止的pull_request_target工作流尝试，会产生带有错误注释的失败运行，工作流不会执行。每个窗口结束后，规则回到评估模式，工作流重新运行并带有警告。因此，对这些工作流来说，限时停用是一次真实的中断，而不是纸面上的演练。

日志给出两个选择。在第一次限时停用之前，先用Insights查看规则会阻止哪些工作流运行。然后要么保留默认规则，让这个触发器继续被阻止；要么在适用的Actions事件策略中明确允许pull_request_target（如果你的工作流依赖它），并用工作流文件定位只放行特定的工作流。对整个仓库放行该事件，比只放行一个文件是更宽的决定，日志也指向了关于如何控制工作流执行的文档。

这份文档补充了日志没有重复的细节。工作流执行保护可以限制谁能触发工作流、限制哪些事件可以运行，并要求锁文件。事件规则涵盖push、pull_request、pull_request_target和workflow_dispatch等事件。参与者规则意味着，与某个GitHub功能绑定的身份，比如dependabot[bot]，需要运行工作流时必须被加为允许的参与者。文档说策略可以设在仓库、组织和企业三个层级，并建议用多个定义清晰的策略，而不是一个大策略。文档还显示出一处需要核对的矛盾：页面说，如果为某个策略选择“评估”（Evaluate）执行状态，就可以在策略洞察中监控用户何时会触及限制，同时标明评估状态仅限GitHub Enterprise Cloud；而更新日志说，默认规则在Free、Team和Enterprise Cloud的公共仓库里都以评估模式开始。这些页面没有说明Free和Team的所有者是否能看到同样的Insights视图，所以依赖它之前，应先在自己的设置里核实。

实用的做法很简短。先找出公共仓库里每一个使用pull_request_target的工作流。对每一个，判断它是否真的需要基础仓库的机密或写权限，还是改用pull_request就够了。如果必须保留，就检查它从分叉仓库检出了什么代码，因为那正是该规则针对的危险模式。然后只为那个文件添加明确的放行，记录负责人和理由，并在11月9日的窗口里测试。要把12月2日当作这样一个日期：此后缺少放行规则，就意味着工作流根本不会运行。

对维护开源项目的团队来说，这件事还有一层含义：自动化标签、评论机器人和依赖更新这类流程，过去常常靠pull_request_target来获得写权限。限时停用期间，这些流程可能同时失效，而贡献者看到的只是一个失败的检查。建议提前在贡献指南或仓库的置顶议题里说明计划，避免维护者在窗口当天才发现自动化停了。