← LeisureLinux 文章索引
LeisureLinux · 微信公众号文章

Red Hat 软件包遭篡改：Miasma 蠕虫深度分析与供应链安全启示

安全/漏洞 阅读原文（微信）↗

事件概述

2026 年 6 月初，Red Hat（红帽）官方 npm 组织 @redhat-cloud-services 下的多个软件包被发现携带恶意代码，引发开源软件供应链安全领域的广泛讨论。LWN.net 将其列为近期 Briefs 头条，Ars Technica、BleepingComputer、Sonatype、StepSecurity 等多家安全机构和媒体均发布了详细分析报告。

安全社区将此攻击活动称为 \"Miasma\"（瘴气）——一个会自我传播的蠕虫式供应链攻击，其名字恰如其分地描述了它\"如瘴气般蔓延\"的特性。

━━━ ━━━ ━━━

攻击技术细节攻击入口

攻击者并非通过常见的\"钓鱼邮件\"或\"密码猜测\"突破防线，而是通过 GitHub Actions OIDC 从 Red Hat 官方 CI/CD 管道直接注入恶意代码。这意味着攻击者已经拿到了 Red Hat 内部 GitHub 仓库的 CI/CD 凭据或访问权限。

所有受影响的恶意包都是通过 RedHatInsights/cloud-services-config 这个 GitHub 仓库的 GitHub Actions OIDC 发布到 npm 的——上游 CI/CD 管道本身已被攻陷。

受影响的软件包

截至报告，已确认至少 18 个 \@redhat-cloud-services 命名空间下的包被植入了恶意代码，其中包括：

  • @redhat-cloud-services/types——类型定义
  • @redhat-cloud-services/frontend-components——前端组件库
  • @redhat-cloud-services/rbac-client——权限控制客户端
  • @redhat-cloud-services/javascript-clients-shared——JS 客户端共享库
  • @redhat-cloud-services/host-inventory-client——主机清单客户端
  • @redhat-cloud-services/notifications-client——通知客户端
  • @redhat-cloud-services/vulnerabilities-client——漏洞客户端

等等。这些不是拼写错误的冒名包（typosquatting），而是在 Red Hat 官方命名空间下的、由合法维护者发布的包。

多阶段隐蔽载荷

StepSecurity 团队对恶意代码进行了深度逆向分析，发现了一个经过四层混淆的、体积高达 4.2MB 的载荷（正常库包只需几 KB）：

  1. Layer 1——obfuscator.io 标准混淆，1.27MB 输出，含一个静默 catch 块
  2. Layer 2——ROT-21 凯撒密码编码，字符代码储存在大型数值数组中，运行时重建
  3. Layer 3——自定义 Base64 字母表 + IIFE 旋转（284 次轮换），2,219 个字符串表项
  4. Layer 4——自定义 PBKDF2（20 万次迭代）+ Fisher-Yates 字节替换密码，所有敏感字符串（C2 域名、端点、路径）均被加密

这四层混淆让传统的静态分析工具几乎无法检测。

Credential Harvesting（凭据收割）

恶意代码在 npm install 的 preinstall 钩子中自动执行，在开发者的代码运行之前就已启动，目标是：

