全球热点解读 · 阅读档案

2026-11-02 2 浏览公开

pull_request_target 将于 12 月 2 日默认被阻止

Q: 这篇文章和哪些AI专题相关？

它适合放在AI日报、Agent工作流、AI工具专题里阅读。 关联原因：这篇内容命中「热点解读」等主题信号。；这篇内容命中「工作流」等主题信号。；这篇内容来自该专题长期覆盖的栏目。

GitHub Actions 将于 2026 年 12 月 2 日起在公共仓库默认阻止 pull_request_target 事件，除非适用的 Actions 事件策略显式允许；私有/内部仓库和 GitHub Enterprise Server 不受影响。

全球热点解读约 9 分钟读完公开原文 2026-11-02 23:14:46

原贴

查看原文

作者：Allison 来源站点：github.blog 原贴时间： 2026-11-02 23:14:46

原文

Starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories, unless an applicable Actions event policy explicitly allows them. Enforcement was previously scheduled for November 2, 2026. GitHub introduced this default rule through workflow execution protections. The rule initially runs in evaluate mode, so you can see which workflow runs it would block before enforcement begins. Private and internal repositories aren’t affected. pull_request_target runs in the context of the base repository and can access its secrets. If a workflow executes untrusted code from a fork, that code could compromise your pipeline or steal secrets. The default rule helps reduce this risk while letting you explicitly allow workflows that depend on the trigger. Before permanent enforcement begins on December 2, 2026, we’ll temporarily enforce the default protection during two scheduled brownouts. These windows will help you identify affected workflows and update your policies before enforcement becomes permanent. During each window, pull_request_target workflow attempts blocked by the default rule in affected public repositories will create failed runs with an error annotation; the workflows won’t execute. After each window, the default rule will return to evaluate mode, allowing workflows to run with warnings. Private and internal repositories aren’t affected. Before the first brownout on November 9, use Insights to see which workflow runs the rule would block. From there, you have two options: Keep the default rule in place to block pull_request_target . Explicitly allow pull_request_target in an applicable Actions event policy if your workflows depend on it. Use workflow file targeting to allow specific workflows. See how to control workflow execution to configure your policies. This change applies to public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud, not GitHub Enterprise Server.

中文翻译

从 2026 年 12 月 2 日开始，GitHub Actions 将在所有公共仓库中默认阻止 pull_request_target 事件，除非适用的 Actions 事件策略明确允许它们。强制执行原定于 2026 年 11 月 2 日。GitHub 通过工作流执行保护引入了此默认规则。该规则最初以评估模式运行，因此你可以在强制执行开始前看到它将会阻止哪些工作流运行。私有仓库和内部仓库不受影响。pull_request_target 在基础仓库的上下文中运行，并且可以访问其机密。如果工作流执行来自复刻的不可信代码，该代码可能会危及你的流水线或窃取机密。默认规则有助于降低此风险，同时允许你明确允许依赖该触发器的工作流。在 2026 年 12 月 2 日永久强制执行开始之前，我们将在两个计划的 brownout 期间临时强制执行默认保护。这些窗口将帮助你在强制执行变为永久之前识别受影响的工作流并更新你的策略。在每个窗口期间，受影响公共仓库中被默认规则阻止的 pull_request_target 工作流尝试将创建带有错误注释的失败运行；这些工作流将不会执行。每个窗口之后，默认规则将回到评估模式，允许工作流运行并给出警告。私有仓库和内部仓库不受影响。在 11 月 9 日第一次 brownout 之前，使用 Insights 查看该规则将会阻止哪些工作流运行。从那里，你有两个选项：保留默认规则以阻止 pull_request_target。如果你的工作流依赖它，请在适用的 Actions 事件策略中明确允许 pull_request_target。使用工作流文件定向以允许特定工作流。请参阅如何控制工作流执行以配置你的策略。此更改适用于 GitHub Free、GitHub Team 和 GitHub Enterprise Cloud 上的公共仓库，不适用于 GitHub Enterprise Server。

核心信息

GitHub Actions 将于 2026 年 12 月 2 日起在公共仓库默认阻止 pull_request_target 事件，除非适用的 Actions 事件策略显式允许；私有/内部仓库和 GitHub Enterprise Server 不受影响。

GitHub Actions 将于 2026 年 12 月 2 日起在公共仓库默认阻止 pull_request_target 事件，除非适用的 Actions 事件策略显式允许；私有/内部仓库和 GitHub Enterprise Server 不受影响。
原贴提到：Starting December 2, 2026, GitHub Actions will block pull_request_target
来源：github.blog

详细解读

这是什么信号：GitHub Actions 把 pull_request_target 从“默认可运行”改为“默认阻止”，生效日为 2026 年 12 月 2 日；原定 11 月 2 日，现延后。规则先以评估模式观察，再通过两次 brownout 临时强制，最后永久执行。它只覆盖公共仓库，私有/内部仓库和 GitHub Enterprise Server 不在范围内。

为什么重要：pull_request_target 在基础仓库上下文运行并可访问机密。若工作流执行来自 fork 的不可信代码，可能污染流水线或窃取机密。默认阻断把安全基线抬高，但会直接影响依赖该触发器的公共仓库 CI，尤其是开源维护者和平台团队。

对谁有价值：公共仓库管理员、开源维护者、DevOps/平台工程、安全团队，以及使用 GitHub Free、Team、Enterprise Cloud 且用 fork PR 工作流的团队。私有/内部仓库团队和 GitHub Enterprise Server 用户暂不受此变更影响，但仍应理解该触发器的风险边界。

可以怎么行动：在 11 月 9 日第一次 brownout 前，用 Insights 查看规则会阻止哪些工作流运行；盘点所有使用 pull_request_target 的工作流及其机密访问；决定保留默认阻止，或通过适用的 Actions 事件策略显式允许。若只需放行少数流程，使用 workflow file targeting 限定具体工作流，避免大范围放开。利用评估模式和 brownout 窗口验证失败表现并更新策略。

风险或限制：brownout 期间被阻止的尝试会产生失败运行和错误注释，工作流不会执行；窗口结束后回到评估模式，只给警告，因此不能把警告当作已安全。显式允许虽然恢复流程，但若工作流仍执行 fork 的不可信代码，机密泄露和流水线被污染的风险仍在。策略配置不当可能误伤关键 CI，过度放行又会削弱默认保护。

信息差价值

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《pull_request_target 将于 12 月 2 日默认被阻止》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

参考来源

Allison 原帖

TOPIC HUBS

延伸专题

AI日报 AI日报：每日AI信号、工具动态与行动判断

这篇内容命中「热点解读」等主题信号。

Agent工作流 Agent工作流：智能体、AI编程与自动化协作

这篇内容命中「工作流」等主题信号。

AI工具 AI工具：模型、插件、自动化与实战场景

这篇内容来自该专题长期覆盖的栏目。

AI SUMMARY

这篇文章回答了什么