Red Hat 的官方 npm 命名空间 @redhat-cloud-services 出事了。
安全公司 Aikido 和 Socket 披露，攻击者利用这个官方 scope 发布了 30 多个被植入后门的软件包。恶意代码可在 npm install 阶段执行，目标包括 GitHub Actions secrets、npm token、Kubernetes、Vault，以及云服务凭据。
这件事的反常点在这里：风险不等到业务代码运行才出现。只要开发机或 CI runner 安装过受影响版本，就可能已经暴露。
Red Hat 称恶意包已移除，并表示这些包仅限内部开发，未通过 console.redhat.com 面向客户发布。目前也未发现客户、合作伙伴环境或 Red Hat 生产系统受影响。这个边界很重要，不能把它写成 Red Hat 全线产品被攻破。
官方 npm scope 会把信任变成放大器
@redhat-cloud-services 是 Red Hat 在 npm 上的官方命名空间。
对很多开发团队来说，官方 scope 本来是降低审查成本的信号。依赖扫描、人工 review、CI 自动构建，都更容易给它放行。
攻击者利用的正是这层信任。
普通 npm 投毒，很多时候还要靠相似包名、拼写错误或陌生维护者蒙混过关。官方命名空间被滥用后，攻击链少了一道阻力。
| 对比项 | 普通 npm 投毒 | 这次 Red Hat 事件 | 对团队的实际影响 |
|---|---|---|---|
| 信任来源 | 陌生包、仿冒包名、维护者账号 | 官方 @redhat-cloud-services scope | 更容易进入企业流水线 |
| 触发位置 | 运行、导入或构建时 | npm install 阶段即可执行 | CI runner 和开发机都要查 |
| 窃取目标 | 常见环境变量、账号令牌 | GitHub Actions、npm、Kubernetes、Vault、云凭据 | 可能牵出仓库、集群和云资源 |
| 扩散方式 | 单点窃取为主 | 可利用感染系统权限重新发布后门包 | 风险可能外溢到第三方包 |
这里要保持克制。
目前公开信息还不能确认攻击者最初怎样拿到 Red Hat 相关发布权限。原文只指向凭据泄露或 CI/CD 环节被利用的可能性。不能直接断言某个员工终端、某套内部系统，或客户环境已经被攻破。
但这已经足够说明一个问题：供应链安全最脆的地方，往往不是包本身，而是发布包的人、机器和令牌。
安装阶段执行，排查范围要往前推
npm 包可以通过安装脚本执行代码。
这意味着，团队不能只问“我们的应用有没有 import 这个包”。更该问的是：哪台开发机、哪个 CI runner、哪条构建流水线安装过它。
Socket 的分析称，恶意软件会收集敏感凭据并加密外传。在具备条件时，它还可能把加密数据写入被攻陷的 GitHub 仓库。
更危险的是扩散能力。恶意软件可利用被感染系统已有权限，重新发布带后门的包。这样一来，被害者不只是丢了 token，还可能变成下一轮投毒的发布点。
这对两类人影响最大。
一类是维护 npm 依赖和 CI/CD 的开发平台团队。他们需要暂停相关构建，核对锁文件、构建日志和 runner 镜像，而不是等业务报错。
另一类是管 GitHub Actions、Kubernetes、Vault 和云账号权限的安全团队。他们要把凭据轮换放到排查前面。因为这类凭据一旦被拿走，攻击者可以绕开应用层，直接碰代码仓库、集群和云资源。
近期装过相关包，先按潜在失陷处理
受影响团队不应只删包了事。
更稳妥的顺序，是先保全现场，再切断权限，再查扩散面。
| 动作 | 具体做法 | 目的 |
|---|---|---|
| 核对范围 | 对照 Aikido、Socket 披露的受影响包清单和 IOC | 确认是否安装过相关版本 |
| 冻结构建 | 暂停相关 CI job，保留 runner、workflow、npm install 日志 | 避免继续触发脚本，保留证据 |
| 隔离环境 | 隔离装过受影响版本的开发机和 CI runner | 防止凭据继续外泄 |
| 轮换凭据 | 更换 npm token、GitHub secrets、OIDC 配置、Kubernetes、Vault 和云凭据 | 让已泄露凭据失效 |
| 查二次投毒 | 检查近期异常包发布、异常 workflow、未知仓库写入 | 判断是否已被用来继续扩散 |
采购或平台团队也要做一个现实调整：近期涉及 @redhat-cloud-services 相关依赖的内部升级、镜像构建和自动发布，最好延后到清单核验和凭据轮换完成后。
这不是对 Red Hat 所有产品按下暂停键。Red Hat 已称未发现客户、合作伙伴环境或生产系统受影响。
真正需要暂停的是那些“已经安装过相关 npm 包、且安装环境带有高权限凭据”的流程。边界划清，处置才不会失焦。
接下来有两个变量最关键。
一个是初始入侵路径。如果只是单个发布凭据泄露，处置重点是轮换和权限收敛；如果牵到 CI/CD 发布流程，问题就会更深。
另一个是二次投毒有没有出现。如果被窃凭据已经被用来发布新包、写入仓库或改动 workflow，这起事件就不会停在 Red Hat 的官方 scope 里。
回到开头那个问题：为什么 npm install 阶段这么要命？
因为它发生在很多团队最放松的时候。代码还没跑，信任已经交出去了。