Red Hat 的 npm 命名空间遭供应链攻击
ZDNET AI··作者 Steven Vaughan-Nichols
关键信息
Aikido 表示，共有 32 个软件包的 96 个版本被入侵，周下载量合计达到 116,991 次。报告称，恶意代码通过 npm 的 preinstall 钩子执行，并用高度混淆的加载器窃取 npm、GitHub、AWS、SSH、Kubernetes、Vault 以及其他 CI/CD 来源中的密钥。
资讯摘要
Red Hat 遭遇了一起影响其 @redhat-cloud-services 命名空间中数十个 JavaScript 软件包的 npm 供应链入侵。根据 Red Hat 安全团队和外部研究人员的说法，攻击者利用一个被盗用的 GitHub 账户，向 Red Hat GitHub 组织内维护的软件包注入了恶意代码。受影响的软件包是前端库，会在 Red Hat 产品构建流程中被编译并打包进容器镜像。安全研究人员称，此次攻击共污染了 32 个软件包的 96 个版本，合计每周下载量达到 116,991 次。恶意代码通过 npm 的 preinstall 钩子植入，因此当开发者或构建系统对受影响软件包执行 npm install 时，恶意逻辑会自动运行。Microsoft 威胁情报团队将载荷描述为一个经过混淆的加载器，它会下载并执行第二阶段脚本，用于窃取密钥。
研究人员将这次行动与 Mini Shai-Hulud 的行为联系起来，也有报告把该载荷称为名为 Miasma 的新变种，强调它具有更强的混淆能力和多阶段加载设计。这个类似蠕虫的组件不只是偷取凭据；如果它发现了发布权限，就会把同样的恶意 preinstall 负载重新发布到更多软件包中，从而让每个受害者都变成新的攻击者。独立分析还指出，攻击路径可能与 RedHatInsights/javascript-clients 仓库相关的 GitHub Actions OIDC 令牌被滥用有关。被执行的代码会搜集 GitHub 密钥和令牌、SSH 密钥、AWS、GCP 和 Azure 凭据、Kubernetes 令牌、HashiCorp Vault 数据，以及存放在环境变量或配置文件中的其他 CI/CD 密钥。安全厂商警告称，任何在开发者工作站或自动化环境中安装过受影响版本的人，都应默认相关密钥可能已经泄露。
资讯正文
关注 ZDNET：将我们添加为您在 Google 上的首选来源。ZDNET 的要点：红帽成为 npm 安全漏洞的受害者。该公司已移除受影响的软件包。请检查你是否使用了 @redhat-cloud-services npm 命名空间。
npm 仓库命名空间——也就是 JavaScript 运行时环境 Node.js 的包管理器——因安全漏洞而臭名昭著。如今，刚刚与 IBM 一起宣布了 Project Lightwell 的红帽，也就是一个旨在发现并修复开源软件漏洞的 AI 驱动项目，自己也遇到了 npm 问题。另：开源安全一团糟——IBM 和红帽押下 50 亿美元和 2 万名工程师，赌能把它修好。
该公司 @redhat-cloud-services 命名空间中的数十个 JavaScript 软件包被植入了后门，恶意软件会窃取红帽开发者以及持续集成和持续交付（CI/CD）系统中的密钥。安全研究公司 Aikido 报告称，这个命名空间“已被一个窃取凭证的蠕虫攻陷。总共有 32 个软件包中的 96 个版本受到影响，累计每周下载量为 116,991 次。”根据红帽安全团队的说法，有人利用一个被攻陷的 GitHub 账户，将恶意代码注入到红帽某个 GitHub 组织维护的软件包中。受影响的软件包是前端库，会在红帽产品构建过程中被编译并捆绑进容器镜像。
到底发生了什么？看起来恶意软件是通过 npm 的 preinstall 钩子被加入的：每当开发者或构建系统对受影响的软件包执行“npm install”时，恶意代码就会自动运行。根据微软威胁情报团队的说法，每个被攻陷的软件包都添加了一个 preinstall 脚本，该脚本会运行一个臃肿、经过高度混淆的 index.js 加载器，然后下载并执行一个负载，旨在从 npm、GitHub、AWS、SSH 以及其他环境中搜刮密钥。
研究人员很快将这次攻击与基于 Mini Shai-Hulud 恶意软件的更大规模行动联系起来；这种会在 npm 中传播的蠕虫曾用于此前的供应链事件。在红帽这起案例中，多份报告将该负载称为一个被命名为 Miasma 的新变种，它保留了 Mini Shai-Hulud 的自我传播行为，同时加入了更多混淆和多阶段加载设计。
这种蠕虫做的不只是窃取凭证。一旦它在一台有权访问其他 npm 软件包的机器上运行，它就会识别当前用户能够发布的每一个软件包，并用同样的恶意 preinstall 载荷重新发布它们。也就是说，每个受害者都会变成新的攻击者。安全公司表示，正是这种“可蠕虫化”行为，使得与红帽相关的命名空间能如此迅速地被污染。有些估计认为，超过 30 个软件包是在几分钟内被植入后门的。另：Red Hat Desktop vs. Fedora Hummingbird：哪条 AI 开发 Linux 路线更适合你？
虽然红帽尚未发布详细的事后分析，但独立分析指出，被攻陷的 GitHub 基础设施是最初的入侵入口。
Semgrep 和其他安全研究公司报告称，恶意的 Red Hat 范围包是使用与 RedHatInsights/javascript-clients 仓库相关联的 GitHub Actions OpenID Connect（OIDC）令牌推送上去的。入侵后，攻击者向多个包和版本中注入了 preinstall 钩子，而且往往没有在公开源代码仓库中留下任何对应的变更。这是构建流水线被攻破的一个典型标志。执行的代码会扫描并尝试外传以下内容：GitHub Actions 密钥和访问令牌、GitHub SSH 密钥和个人访问令牌、AWS、GCP 和 Azure 云凭证、Kubernetes 配置和令牌、HashiCorp Vault 令牌以及其他密钥管理器数据、npm 和 CircleCI 令牌，以及存储在环境变量或配置文件中的其他 CI/CD 密钥。
安全厂商警告称，任何在开发者工作站、构建代理或 CI 运行器上安装了受影响版本的人，都应当假定该环境中所有可访问的令牌和凭证现在可能已经落入攻击者手中。对于开发者来说，多家公司给出的建议非常明确：立即轮换密钥；审计 GitHub 和云端活动，查找可疑访问；基于已知良好的基线重建任何可能被污染的环境。
Red Hat 告诉我：“我们已立即启动调查，并将这些包从 npm registry 中移除。这些包严格限于内部开发，恶意代码从未通过 console.redhat.com 系统发布给客户使用。虽然我们的调查仍在进行中，但我们尚未发现对客户或合作伙伴环境，或 Red Hat 生产系统的任何影响。”简而言之，这本来可能更糟。
此前，在关于 npm 供应链攻击的更一般性指导中，Red Hat Product Security 表示，其产品高度依赖严格的版本锁定和内部镜像，并且此前被攻破的 npm 包并未被纳入受支持的 Red Hat 软件中。
然而，在最近这起事件之后，安全研究人员正敦促各组织不要因为自己使用 Red Hat 相关产品就想当然地认为安全无虞。他们认为，任何接触过这些带后门包的构建或开发工作流都应被视为可能已遭入侵。现在该做什么？虽然 Red Hat 向所有人保证坏代码并未进入公开环境，但我仍然保持谨慎。如果你依赖 Red Hat 的云服务工具，或者曾将 @redhat-cloud-services 包拉入你的构建流程，我建议你扫描依赖树，查找受影响版本，阻止已知恶意的发布，并在必要时降级到或替换为可信构建版本。
与此同时，我会假定任何安装过这些包的环境都可能已泄露其密钥，并轮换所有相关凭证，例如 GitHub PAT、SSH 密钥、云服务提供商 API 密钥以及 CI 令牌。
从长远来看，Red Hat 的 npm 事件再次表明，npm 仓库并没有那么值得信任。即便像 Linux 和云领域这样重量级的厂商如今也已被证明会受到可蠕虫传播的 npm 恶意软件影响，这就给 npm 的维护者以及主要软件供应商带来了越来越大的压力，要求他们就各自软件包的来源和安全性提供更强有力的保障。换句话说，虽然 Red Hat 这次确实有些尴尬，但这也凸显出 Project Lightwell 以及类似项目有多么重要，例如 Chainguard 为寻找提升所有人开源安全性的方法所做的努力。
来源与参考
收录于 2026-06-04