12 月 2 日起，公开仓库的 pull_request_target 默认会被拦下

先说结论：12 月 2 日起，公开仓库的 pull_request_target 默认会被拦下

GitHub 在 2026 年 11 月 2 日的 Changelog 中宣布：从 2026 年 12 月 2 日起，GitHub Actions 将在所有公开仓库中默认阻止 pull_request_target 事件，除非适用的 Actions 事件策略明确放行它。这项强制原本定在 11 月 2 日执行，现已推迟一个月，给了仓库维护者一段最后的整改窗口。在此之前，默认规则处于评估模式：它会告诉你哪些运行会被拦，但还不会真正动手。

这个时间点值得所有维护公开仓库的人认真对待，因为 pull_request_target 并不是一个冷门触发器。它是很多开源项目处理外部贡献的标准做法：给来自 fork 的拉取请求贴标签、发表评论、跑需要密钥的预览部署、把测试结果回写到 PR 里。一旦默认规则生效，这些工作流会在没有预警的情况下直接失败——除非你提前做了两件事中的一件：要么接受默认阻止，要么在策略里明确放行。

先划清范围，避免不必要的恐慌。这次变化只影响公开仓库，且只适用于 GitHub Free、Team 和 Enterprise Cloud；私有仓库、内部仓库和 GitHub Enterprise Server 不受影响。如果你维护的仓库全部是私有的，这篇可以跳过；只要你有一个公开仓库，哪怕它只是个小工具，都值得花十分钟自查一次。

为什么偏偏是 pull_request_target？因为它天生拿着密钥

要理解这条规则，先理解 pull_request_target 的特殊之处。普通的 pull_request 事件在 fork 的代码上下文中运行，拿不到目标仓库的密钥；而 pull_request_target 在目标仓库的上下文中运行，可以访问仓库密钥。它的设计初衷是合理的：有些任务必须以仓库的身份执行，比如用机器人账号评论、调用需要认证的外部服务、部署预览环境。

但这个能力也正是风险所在：如果工作流执行了来自 fork 的不可信代码，那段代码就有可能窃取密钥、破坏流水线。过去几年，这类攻击路径已经被反复讨论：PR 里改一行工作流之外的代码、改一个被工作流执行的脚本、改一份会被解析的配置文件，都可能成为跳板。GitHub 这次的做法不是删除这个触发器，而是把默认立场从“默认放行”翻转为“默认阻止”，把举证责任交还给维护者：你确实需要它，就明确说出来。

这里有一个常见的误解需要澄清：默认阻止不等于禁用功能。它更像一道默认上锁的门——钥匙还在你手里，只是不再替你敞着。已经有适用的事件策略明确放行的仓库，不会被这条默认规则改写；没有策略的仓库，才会在 12 月 2 日之后撞上这道门。

两个褐断窗口：11 月 9 日和 11 月 16 日，别等到 12 月才发现问题

在 12 月 2 日永久生效之前，GitHub 安排了两次临时强制窗口，也就是俗称的褐断：2026 年 11 月 9 日 16:00–18:00（UTC），以及 11 月 16 日同一时段。在这两个窗口里，被默认规则拦下的 pull_request_target 尝试会产生失败的运行记录并附带错误标注，工作流不会执行；窗口结束后，规则回到评估模式，工作流恢复运行并只给出警告。

这两个窗口是留给你的免费演习。正确的做法不是祈祷窗口期没有外部贡献者提 PR，而是主动利用它们：11 月 9 日之前先去 Insights 里查看哪些运行会被拦，列出清单；11 月 9 日窗口期观察实际失败情况，确认清单没有遗漏；11 月 16 日第二窗口复核修复效果。如果你的项目在窗口期恰好没有外部 PR，也别当作“没问题”——没有触发不等于没有风险，评估模式里的警告记录才是更可靠的依据。

换算成北京时间，这两个窗口是 11 月 10 日和 11 月 17 日的凌晨 0:00–2:00，正好是多数人睡觉的时间。这意味着你不能指望“窗口期盯着看”，而应该提前把检查做完，让窗口期的失败记录成为验证手段，而不是发现问题的第一现场。

自查三步：先看 Insights，再分三类处理

GitHub 官方给出的操作路径很清晰：12 月 2 日之前，用 Insights 查看哪些工作流运行会被默认规则阻止，然后二选一——保留默认阻止，或者在适用的 Actions 事件策略中明确放行。但在动手之前，建议先把受影响的工作流分成三类，因为三类的正确处理完全不同。

第一类是“根本不该用 pull_request_target”的工作流：它只是跑测试、跑 lint、构建产物，根本不需要仓库密钥。这类最常见的成因是复制粘贴——从别人的工作流模板抄来触发器，一直沿用至今。对它们，正确动作是改回 pull_request，顺带去掉不再需要的密钥权限，工作流反而更安全、也更符合最小权限原则。

