引言

6月5日早上，全球数万名开发者的CI/CD流水线突然报错。他们检查了半天配置，才发现问题出在一个自己根本没碰过的地方——Azure/functions-action这个GitHub Action被微软禁用了。不是因为有bug，而是因为它被一种蠕虫感染了。

这就是Miasma蠕虫。它不像传统病毒那样利用软件漏洞，而是利用了一个更根本的东西：信任。它伪装成正常的npm更新、正常的GitHub提交、正常的项目配置文件，然后在你用AI编程助手打开项目的那一刻，悄悄激活。过去两周，它先后感染了Red Hat的32个npm包、微软的73个GitHub仓库，以及npm生态中超过57个包的286个恶意版本。

更让人不安的是，这可能是第一种专门为AI编程时代设计的供应链恶意软件。它不是偶然被AI工具触发的，而是精确地针对Claude Code、Cursor、Gemini CLI、VS Code这四大AI编程工具设计了触发机制。当你的AI助手"读取整个代码库"来理解上下文的时候，它也在帮恶意软件执行攻击链。

01 | 三波攻击：从PyPI到npm到GitHub的连环爆破

Miasma蠕虫的攻击不是一次性事件，而是一场精心编排的三幕剧，每一波攻击都比前一波更精密、更隐蔽。

第一波：5月19日，PyPI投毒

故事要从5月19日说起。那天，一个名为durabletask的Python包在35分钟内被上传了3个恶意版本（1.4.1、1.4.2、1.4.3）。这个包是微软Azure工作流引擎的核心组件，被大量企业级项目依赖。

恶意代码只有14行，藏在__init__.py里，做的事情很简单：从check.git-service[.]com下载一个28KB的Python归档文件rope.pyz。但这个小小的载荷背后，是一台精密的凭证收割机。它包含7个并行运行的收集模块，专门针对AWS、Azure、GCP、Kubernetes、HashiCorp Vault等云平台的凭证。它会遍历AWS的19个区域枚举Secrets Manager和SSM参数，通过4种认证方式访问Azure Key Vault，甚至会下载kubectl来dump Kubernetes集群中所有命名空间的Secret。

