我配了三年 GitHub Actions，今天才发现 pull_request_target 这个漏洞一直在偷我的代码——actions/checkout v7 把这件事彻底堵上了

你可能觉得自己的仓库没什么值得偷的。但”pwn request”攻击从来不挑目标——攻击者要的不是你的代码，是你的基础设施。2026年6月，一个叫 TeamPCP 的黑客组织利用这个漏洞，一口气绑定了 170 个 npm 包，其中就包含了 TanStack Router 生态。更尴尬的是，在另一场与 pwn request 无关的攻击里，GitHub 自己的约 3800 个内部仓库源代码也被偷了。

这就是 pwn request 攻击的现状。GitHub 在 2024 年 6 月发布了 actions/checkout v7，2026 年 7 月把这个安全机制回溯到了所有浮动主版本标签的 workflow 上。从今天开始，默认安全成了 GitHub Actions 的新常态。

漏洞是怎么成立的

要理解 v7 在堵什么，先要理解这个漏洞怎么工作的。

GitHub Actions 有两个触发器看起来很像：pull_request 和 pull_request_target。前者不会给 workflow 访问 API 密钥、服务 Token 这类敏感信息的权限——这对外部 Fork 的代码是保护。但这也导致某些自动化流程没法正常运行，所以部分开发者改用了 pull_request_target，因为它会授予完整权限。

问题来了：当 pull_request_target 配合 actions/checkout 拉取外部 Fork 的 PR 代码时，攻击者提交的 PR 就以你的 workflow 完整权限执行了。你的 secrets、npm token、部署权限，全归攻击者了。

这不是新漏洞。安全社区早就知道这个风险。但因为修复起来麻烦（涉及工作流重构），大量仓库一直敞着门。

v7 做了什么

actions/checkout v7 的策略很简单：在 pull_request_target 或 workflow_run 事件触发时，直接终止试图拉取外部 Fork PR 代码的工作流。

这意味着什么？不管你的 workflow 怎么配置，只要用 v7 或更新的版本，系统就会自动拦截高风险操作。

如果你真的需要这个能力（某些合法场景确实需要），GitHub 要求你显式声明：

- uses: actions/checkout@v4
  with:
    allow-unsafe-pr-checkout: true

注意是 v4 而不是 v7——v7 是最新稳定版。这里的关键词是”显式”：安全责任从平台的默认值转移到了开发者自己。你必须主动选择风险，而不是默认就有风险。

谁会受影响

会自动获得新安全默认的工作流：

• 固定到浮动主版本标签的，如 actions/checkout@v4

不受回溯影响、需手动升级的：

• 固定到特定 SHA 的
• 固定到次版本号或补丁版本的

固定到 SHA 的工作流不受回溯影响，所以如果你用的是 actions/checkout@sha1a2b3c... 这样的写法，需要通过 Dependabot 或手动流程升级。

真实案例：一个170个npm包被绑的故事

2026年5月，TeamPCP 黑客组织发动了一轮供应链攻击。他们的手段之一就是 pwn request——向开源仓库提交包含恶意代码的 PR，等待仓库维护者合并，workflow 就以完整权限执行，趁机窃取 npm token 或注入恶意依赖。

这轮攻击绑定了 170 个 npm 包。讽刺的是，受影响最小的仓库恰恰是那些早已弃用 pull_request_target 的项目。

你的仓库在用 pull_request_target 吗？GitHub 官方建议是：能不用就别用。如果必须用，务必限制 checkout 范围，并尽快迁移到 v7+。

怎么检查自己有没有中招

在仓库的 Actions 标签页里搜索包含 pull_request_target 的 workflow 文件：

grep -r "pull_request_target" .github/workflows/

如果找到了，检查对应的 checkout step 是否显式声明了安全意图。没有的话，要么删掉 pull_request_target，要么升级 checkout 版本并加上 allow-unsafe-pr-checkout。

给工程团队的检查清单

1. 确认所有 workflow 使用 actions/checkout 的浮动标签（@v4 或更高）
2. 搜索仓库内所有 pull_request_target 使用场景
3. 对于确实需要保留的，评估是否可以改用 pull_request + workflow_run 的替代方案
4. 需要保留的，加上 allow-unsafe-pr-checkout: true 并在注释里写清楚为什么
5. 将 Actions secrets 和 Environment secrets 审查一遍，移除不必要的权限
6. 开启 GitHub 的 Secret scanning 和 Dependabot security updates

总结

GitHub 用 7 年时间才把这个漏洞做成”默认安全”，中间经历了无数次供应链攻击。这个改变本身不算技术突破，但它代表了一种更成熟的安全理念：平台默认应该是安全的，而不是把安全责任全推给开发者。

作为前端工程团队，这是 2026 年下半年最值得做一次 workflow 审计的理由。你的 CI/CD 流程里，可能就躺着一个还没关的敞口。