文章总结： 本文详细分析了GitHub的PwnRequest供应链攻击漏洞，指出当pullrequesttarget触发器与actions/checkout结合时，黑客可通过PR注入恶意代码获取高权限。GitHub在actions/checkoutv7中新增拦截机制，默认阻止拉取Fork仓库的危险代码。文章建议开发者避免使用pullrequesttarget、实施最小权限原则并隔离不可信代码以防范此类攻击。 综合评分： 85 文章分类： 漏洞分析,供应链安全,WEB安全,安全开发,解决方案

黑客如何用一个 PR 掏空你的代码库？一文看懂 Pwn Request 提权漏洞与防御

原创

Kit Chung Kit Chung

安全圈动向

2026年6月25日 08:03 广东

在小说阅读器读本章

去阅读

摘要：今天咱们来扒一扒近期搅动开源圈的 Pwn Request 攻击链，看看 GitHub 刚刚更新的 actions/checkout v7 究竟修补了怎样的致命漏洞，以及你的项目到底该如何避坑。

大家好！最近搞 CI/CD 和开源项目维护的同学，可能已经注意到 GitHub 的一个重磅更新。就在前几天（2026年6月18日），GitHub 官方紧急更新了 actions/checkout 核心组件，并且会在 7 月 16 日将这个补丁反向移植到所有主流版本。

他们这次的目标非常明确：一刀切断近期极其泛滥的 “Pwn Request” 软件供应链攻击链。

很多开发者可能还没意识到问题的严重性。最近几个月，大名鼎鼎的 Nx 构建系统（s1ngularity 攻击活动）、PostHog、TanStack 甚至知名 Emacs 插件包，全都在这个坑里栽了跟头。

今天，我就带大家深挖一下，这究竟是个什么神仙漏洞？黑客是怎么用一个区区的 PR（Pull Request）把老底看穿的？以及 GitHub 这次的新规，对咱们日常写 CI/CD 脚本会有什么具体影响。

☠️ 致命陷阱：当 pull_request_target 遇见陌生代码

要懂这次更新的含金量，咱们得先搞懂 Pwn Request 漏洞的底层逻辑。

我们平时写 GitHub Actions，最常用的触发器是 pull_request。但它有个限制：如果是陌生人（Fork 仓库）提的 PR，这个流水的权限会被阉割，拿不到仓库的 Secrets，GITHUB_TOKEN 也只有只读权限。这是为了防止别人写个恶意脚本，一提交就把你的服务器给炸了。

但有时候我们需要给 PR 自动打标签、评论，或者访问特定元数据，这就需要高权限。于是 GitHub 搞出了个 pull_request_target 触发器。

这玩意儿是个双刃剑。 它的工作机制是：

1. 无需人工审批

   ，PR 一开或者一更新就自动跑。

2. 运行上下文是基准仓库（Base Repository）的默认分支。

3. 最致命的一点：

   它可以拿到高权限的 GITHUB_TOKEN（读写权限）并能直接访问核心 Secrets！

官方本来设计它是用来跑你自己仓库里绝对可信的自动化脚本的。但是，很多开发者图省事，或者对机制不熟悉，写出了下面这种“自杀式”代码：

on:
  pull_request_target: # ⚠️ 触发高权限环境

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          ref: ${{ github.event.pull_request.head.sha }} # ❌ 致命错误：检出了黑客的不可信代码！
      - run: npm install # 💥 执行了黑客注入的恶意 preinstall 脚本

发现盲点了吗？ 当高权限的运行环境（pull_request_target），遇上了黑客伪造的、未经审查的代码（actions/checkout 拉取了 Fork PR 的代码）。黑客只需要在他们的 package.json 里植入一个恶意的 postinstall 脚本，就能在你的高权限 Runner 里为所欲为。

这就是大名鼎鼎的 Pwn Request 攻击。 你的 Secrets、你的发版权限，甚至你的底层缓存，瞬间全部沦陷。

🛡️ 官方雷霆手段：actions/checkout 强行阻断

因为太多人踩坑，GitHub 终于坐不住了。这次他们不光是写文档警告，而是直接在官方最底层的组件 actions/checkout v7 里加了硬编码的拦截机制。

核心技术路径如下：

在新规则下，如果触发器是 pull_request_target 或 workflow_run，且这个 PR 来自一个 Fork 仓库，actions/checkout 会默认拒绝拉取代码并直接报错退出，前提是满足以下任意一个匹配条件：

• repository

  参数解析为这个 Fork PR 的代码库。

• ref

  参数匹配了 refs/pull/number/head 或 refs/pull/number/merge。

• ref

  参数解析出来的 SHA 刚好是这个 Fork PR 的 head 或者 merge 提交。

说白了，官方在底层把你“拉取不可信代码”的动作给物理切断了。 只要是来自 Fork 的危险代码，统统拦截在门外。

💡 后门开关（极不推荐）：

当然，如果你是高端玩家，确信自己后续的步骤绝对安全（比如纯粹用沙箱做静态代码扫描），GitHub 也留了后门。你可以通过设置 allow-unsafe-pr-checkout: true 来强行关闭这个保护。但我奉劝大家：没有金刚钻，别揽瓷器活，千万别手贱去开这个 flag。

⚠️ 安全护栏并非万灵药：这几个盲区依然存在

可能有的同学看到这儿，长舒一口气：“官方兜底了，那我是不是可以躺平了？”

大错特错！ 正如安全公司 Socket 指出的，这仅仅是个安全护栏（Guardrail），治标不治本。大家一定要清楚它的局限性：

1. 只保护官方 Action：

   如果你自己在脚本里手敲 git clone，或者用 gh pr checkout 命令行去拉代码，这个补丁根本救不了你。

2. 不防第三方恶意库：

   如果你把 repository: 指向了一个毫无关联的第三方恶意仓库，拦截机制也不会生效。

3. 其他触发器依然高危：

   比如 issue_comment 触发器，在特定条件下同样能被武器化，这也不在本次更新的保护范围内。

只要你在高特权事件中执行了不可信代码，Pwn Request 的风险就永远存在。

🛠️ 我们该如何自救？给开发者的 3 条铁律

作为一线开发者，防御这类供应链投毒其实并不难，关键在于“权限控制”这根弦要时刻绷紧：

• 如非必要，绝不用 pull_request_target：

  检查你所有的 workflow 脚本。如果不需要读写代码库或者访问敏感 Secrets，立刻降级回 pull_request。

• 践行最小权限原则：

  在工作流文件中显式声明 permissions 块。不要给 Runner 默认的全局读写权限。

• 隔离不可信输入：

  永远不要直接运行未经审核的代码。如果要自动化构建测试 Fork PR，确保运行在完全沙盒化、无权访问任何 Secrets 的独立环境中。

安全无小事，尤其是 CI/CD 这种直接接触核心资产的基建。今天下班前，赶紧花五分钟去自查一下公司的 GitHub Actions 配置文件吧！

你之前在写 CI/CD 脚本时遇到过权限管理的坑吗？或者对这次 GitHub 的更新有什么看法？欢迎在评论区和我交流！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈动向 Kit Chung Kit Chung《黑客如何用一个 PR 掏空你的代码库？一文看懂 Pwn Request 提权漏洞与防御》