文章总结： Orca安全团队揭露GitHubActions的pull_request_target触发器因配置不当引发供应链风险。该触发器拥有基础仓库高权限，若执行外部PR提交的不可信代码，可导致RCE、密钥窃取或仓库篡改。谷歌、微软等知名项目均存在此类隐患。建议避免在高权限上下文执行外部代码，审查工作流配置以防范供应链攻击。 综合评分： 82 文章分类： 供应链安全,漏洞分析,漏洞预警,安全建设

pull_request_target：一个被滥用的危险开关

幻泉之洲

2026年3月7日 10:30 北京

开源安全团队Orca揭露了一个由GitHub Actions工作流配置错误引发的供应链攻击风险。多个知名开源项目，包括谷歌、微软等巨头的仓库，都因为一个叫pull\_request\_target的触发器而暴露在远程代码执行（RCE）和数据窃取的危险之下。这篇文章将带你了解攻击是如何发生的。

拉取请求怎么就成了噩梦？

想象一下，一个外部开发者给你的开源项目提了个代码拉取请求（Pull Request）。你觉得没问题，CI/CD流水线会自动运行测试。但就在这个看似平常的环节，你的仓库可能已经沦陷了。

Orca安全研究团队发现，问题的核心在于一个叫pull_request_target的GitHub Actions事件触发器。这个触发器和更常见的pull_request触发器有着本质区别。pull_request运行时，使用的是fork分支的上下文，权限较低。但pull_request_target不同，它会在基础仓库的上下文中运行，这意味着它能直接访问仓库的机密信息（secrets），并且默认拥有GITHUB_TOKEN的读写权限。

这个触发器的本意是好的，用来安全地处理一些需要高权限的任务，比如给PR打标签、进行分类。

name: Labeler on: [pull_request_target]

jobs:   label:     runs-on: ubuntu-latest     permissions:       contents: read       pull-requests: write     steps:     – uses: actions/labeler@v4       with:         repo-token: “${{ secrets.GITHUB_TOKEN }}”

上面这个例子很常见，就是用PR来触发自动标签机器人。pull_request_target在这里是必须的，因为“打标签”这个动作需要有写权限来修改PR的元数据。

但问题就出在，如果工作流不仅仅是打标签，而是去执行了来自PR的、不受信任的代码，那么pull_request_target提供的所有高权限，都会成为攻击者的武器。

当CI/CD执行了恶意代码

漏洞的关键在于，这些被攻陷的工作流都犯了一个相同的错误：在拥有高权限的上下文中，检出了外部PR提交的代码并执行了它。

我们来看一个危险的例子：

name: Dangerous PR runner on:   pull_request_target:

jobs:   run-pr-code:     runs-on: ubuntu-latest     permissions:       contents: write       pull-requests: write     steps:       – uses: actions/checkout@v4         with:           ref: ${{ github.event.pull_request.head.sha }}       – name: Run script         run: |           scripts/run.sh

这个工作流用pull_request_target触发，配置了contents: write权限。接着，它通过github.event.pull_request.head.sha这个变量，直接检出了PR提交者的分支代码，然后执行了里面的scripts/run.sh脚本。

这下完了。原本只该对PR进行分类或验证的任务，现在毫无戒备地执行了一个外部贡献者提交的、任意内容的脚本。这个脚本运行在拥有基础仓库写权限的GitHub Runner上，攻击者现在可以为所欲为。

这个配置模式是许多漏洞的根源：用高权限（pull_request_target）去处理不可信的数据（外部PR代码）。

在分析中，Orca团队总结了几个反复出现的、危险的错误配置：

• 过于宽泛的令牌权限

  ：工作流直接赋予外部贡献者向仓库推送代码的能力。

• 机密信息泄露

  ：敏感的API密钥、令牌被内嵌在配置不当的工作流中，让攻击者轻松窃取。

• 自托管Runner被外部利用

  ：通过自动批准的错误配置，将功能强大的自托管云服务器暴露给外部用户使用。

• 遗留的粗粒度令牌

  ：许多在GitHub 2021年改进令牌细粒度权限控制前创建的老仓库，还在使用权限过大的旧令牌。

具体影响因项目而异，但根本风险都一样：让不受信任的代码，以过高的特权运行。

漏洞早已在现实中蔓延

这不是理论推演。在研究中，Orca团队发现多个出自名门的、不同组织的开源仓库都中了这招。

他们利用这些漏洞，成功做到了一些“危险动作”：

▲ 利用被攻陷的Github Actions Runner向main分支写入代码

▲ 利用被攻陷的Github Actions Runner操纵Pull Request

▲ 利用被攻陷的Github Actions Runner向组织级GitHub包仓库推送内容

有些漏洞暴露了敏感的API密钥；有些让我们能力直接向包括main在内的受信任分支推送代码；更有甚者，让我们得以滥用云端的后台资源。

说实话，看到谷歌、微软这样的公司也会在开源仓库里留下这种配置隐患，让人有点意外。这恰恰说明，pull_request_target的误用和CI/CD安全，是一个需要整个开发社区严肃对待的系统性问题。

单一的一个错误配置的流水线，通过一个看似无害的fork PR，就可能演变成一次完整的供应链攻击。

Orca表示，他们已通过负责任的披露程序，将发现报告给了受影响的组织。本文仅仅是第一部分。9月30日发布的第二部分，将带你进入真实事件的幕后，一步步复盘攻击链，看看那些微小的配置疏漏是如何被串联起来，造成灾难性后果的。

免责声明：

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

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

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

本文转载自：幻泉之洲 《pullrequesttarget：一个被滥用的危险开关》