AI 开发工具正在被当作「凭证金矿」系统性挖掘：npm 双波供应链攻击 + MCP 协议层已成重灾区

今天有两件事同时发生，指向同一个方向。

第一件：The Hacker News 报告了 npm 生态系统里的两波相互独立但目标一致的供应链攻击——IronWorm 和新型 Miasma 变种。第二件：Palo Alto Networks 正式发出警告，MCP 服务器正在成为企业 AI 架构里「无人管控的新型 API」，CloudSEK 本周刚刚公布了一个真实客户案例，一台零认证 MCP 服务器被攻击者链式利用，最终把 AWS IAM 凭证和数据库密码全部拿走。

这两件事的共同点：攻击的目标不是应用本身，而是开发者机器上存着的凭证——尤其是 AI 工具的凭证。

两波 npm 攻击：专门猎杀 AI 工具密钥

IronWorm 是一个用 Rust 写的信息窃取程序，通过 50 多个恶意或被投毒的 npm 包传播，额外配备了 eBPF rootkit 做隐藏和 Tor 做 C2 通信1。同期出现的 Miasma 新变种击中了 57 个 npm 包、286 余个恶意版本，而且采用了 binding.gyp 绕过机制，专门躲开监控 postinstall 脚本的安全检查2。

这两波攻击的窃取范围清单让人印象深刻——同时也让人不安。IronWorm 扫描 86 个环境变量，包含 AWS、GCP、Azure、HashiCorp Vault、Kubernetes、GitHub，以及：Claude、Cursor、Gemini、VS Code 的 API 密钥和认证文件3。Miasma 的窃取清单同样明确列出 AI 助手，并专门在 Stage 4 载荷里植入了「Claude 钩子」。

这个设计不是偶然的。对攻击者来说，AI 工具的 API 密钥在价值排名上已经与云凭证并列。拿到 Claude 的 API 密钥，就能用受害者的配额发起攻击性提示；拿到 Cursor 的认证文件，意味着能接触到开发者机器上所有处理过的代码上下文。对于一次精心设计的供应链攻击来说，开发者的 npm 依赖是进入这些工具最自然的入口——它安静、合法，还自动在 CI/CD 流水线里跑。

npm 恶意包六阶段攻击流程，Miasma Payload 的窃取目标分布于云服务商、CI/CD 和 AI 工具凭证 — Miasma Payload 窃取目标清单：覆盖云服务商、基础设施、CI/CD 注册表及 AI 助手（Claude、Cursor、Gemini）凭证 1

MCP 协议层：连 AI 本身也在「帮倒忙」

如果 npm 供应链攻击还可以理解为「传统手段针对新目标」，那么 MCP 服务器的问题就更根本。

MCP（Model Context Protocol）由 Anthropic 于 2024 年 11 月发布，现在已成为 AI 智能体连接外部工具、数据库、云资源的事实标准接口。LangChain、AutoGen，以及各大云厂商的智能体工具包都支持它。截至 2025 年底，GitHub 上已有超过 13,000 个 MCP 服务器实现4。

问题在于，MCP 服务器本质上是在企业控制平面里运行的进程——它们持有的凭证往往是开发阶段直接配置进去的个人访问令牌或宽权限服务账号，MCP 规范本身在传输层也不强制要求客户端与服务器之间的认证。Palo Alto Networks 的安全团队在 6 月 4 日发布的报告里把它描述为「企业环境里新型的无管控 API」5。

CloudSEK 本周公开的案例是目前最具体的实证。客户环境中的一台 MCP 服务器完全暴露在互联网上，无需任何认证，攻击者的完整利用链是这样走的4：

无认证枚举工具列表，获取该 AI 系统的完整能力描述
通过音频代理工具传入 http://169.254.169.254/（AWS IMDS 地址），完成 SSRF，获取 AWS IAM 临时凭证
通过同一工具传入 file:///proc/self/environ，完成本地文件包含（LFI），取出环境变量里的明文数据库密码

从开始到拿到云凭证，攻击者不需要找一个 CVE，不需要任何漏洞扫描结果，只需要 MCP 规范里允许的标准协议调用。

MCP 架构与攻击面：MCP 客户端发出工具调用指令，经 MCP 服务器层到达底层资源，各层均存在认证缺失和提示注入风险 — MCP 架构中，服务器层持有宽权限凭证且默认不强制认证，任何 MCP 客户端均可发出工具调用 5

整个案例对应的背景数据同样清晰：现有研究对 2,614 个 MCP 实现的分析显示，82% 存在路径遍历风险，67% 涉及代码注入，34% 可被命令注入利用4。BlueRock Security 分析了 7,000 多个 MCP 服务器，其中 36.7% 存在 SSRF 漏洞。Endor Labs 的调查发现，38% 到 41% 的 MCP 实现没有任何认证机制5。

同一攻击面，两种入口

把这两件事放在一起，结构就很清晰：

攻击者既可以从下游（npm 包）污染开发者机器，让恶意代码在本地扫描 AI 工具密钥；也可以从协议层（MCP 服务器）找到已经部署在企业内部的 AI 集成端点，通过无认证接口直接操控它对接的工具。

前者利用的是开发者对 npm 生态的信任；后者利用的是企业对已部署 AI 基础设施的低可见性。两条路都在走，都在今天。

Datadog 的安全审计曾在被调查的 MCP 部署中发现 12,000 个 API 密钥和密码通过不安全的凭证处理方式暴露出来4。MCP 在 2025 年全年还产生了超过 30 个 CVE，其中包括 mcp-remote 的 CVSS 9.6 远程代码执行漏洞4。

这不是「AI 应用有风险」这种泛泛的命题。问题出在一个更具体的位置：AI 推理运行时需要凭证，而这些凭证目前的存储和传递方式——环境变量、明文配置、无认证端点——和 2015 年普通 Web 服务的安全实践没有本质区别，但 AI 推理所能接触的数据范围已经扩大了一个量级。

明文推理的代价，以及一条路径

上面这些案例指向同一个技术根源：AI 在完成推理时，输入数据必须以明文形式存在于某个可访问的内存空间。凭证泄露之所以危险，一个重要原因就是攻击者用窃取到的密钥发起推理请求时，他们能看到传进模型的是什么。

荆华密算的密态推理技术从这个节点切入：让 AI 模型在加密状态下完成整个推理过程，明文数据不在任何可访问的内存空间出现。无论 MCP 服务器配置多松、npm 包是否被投毒，攻击者拦截到的是密文，而不是推理输入和输出的原始内容。

对企业来说，6 月 1 日开始内测的全链路密态 AI 助手正好面向这种场景：员工日常用 AI 处理的业务数据，整个推理链路不出现明文。这在 npm 供应链攻击和 MCP 安全问题同时爆发的今天，具有相当直接的意义——补丁和认证机制可以减少攻击面，但无法消除「推理过程存在明文暴露前提」这个架构级问题。

参考来源：The Hacker News、Phoenix Security、Palo Alto Networks Unit 42、CloudSEK AIVigil、Cybersecurity News