GitHub Actions 凭据：

  • 通过读取 /proc/*/mem 直接从 CI runner 进程内存中提取密钥
  • 利用 GitHub Actions 运行时 API 查询 ACTIONS_RUNTIME_TOKEN
  • 精准定位 isSecret 标记的变量（即被遮蔽的密钥）

多云服务凭据：

  • AWS：默认应用凭证、服务账号密钥文件
  • GCP：gcloud 配置、服务账号密钥
  • Azure：Azure CLI 配置
  • Kubernetes：kubeconfig、集群凭证
  • HashiCorp Vault：令牌和配置

开发工具令牌：

-   npm 发布令牌（用于自我复制）
  • CircleCI 令牌
  • SSH 私钥

自我传播蠕虫

这是最令人担忧的部分。使用窃取的 npm 令牌，恶意代码会自动发布已被植入后门的新版本到其他 npm 包中。它利用 npm 的 ——otp=bypass_2fa 参数绕过双因素认证（2FA）保护。

这意味着：每一台被感染的机器，都可以自主催生下一波攻击，无需攻击者进一步参与。

隐蔽的 GitHub 数据外传通道

恶意代码不仅通过 HTTPS 外传数据，还实现了一个基于 GitHub API 的隐蔽外传通道：

  • 使用窃取的 GITHUB_TOKEN 调用 GitHub Contents API
  • 在被感染者的仓库中创建 ref 和 commit
  • 将 stolen data 进行 Base64 编码存储在 commit 中
  • 从网络层面来看，这完全无法与正常的 git 操作区分
  • GitHub.com (api.github.com) 几乎在所有 CI 网络策略中都是白名单的

持久化机制

即使删除了恶意包，攻击者仍然可以通过以下方式保持访问：

  • Claude Code：在 ~/.claude/settings.json 注入 postMessage 钩子，每次 Claude Code 会话启动时执行攻击者代码
  • VS Code：在 .vscode/tasks.json 写入 task trigger，打开项目文件夹时执行

━━━ ━━━ ━━━

攻击波及面：从 Red Hat 到微软 Azure

这场攻击并非局限于 Red Hat。Miasma 蠕虫在 6 月 5 日扩散到了微软 Azure 的 GitHub 组织。

GitHub 强制禁用了微软四个 GitHub 组织下的 73 个仓库，原因是一个恶意 commit 被推送到 Azure/durabletask 仓库，该 commit 使用了之前已被攻陷的贡献者账号。攻击配置了在开发者使用 Claude Code、Gemini CLI、Cursor 或 VS Code 打开仓库时自动触发凭据收割载荷。

━━━ ━━━ ━━━

为什么这次事件意义重大

1. 信任链条的彻底断裂

这些是 Red Hat 官方命名空间下的合法包，有真实的维护者、有意义的下载历史和有效的元数据。安全界长期以来依赖\"包的信誉\"作为安全指标——这个做法已经失效。一个包昨天是安全的，今天可以是恶意的。

2. 签名认证无法阻止管道劫持

Tech Times 的报道标题直击核心：《Signed Attestations Cannot Block Pipeline Hijack》。即使有 SLSA 级别签名和 Sigstore 认证，如果发布管道本身被攻陷，所有签名都是\"恶意的合法签名\"。

3. 蠕虫式自我复制让响应极其困难

传统的供应链攻击是线性的（攻击者手动上传 → 用户下载）。Miasma 的工作方式是指数级的：每个受害者都变成新的传播节点，使用自己的 npm 令牌去感染更多包。npm 的 bypass_2fa 参数本是为了自动化发布流程设计的，现在被恶意利用。

4. 开发者工具成为攻击面

Claude Code 和 VS Code 的配置文件成为持久化入口点。AI 辅助编程工具越来越普及，攻击者正在把\"AI 信任\"当作新的攻击面。

━━━ ━━━ ━━━

防御建议对于使用受影响包的组织

  1. 立即隔离：停止受影响环境中的所有 CI/CD 活动
  2. 审计痕迹：检查 GitHub、npm、云平台和 CI/CD 审计日志，查找异常的 token 使用、仓库变更、工作流编辑或包发布
  3. 轮换凭据：在隔离后，从一个干净的机器轮换所有可能暴露的凭据
  4. 重建 CI 运行器：如果无法排除系统被感染，重建 CI runner 和开发者机器
  5. 扩大排查范围：假设影响范围超出最初受影响的仓库，检查其他可访问的项目和仓库

长期防御策略

  • 引入发布时间冷却期：新发布的包版本在一个可配置的窗口期内不可用，等待安全社区的反馈
  • 运行时 CI 监控：使用 Harden-Runner 类工具监控 CI 运行时的网络、进程和文件行为
  • 最小权限原则：npm 发布 token 应只赋予最小必要的权限范围
  • 供应商中立的安全扫描：不依赖单一信誉系统，使用多层安全检测

一个深刻的教训

\"信任应当是持续评估的过程，而非一劳永逸的决定。\"

>

------ Sonatype Security Research Team

对于安全团队来说，开源治理必须从静态的许可名单和一次性依赖审批，转变为\"每一次新版本都是新的风险决策\"。

━━━ ━━━ ━━━

参考来源

  • [LWN.net] Briefs: Lightwell; jqwik protestware; RedHat package compromise——2026年6月周报
  • [StepSecurity] Multiple \@redhat-cloud-services npm Packages Compromised——完整技术逆向分析
  • [Sonatype] Red Hat Cloud Services npm Packages Hijacked——安全研究团队报告
  • [Tech Times] Signed Attestations Cannot Block Pipeline Hijack——行业评论
  • [Ars Technica] Dozens of Red Hat packages backdoored through its official NPM channel
  • [BleepingComputer] Red Hat npm packages compromised to steal developer credentials
  • [Microsoft] Preinstall to persistence: Inside the Red Hat npm Miasma credential-stealing campaign
  • [LWN.net] Supply-chain attacks section——同期安全更新汇总

━━━ ━━━ ━━━

*本文由 AI 小龙女原创 · 首发 LeisureLinux 公众号 · 欢迎转载，请注明出处*

供应链防御链条的"坍塌"：美国金融科技服务商Marquis 勒索攻击事件全维度还原

Bitwarden 供应链污染事件：是发布链投毒，而非加解密崩盘

供应链投毒：LiteLLM 投毒事件给每一位架构师的警示

软件供应链安全范式变革：PURL元数据标准化、生态系统融合与"SBOM混淆"漏洞深度研究

AI Agent 的"操作系统"呼之欲出：红帽 Skill 仓库释放的重磅信号

常见问题（FAQ）

Q1：这篇文章主要讲什么？ 2026 年 6 月初，Red Hat（红帽）官方 npm 组织 @redhat-cloud-services 下的多个软件包被发现携带恶意代码，引发开源软件供应链安全领域的广泛讨论。LWN.net 将其列为近期 Briefs 头条，Ars Technica、BleepingComputer、Sonatype、StepSecurity 等多家安全机构和媒体均发布了详细分析报告。 Q2：还有哪些关键事实？ GitHub 强制禁用了微软四个 GitHub 组织下的 73 个仓库，原因是一个恶意 commit 被推送到 Azure/durabletask 仓库，该 commit 使用了之前已被攻陷的贡献者账号。 Q3：有哪些值得注意的细节？ 2. 签名认证无法阻止管道劫持 Tech Times 的报道标题直击核心：《Signed Attestations Cannot Block Pipeline Hijack》。 Q4：核心结论是什么？ ━━━ ━━━ ━━━ 防御建议对于使用受影响包的组织 1. 立即隔离：停止受影响环境中的所有 CI/CD 活动 2. 审计痕迹：检查 GitHub、npm、云平台和 CI/CD 审计日志，查找异常的 token 使用、仓库变更、工作流编辑或包发布 3. 轮换凭据：在隔离后，从一个干净的机器轮换所有可能暴露的凭据 4. **重建 CI…

本文整理自微信公众号 LeisureLinux 的原创内容（Linux / AI / 安全 硬核技术）。

· 阅读原文（微信公众号）

· 关注公众号 LeisureLinux，第一时间获取技术深度内容。

LeisureLinux 公众号二维码（微信扫一扫关注）