GitHub Actions漏洞攻击来袭，安全意识强的企业也难幸免

研究人员警告称 ，洞攻在GitHub上托管代码仓库的击袭开发者仍在不安全地使用GitHub Actions，设置了可能被利用来提取敏感认证令牌的安全自动工作流。

与GitHub Actions工作流相关的意识也难安全风险并非新鲜事 ，然而，强的企业Sysdig的幸免研究人员已经识别出了数十个存在漏洞的项目 ，其中包括来自知名且具备安全意识的洞攻高调企业MITRE和Splunk的项目
。

Sysdig的击袭研究人员在本周的源码下载一份报告中写道：“这些工作流往往包含机密信息，如API密钥或凭证 ，安全这些信息可能被用于提升权限或在仓库内横向移动 ，意识也难甚至如果被窃取 ，强的企业还可能在整个企业内横向移动 。幸免尽管已有工具、洞攻技术和公开研究详细说明了如何识别和利用这些漏洞，击袭但许多开源项目的安全整体成熟度仍然令人担忧地低。”

Sysdig调查的一个攻击向量涉及在pull_request_target事件上触发的GitHub Actions工作流
。据Sysdig称 ，这个攻击向量会泄露机密和一个具有仓库写入权限的GitHub令牌 ，建站模板并且，由于该操作在基础仓库而非触发拉取请求的分支中执行 ，因此如果未设置防护措施 ，它可能导致整个仓库被接管
。

“在分析结果时，我们对发现的易受攻击的pull_request_target工作流数量感到惊讶 ，”研究人员写道
，“你可能会认为这些仅限于不知名或不活跃的仓库  ，但事实并非如此 ，我们发现，几个拥有数万颗星的高调项目仍在使用不安全的云计算配置。”

GitHub Actions攻击成为现实

GitHub Actions是一种CI/CD(持续集成和持续交付)服务 ，它使开发者能够通过设置在指定事件(如新代码提交到仓库)发生时触发的工作流来自动化软件构建和测试 ，这些工作流被称为Actions，是打包在.yml文件中的指令 ，通常在GitHub的基础设施上的虚拟容器中执行 ，并返回编译后的二进制文件
、测试结果 、日志等。源码库

为了操作 ，工作流必须能够克隆仓库并对其执行操作，为此，系统会在本地.git文件夹中创建并保存一个临时的GITHUB_TOKEN，以允许执行经过认证的git命令 ，这个令牌本应是短暂的 ，并且应该在工作流完成后停止工作 。

多年来，研究人员已经展示了GitHub Actions如何被滥用 ，包括通过域名拼写错误(typosquatting)、未清除机密信息的构建产物以及在工作流之间转移时的服务器租用产物污染等方式，并且 ，这些不仅仅是理论上的攻击。去年12月
，攻击者通过GitHub Actions脚本注入漏洞，成功入侵了GitHub上Ultralytics YOLO AI库的构建过程，这导致被污染的库版本被上传到了PyPI仓库。

危险的拉取请求工作流触发器

当开发者从他们分叉的代码仓库版本提交新代码回主仓库以供包含时，就会发生拉取请求，然后，免费模板项目的开发者会对拉取请求进行审查和评论 ，之后才会接受请求进行提交。

在GitHub Actions中，pull_request触发器会促使工作流在分叉分支的上下文中执行，创建一个仅具有主仓库读取权限的GITHUB_TOKEN ，然而，pull_request_target触发器会促使工作流在目标分支(通常是主分支)的上下文中执行，具有对仓库中存储的所有机密信息的完全访问权限 ，以及一个具有读取和写入权限的GITHUB_TOKEN。开发者在使用此触发器时需要谨慎，特别是对于那些尝试从拉取请求中检出
、运行或构建代码的工作流，因为代码可能是恶意的 ，并且将获得工作流的机密信息 、令牌和权限  。

GitHub Actions文档实际上已经警告了这种危险行为，Sysdig发现，许多开发者仍然以这种方式使用它来测试拉取请求中的代码更改。

Sysdig发现的一个例子是Spotipy
，这是一个用于与Spotify Web API交互的开源Python库 ，该项目在GitHub上相当受欢迎，拥有超过5000颗星和近1000个分支。

Spotipy的工作流integration_tests.yml在pull_request_target上触发，在从拉取请求的仓库检出代码之前，执行pip install(Python包安装器)命令以安装依赖项
。

如果攻击者在他们的仓库中放置了一个恶意的setup.py文件
，他们就可以在工作流的pip install操作期间执行恶意代码。研究人员的概念验证部署了一个memdump.py脚本，该脚本从内存中提取了凭证
，包括SPOTIPY_CLIENT_ID、SPOTIPY_CLIENT_SECRET以及具有读写权限的特权GITHUB_TOKEN。

研究人员还在他们的恶意代码中添加了sleep命令 ，以延长工作流的执行时间 ，从而延长GITHUB_TOKEN的有效性，以便在它过期之前被滥用，该漏洞被评为严重级别，并被分配了CVE-2025-47928。

MITRE和Splunk修正仓库配置错误

另一个值得注意的例子是MITRE CAR(网络分析仓库)，它讽刺地托管了一个分析集合，包括检测规则和逻辑 ，旨在帮助安全团队识别映射到MITRE ATT&CK框架的对手行为。

这个仓库包含一个类似于Spotipy的工作流 ，它在pull_request_target上触发，以从拉取请求中检出代码并发出pip install -r ./scripts/requirements.txt命令 。由于requirements.txt文件是检出代码的一部分 ，因此它完全处于潜在攻击者的控制之下  。

“再次，我们成功窃取了默认的高特权GITHUB_TOKEN和其他机密信息
，最终在仓库内获得了提升的权限 ，”Sysdig团队表示，“在向MITRE报告该漏洞后，它得到了确认并迅速被MITRE团队修复 。”

第三个例子是Splunk的一个名为security_content的仓库
 ，它有一个类似的可滥用工作流，在这种情况下，提取的GITHUB_TOKEN仅限于读取权限，但研究人员设法从仓库中提取了其他凭证 ，名为APPINSPECTUSERNAME和APPINSPECTPASSWORD，该问题在报告后得到了修复，但提取的凭证的性质和敏感性尚不清楚。

缓解措施

有几种方法可以缓解这些配置错误风险，首先，如果可能的话 ，应避免使用pull_request_target ，并且在不完全理解其安全影响和风险的情况下不要使用
，以这种方式执行的工作流不应检出不受信任的代码 。

如果仍然需要特权工作流 ，那么应首先在不特权的工作流中执行不安全任务，如检出和运行不安全代码，然后将验证后的结果传递给特权工作流，这被称为工作流分割，是GitHub推荐的一种策略。

其次，GITHUB_TOKEN的权限应配置为只读，正如Splunk仓库中的情况一样，这将无法保护工作流执行过程中暴露的其他机密信息 ，但将防止攻击者获得对主仓库的写入权限 。

“一种可以考虑的缓解措施是将工作流配置为仅在拉取请求被分配了特定标签时才运行，这实际上需要具有仓库写入权限的维护者进行手动审查，”Sysdig研究人员建议道，“由于外部贡献者无法分配标签，因此这确保了拉取请求在手动审查后才会触发工作流。”