第二类是“确实需要仓库身份，但可以拆分”的工作流：比如先用 pull_request 跑不可信代码的测试，再由一个独立的、只处理受信产物的流程去评论或部署。把“执行外部代码”和“使用密钥”拆成两个工作流，是这类场景最干净的解法：前者拿不到密钥，后者不执行外部代码，攻击链就断了。拆分需要多花一点时间，但这是唯一能同时保住功能和安全的结构。

第三类是“确实需要、也无法拆分”的工作流：比如必须对 fork 的 PR 发表带密钥认证的评论，或者部署依赖密钥的预览环境。对这类，正确动作是在事件策略中明确放行，并且尽可能缩小放行范围：GitHub 支持按工作流文件定向放行，只放行具体的那一个文件，而不是笼统地放行整个触发器。放行时顺手做一次权限审计：这个工作流真的需要它当前拥有的全部权限吗？能收紧的 secret、能降级的 token 权限，都应该在这次一起收紧。

最危险的放行方式：图省事全量放行

这轮变化里最值得警惕的不是规则本身，而是它可能诱发的应激反应：12 月 2 日之后某个工作流突然失败，维护者为了尽快恢复，随手把 pull_request_target 全量放行，甚至在组织层面一放了之。那样做等于亲手把默认保护拆掉，而且拆完之后没有任何记录能提醒你“这里曾经有道门”。

更稳妥的顺序是反过来的：先接受默认阻止，让失败暴露出来；再逐个工作流判断它属于上面三类的哪一类；只对第三类做定向放行，并且在放行记录里写清楚理由——这个工作流为什么必须用 pull_request_target、它访问哪些密钥、它的触发条件是什么。三个月后当你或你的继任者再看到这条策略时，这段理由就是唯一能判断“这条放行是否还合理”的依据。

还有一个容易被忽略的细节：这条默认规则不会覆盖你已有的事件策略。也就是说，如果你之前已经在组织或企业层面配置过事件策略，默认规则不会替你改写它。自查时要同时看两层：仓库层面有没有受影响的工作流，组织层面现有的策略是否已经放行了它。只看一层，很容易得出错误的“不受影响”结论。

对开源维护者的实际影响：小项目反而更需要提前动手

大项目通常有专人负责 CI，大概率会在 11 月就把这事处理完；真正容易中招的是小项目和个人维护的公开仓库：工作流是几年前搭的，触发器是抄来的，平时没人看 Insights，外部贡献者也不多。12 月 2 日之后，第一个来自 fork 的 PR 触发失败时，维护者才发现问题，而那时贡献者可能已经困惑地离开了。

对这类项目，我的建议是：不要等到有外部 PR 才处理。现在就去 Actions 的 Insights 里看一次评估结果，哪怕你的仓库半年没有外部 PR，也要确认清单是空的而不是“没看过”。如果清单非空，按三类法处理一遍，整个过程通常不超过半小时——比起 12 月之后在贡献者面前手忙脚乱地修，这半小时非常划算。

另外值得一提的是，这次变化和 GitHub 同期的其他安全收紧属于同一条主线：默认立场正在从“方便优先”转向“安全优先”，而把选择权明确交还给维护者。理解了这条主线，就能预判后续：类似的默认收紧还会出现，养成“定期检查评估警告”的习惯，比每次临时救火要省事得多。

一份可直接执行的检查清单

最后把操作收敛成一份清单，照着做一遍即可。第一，在 11 月 9 日之前打开 Insights，导出会被默认规则阻止的工作流清单。第二，把清单按三类分流：能改回 pull_request 的改回去，能拆分的拆分，只对确实无法替代的做定向放行。第三，收紧被放行工作流的权限：最小 secret 集合、最小 token 权限、必要时加环境审批。第四，在 11 月 9 日和 11 月 16 日的褐断窗口后各复核一次失败记录，确认没有遗漏。第五，把放行理由写进策略备注或仓库文档，方便日后审计。

如果你的仓库没有任何 pull_request_target 工作流，清单的第一步就会告诉你这个好消息——那也值得确认一次，因为“确认没有”和“以为没有”是两件完全不同的事。12 月 2 日这个日期不会再推迟一次（它本身就是从 11 月 2 日推迟来的），提前半小时自查，是这轮变化里性价比最高的动作。

附：pull_request 与 pull_request_target 到底差在哪