最让人后背发凉的是它的反分析手段：系统语言为俄语的机器会被跳过，CPU核心数不超过2个的虚拟机也会被跳过。还有一个名为roulette.py的模块，针对以色列时区和语言环境的系统，有六分之一的概率执行rm -rf /*。

第二波：6月1日，Red Hat npm包沦陷

两周后的6月1日，攻击者利用从第一波攻击中窃取的凭证，向RedHatInsights GitHub组织推送了未授权的提交。在72秒内，32个@redhat-cloud-services作用域下的npm包被发布了恶意版本。

这次攻击引入了一种全新的技术——"Phantom Gyp"。攻击者不再使用preinstall或postinstall这些安全工具会监控的生命周期钩子，而是在包里放了一个只有100字节的binding.gyp文件。这个文件利用node-gyp（Node.js原生插件构建工具）在npm install时自动执行代码的特性，通过shell展开和"type": "none"配置触发任意代码执行。整个过程不触碰package.json的scripts字段，完美绕过了几乎所有现有的安装脚本安全扫描器。

第三波：6月5日，微软GitHub仓库大沦陷

6月5日，攻击者用同样的受损凭证，向Azure/durabletask仓库推送了一个新的恶意提交（commit 5f456b8）。这次他们植入了5个精心设计的文件，分别针对5种开发者工具：

• .claude/settings.json — Claude Code的SessionStart钩子
• .gemini/settings.json — Gemini CLI的SessionStart钩子
• .cursor/rules/setup.mdc — Cursor的alwaysApply: true提示注入
• .vscode/tasks.json — VS Code的runOn: folderOpen自动执行
• .github/setup.js — 4.6MB的混淆载荷

GitHub在105秒内禁用了横跨Azure、Azure-Samples、Microsoft、MicrosoftDocs四个组织的73个仓库。但Azure/functions-action的下线直接瘫痪了全球大量CI/CD流水线——这是GitHub Actions生态中最常用的Azure部署Action之一。

02 | 技术深潜：AI编程工具如何成为攻击载体

Miasma蠕虫最令人不安的创新，是它把AI编程助手从"生产力工具"变成了"攻击放大器"。这不是偶然的——它的每一个设计决策都精确地针对AI编程工具的工作方式。

三阶段攻击链

整个攻击分为三个阶段，每一阶段都经过精心设计：

第一阶段：混淆加载器。 恶意的index.js文件有4.6MB，包含大量垃圾代码。它使用ROT-N凯撒密码解密出两个AES-128-GCM加密的载荷。这种混淆方式简单但有效——静态分析工具很难在海量代码中识别出真正的恶意逻辑。

第二阶段：Bun运行时部署。 解密后的载荷会从GitHub下载Bun JavaScript运行时（v1.3.13）到临时目录。为什么用Bun而不是Node.js？因为Bun是一个相对较新的运行时，安全检测工具对它的行为模式还不熟悉，更容易绕过EDR（端点检测与响应）系统的监控。

第三阶段：蠕虫主程序。 一个约720KB的Bun程序开始执行核心恶意逻辑。它做的事情包括：凭证收割、GitHub Actions工作流注入、包投毒、以及数据外泄。

为什么AI编程工具是完美目标

传统恶意软件需要用户执行某个操作才会激活——点击链接、运行程序、打开文档。但AI编程工具从根本上改变了这个模型。

当你用Claude Code或Cursor打开一个项目时，AI助手会自动读取整个代码库的上下文，包括所有配置文件。这意味着.claude/settings.json、.cursor/rules/setup.mdc、.gemini/settings.json这些AI代理配置文件会被自动解析和执行。开发者不需要做任何额外操作——只要克隆仓库、用AI工具打开，恶意代码就已经开始运行了。

更危险的是，Miasma蠕虫利用了AI工具的提示注入能力。它在Cursor的配置文件中设置了alwaysApply: true，这意味着无论开发者问什么问题，恶意指令都会被注入到AI的上下文中。AI助手在不知不觉中成为了攻击者的帮凶。

86个环境变量的地毯式收割

Miasma蠕虫的凭证收割范围极其广泛，针对86个环境变量和凭证文件路径：

云平台：AWS Access Key、Azure Client Secret、GCP Service Account JSON——它会通过AWS IMDSv2获取临时凭证，通过Azure的4种认证方式访问Key Vault，通过GCP的metadata server获取OAuth token。

容器与基础设施：Kubernetes Service Account Token、Docker配置、HashiCorp Vault Token——它有一个专门的483行Kubernetes收集器，通过mTLS连接API Server，dump所有命名空间的Secret。

AI与开发工具：OpenAI Codex配置、Anthropic/Claude API Key、Google Gemini配置、Cursor配置——这正是AI编程时代的特色收割目标。

包管理器：npm token、PyPI API Key、RubyGems API Key——获取这些凭证后，蠕虫就能向受害者维护的所有包发布恶意版本，实现自我复制。

其他：SSH私钥、浏览器保存的密码、1Password CLI、Exodus加密货币钱包文件。

自我复制：合法渠道内的蠕虫传播

Miasma蠕虫最精妙的设计是它的自我复制机制。它完全在合法渠道内运作——不利用npm或GitHub的任何漏洞，而是利用这些平台的信任模型。

攻击链是这样的：蠕虫窃取受害者的npm token和GitHub PAT → 用这些凭证向受害者有写权限的仓库推送恶意提交 → 提交中包含投毒后的包配置 → 利用npm的Trusted Publishing流程获取短期token → 发布恶意版本到npm registry → 新的开发者安装这些包 → 循环重复。

在CI/CD环境中，它还会替换现有的GitHub Actions工作流，换成能够收割Secret的恶意工作流。窃取的凭证被加密后写入"悬挂提交"（dangling commits）——这些提交不属于任何分支，只有知道commit hash的人才能访问，完美隐藏了数据外泄的痕迹。

更狡猾的是，蠕虫会搜索GitHub上包含"firedalazer"字符串的commit来获取额外载荷。攻击者可以随时修改这些commit的内容，实现动态C2（命令与控制）。GitHub本身成为了C2服务器——这在安全史上是极其罕见的。

归因与关联

安全研究人员将这次攻击归因于TeamPCP威胁组织。该组织使用俄罗斯民间传说命名外泄仓库——BABA-YAGA（芭芭雅嘎）、KOSCHEI（不死者科谢伊）、FIREBIRD（火鸟），暗示其可能具有东欧背景。

Miasma蠕虫的前身是2025年9月出现的Mini Shai-Hulud蠕虫，当时是npm生态中第一个被观察到的自复制恶意软件。从Shai-Hulud到Miasma的进化只用了不到一年，但技术复杂度提升了数个量级。

03 | 你该怎么办：开发者生存指南

面对这种新型攻击，传统的"小心陌生包"建议已经不够了。以下是基于安全研究人员建议的10条具体防护措施：

1. 审查binding.gyp文件。 在npm install任何新包之前，检查是否包含binding.gyp文件。如果一个纯JavaScript包突然需要原生编译，这是巨大的红旗。

2. 不要用AI工具直接打开不熟悉的仓库。 先用普通编辑器或cat检查关键配置文件（.claude/、.cursor/、.gemini/、.vscode/、.github/），确认没有异常后再用AI工具。

3. 禁用AI工具的自动执行功能。 在Cursor中，不要使用alwaysApply: true的规则文件；在Claude Code中，审查SessionStart钩子；在VS Code中，禁用runOn: folderOpen任务。

4. 使用依赖锁定文件。package-lock.json或yarn.lock可以防止意外安装新版本。结合npm ci（而非npm install）确保只安装锁定的版本。

5. 实施依赖审计自动化。 使用Socket.dev、SafeDep、StepSecurity等工具实时监控依赖变化。关注preinstall、postinstall脚本和binding.gyp文件的变更。

6. 最小化npm token权限。 使用Granular Access Token而非Classic Token，限制token只能发布特定的包。启用2FA发布要求。

7. 监控你的仓库。 设置GitHub webhook，对所有推送发送通知。关注是否有你没有做的提交——这可能是蠕虫在利用你的凭证传播。

8. 轮换凭证。 如果你在5月到6月期间安装过任何受影响的包，立即轮换所有npm token、GitHub PAT、云平台凭证。

9. 使用AI代理防火墙。 工具如Invariant Labs的Agent Firewall可以监控和限制AI编程工具的行为，阻止异常的文件访问和网络请求。

10. 保持CI/CD最小权限原则。 GitHub Actions工作流应该使用最小权限的GITHUB_TOKEN，不要给contents: write除非绝对必要。

总结

Miasma蠕虫不是一个普通的安全事件，它是一个时代的标志。几个核心要点：

AI编程工具正在成为新的攻击面。 当你的AI助手自动读取整个代码库时，它也在为攻击者执行恶意配置文件。这不是AI的bug，而是它的核心功能被武器化了。

供应链攻击正在进化。 从投毒npm包到利用GitHub信任模型，从凭证收割到自我复制，Miasma展示了供应链攻击可以多么精密和隐蔽。它完全在合法渠道内运作，传统的安全边界形同虚设。

信任模型需要重新设计。 "包由认证维护者签名发布就是安全的"这个假设已经不再成立。我们需要从"默认信任"转向"默认验证"。

开发者需要新的安全习惯。 审查AI配置文件、限制AI工具权限、监控依赖变化——这些在一年前不存在的需求，现在是每个开发者的必修课。

最后引用安全研究员Paul McCarty的话："当上个月被攻破的仓库根节点就是本月大关停的中心，这不是巧合，这是同一个伤口在重新裂开。"Miasma蠕虫可能已经被遏制，但它揭示的攻击范式才刚刚开始。