Red Hat npm 包遭攻击：30 余个仓库投递云凭据窃取器
一场协调的 npm 供应链攻击云凭据盗窃活动击中了企业软件领域最知名的名字之一。未知攻击者入侵了 30 多个 Red Hat Cloud Services npm 包，手段是先劫持一名 Red Hat 员工的 GitHub 账号，再利用该访问权限推送恶意提交。这些包中嵌入的恶意软件被识别为 “Mini Shai‑Hulud” 变种，会在安装时自动执行，并立即开始窃取云凭据，包括 AWS、GCP 和 Azure 访问密钥，以及 SSH 密钥和 Kubernetes 配置文件。
此次事件的突出之处并非 npm 本身的弱点，而是攻击者的入侵入口：通过一个合法的、受信任的开发者身份。
Red Hat npm 包是如何被入侵的
攻击链始于一名 Red Hat 员工的名下 GitHub 账号被攻破。一旦进入该账号，攻击者便拥有了直接向与 Red Hat Cloud Services npm 包关联的仓库推送代码的权限。由于这些提交来自一个被认可的贡献者账号，自动化流水线和代码评审者要发现任何可疑之处，门槛大大提高了。
这正是软件供应链攻击的典型特征：恶意载荷藏匿在合法软件内部，通过受信任的渠道签名并分发。在受影响的窗口期内安装或更新了这些包中任何一个的开发者，都会在毫无明显警告的情况下，在自己的系统上悄无声息地执行该恶意软件。这些软件包本身继续正常运行，使得检测更加困难。
“Mini Shai‑Hulud” 恶意软件变种专为安装时运行而设计，即在开发者输入 npm install 的那一刻。它不会等待应用程序启动或用户与之交互。这种方式大幅缩短了从感染到数据外泄的时间间隔。
哪些凭据被盗及其重要性
该恶意软件的目标清单，读起来就像是攻击者能从开发者工作站或 CI/CD 流水线运行器中窃取的最具破坏性内容的核对清单。AWS、Google Cloud Platform 和 Azure 凭据文件是首要目标，因为这些密钥往往拥有对生产基础设施的广泛权限。SSH 私钥和 Kubernetes 配置文件则充实了赃物范围，使攻击者可能获得通过横向移动进入内部网络和容器编排集群的路径。
对于运行自动化构建流水线的组织而言，暴露风险会被放大。CI/CD 系统通常将长期云凭据存储为环境变量或挂载的机密。一个被感染的构建运行器可能悄悄交出掌控整个云环境的密钥，从而为数据外泄、勒索软件部署或持久后门访问打开大门。
这也是安全团队应当牢记供应链入口点经常会串联成更深层系统入侵的原因。CISA 近期对可获取 Linux 本地提权漏洞 CVE-2026-31431 的标记，直接提醒我们：通过窃取的凭据或初始访问权限进入系统的攻击者，很少会止步于此。他们会寻找链条中的下一环。
供应链攻击为何是标准安全的盲点
传统安全工具建立在外部、未签名或未知代码是威胁的假设之上。防火墙、端点检测代理和基于签名的扫描器被校准为标记异常。供应链攻击通过隐藏在带有合法签名并通过预期渠道送达的软件内部，颠覆了这一模型。
在此案例中，Red Hat 品牌以及关联的 GitHub 账号历史，本会让被入侵的软件包获得高度的隐性信任。在 Red Hat 相关基础设施上工作的开发者安装这些包，很可能正是因为他们预计这些包会得到良好维护且安全可靠。
标准的依赖检查工具会扫描已知存在漏洞的版本，但除非恶意版本已被标记到漏洞数据库中，否则不会发现安装时凭据窃取器。这种攻击利用了“已知恶意”检测与行为分析之间的间隙。
分层防御：机密管理、网络隔离与 VPN
没有哪项单一控制措施能阻止一起复杂的供应链攻击，但分层防御可以显著减小爆炸半径。
以机密管理取代本地凭据文件。 最有效的缓解措施是彻底消除开发者机器和 CI/CD 运行器上的静态凭据文件。那些能够签发短期、即时生效凭据的工具，意味着即使凭据被盗，也会在攻击者能够实用之前过期。
依赖锁定与完整性验证。 将软件包锁定到特定的、经过验证的提交哈希值，而非浮动版本范围，可限制对未预期代码变更的暴露。将此与对包内容的自动化完整性检查相结合，可增添另一个检测层。
网络隔离与出站过滤。 Mini Shai‑Hulud 恶意软件需要将被盗数据发送到某个地方。限制构建环境和开发者机器到已知端点的出站连接，即使恶意软件成功执行，也能阻止数据外泄。VPN 和零信任网络架构能够在分布式团队中一致地执行这些出站策略。
对每个开发者账号实施多因素身份认证。 此次入侵的初始环节是 GitHub 账号接管。严格的 MFA 要求，尤其是硬件安全密钥或基于通行密钥的身份认证，会使账号劫持困难得多。
CI/CD 流水线中的行为监控。 在构建阶段对非预期的出站 DNS 查询或网络连接发出告警，能够在被盗凭据被使用之前暴露安装时恶意软件。
这对你意味着什么
如果你的开发或运维环境依赖任何 Red Hat Cloud Services npm 包，当务之急是审计正在使用的包版本，在安装事件前后的网络日志中检查入侵指标，并轮换任何可能存在于受影响系统上的云凭据。
更广泛地看，此次事件是一次提示，要求你端到端地审查云凭据的卫生习惯。凭据是否作为文件存放在开发者机器上？CI/CD 环境变量是否被限定为最小权限？是否对每个拥有包发布权限的账号都强制启用了 MFA？
供应链攻击通过利用信任得逞。应对之策是构建不单纯依赖隐性信任的系统——经过验证的身份、时效有限的机密和行为监控是基石。从今天的凭据审计开始，并将每一个依赖项视为值得仔细审查的潜在攻击面。