很多人在这次变化之前并没有分清这两个触发器，借这个机会把区别说清楚，对日后写工作流也有用。pull_request 事件在合并提交的上下文中运行，也就是 fork 那边提过来的代码版本，它能看到 PR 的代码，但拿不到目标仓库的密钥，也拿不到目标仓库的写入权限；正因为拿不到，它才是执行不可信代码的安全选择。pull_request_target 则相反：它在目标仓库默认分支的上下文中运行，工作流文件本身取自目标仓库而不是 fork，运行身份拥有仓库密钥和配置好的权限；正因为它有权，它才必须被当作特权流程对待。

这个区别带来一条非常实用的判断标准：凡是会检出 PR 代码并执行其中内容的步骤——运行测试脚本、执行构建脚本、解析配置文件、运行 PR 里自带的工具——都不应该出现在 pull_request_target 工作流里，或者必须先经过严格的隔离与审查。反过来，凡是只需要 PR 元数据（标题、编号、作者、标签）而不执行 PR 代码的步骤，比如发表格式化评论、打标签、触发下游部署，才是 pull_request_target 的合理用途。把这条标准贴在团队的工作流评审清单里，以后新增工作流时选错触发器的概率会大幅下降。

还有一个细节值得单独提醒：pull_request_target 的工作流文件取自目标仓库，这意味着外部贡献者无法通过改 PR 里的工作流文件来改变特权流程的行为——这是它相对安全的一面；但它执行 PR 代码的那一刻，这层保护就失效了。所以审计时不要只看工作流文件本身，还要看它检出了什么、执行了什么。一个只看“工作流文件在目标仓库，很安全”就放行的判断，是不完整的。

给组织管理员的一句话：别在组织层一放了之

如果你管理的是一个组织或企业账号， temptation 最大的操作是在组织层面统一放行 pull_request_target，让所有仓库恢复原状。这个操作确实能立刻消除所有失败，但它也把 GitHub 替你上的默认保护一次性拆光，而且组织里每个仓库的维护者都不会再收到任何提醒——风险被隐藏了，而不是被解决了。

更合理的做法是分层处理：组织层面保持默认阻止，只对那些经过评审、确实需要且已收紧权限的工作流做定向放行；同时把 Insights 的检查变成例行动作，比如每月看一次评估警告，或者在新增公开仓库时顺手检查触发器。组织层面的策略应该是“默认安全、例外透明”，而不是“默认放行、例外无人知晓”。这轮变化给你的真正礼物不是一道新规则，而是一次免费的全面审计机会——用它把过去几年攒下的特权工作流清理一遍，12 月 2 日之后，你的组织会比之前安全得多。

落地前，先按角色过一遍检查清单

同一条规则，落在不同人手里要做的事完全不同。仓库维护者先做三件事：第一，打开仓库的 Actions 设置，确认哪些工作流用了 pull_request_target，以及它们各自的触发条件是只响应拉取请求，还是同时响应其他事件；第二，对照 Insights 里评估模式标出的警告，把“会被拦”的工作流列成清单，而不是凭印象猜；第三，给每一条清单项定一个处置：能改触发器的改触发器，能拆步骤的拆步骤，实在改不动的再走定向放行。清单做完之前，不要急着在组织层统一放行——组织层一旦放行，等于替所有仓库做了决定，事后很难再收回。

组织管理员的重点则是策略的覆盖范围。先确认组织里有没有已经生效的适用事件策略：默认规则明确不覆盖已有策略，所以“以为被默认保护了、其实走了旧策略”的仓库最危险。办法是抽查几个公开仓库的实际生效策略，而不是只看组织层的开关状态。其次是时间窗口的管理：两次褐断分别落在 11 月 9 日和 11 月 16 日的 16:00–18:00 UTC，换算成北京时间是次日凌晨 00:00–02:00，正好是国内团队的深夜。值班安排上要有人在窗口内盯着失败运行的报错，确认被拦的是预期内的尝试，而不是某个关键工作流被误伤；窗口结束后也要复核一次，因为窗口过后系统会回到评估模式，不会自动告诉你哪些运行曾经被拦过。

普通贡献者的视角最容易被忽略。外部贡献者提拉取请求时，如果仓库的自动化突然不再运行，第一反应往往是“我的请求是不是有问题”，而不是“仓库策略变了”。维护者可以在贡献指南里加一句话，说明公开仓库默认阻止 pull_request_target、自动化需要维护者侧的放行或改触发器，让贡献者不用反复试错。同样，依赖机器人做自动标注、自动回复的仓库，也要提前检查机器人工作流是不是走了 pull_request_target——这类“静默助手”一旦被拦，不会有人立即发现，缺失的标注和提醒会在几周后才以混乱的协作状态暴露出来。把这些边缘情况提前想一遍，12 月 2 日就只是一次平静的切换，而不是一场救火。