上周三凌晨两点，一个叫 react-codeshift 的 npm 包在237个代码仓库里默默运行着。它不是任何一个开发者手动安装的。安装它的是 AI 编程 Agent——Claude Code、Cursor、Copilot，这些你每天信任的工具，在自动生成代码时"推荐"了这个包。

问题是，这个包根本不存在于正常的 npm 生态里。它是 AI 模型"幻想"出来的。

安全研究员 Charlie Eriksen 追踪这条链路时发现了一个让人后背发凉的传播机制：开发者用 AI 生成代码 → AI 在代码中引入了一个不存在的依赖 → 另一个开发者的 AI Agent 读到了这份代码 → Agent 在自己的项目中复用了这个依赖名 → 恶意攻击者嗅探到趋势后抢注了这个包名 → 237个仓库同时中招。

这叫 Slopsquatting。Cloud Security Alliance 在2026年4月的专题报告里给它起了这个名字，但圈内人更愿意叫它"AI喂给AI的毒药"。

19.7%，这不是Bug，是系统性的

Snyk 和 CSA 的联合研究给了一个精确数字：AI 编程工具推荐的 Python 和 JavaScript 依赖中，大约19.7%的包名根本不存在。换句话说，每5个 AI 建议的第三方库，就有1个是模型凭空捏造的。

为什么是19.7%？因为大语言模型从训练数据中学到了"包名长得像什么"，但它没有一本真实的注册表。你问它"怎么在 Python 里做 PDF 解析"，它可能推荐 pdf-parser-plus——听起来像个正经库，PyPI 上根本没人注册过这个名字。攻击者看到这个查询趋势，抢先把这个名字注册下来，塞进恶意代码。下一个让 AI 写 PDF 解析功能的开发者，就中招了。

阿里巴巴今年就踩过这个坑。有人在公开仓库文档里抄了一条 AI 推荐的安装命令——pip install huggingface-cli。这个包名是 AI 幻想出来的，真正的包叫 huggingface_hub。但文档一公开，搜索引擎一收录，三个月内这个假包积累了超过3万次下载。攻击者抢注后，等于白捡了一个3万下载量的分发渠道。

最可怕的不是人犯错，是 Agent 自己在传

传统的供应链攻击，感染链条是人 → 人。一个开发者装了恶意包，最多影响他自己和用他代码的人。

Slopsquatting 不同。它的感染链条是 AI → AI → AI。

你的 Claude Code 写了一个工具函数，引用了一个不存在的包。这段代码被提交到 GitHub。另一个团队的 Cursor Agent 在分析这个仓库时，把这个依赖名学了过去。第三个开发者的 Copilot 在做相似功能时，又复用了这个依赖名。整个过程没有任何一个人类开发者真正审查过这个包名是否真实存在。

react-codeshift 就是靠这条链路传播的——237个仓库，没有一个是人手动 npm install 的。全是 Agent 在执行自己生成的代码时自动引入的。

安全研究员 Bar Lanyado 管这个叫"AI 之间的谣言传播"。跟人类谣言不同，AI 谣言可以被攻击者"实体化"——只要你抢在传播链的某个节点之前注册了那个包名，你就掌握了整条传播链的下游。

你的安全扫描工具，检测不到

更让人不安的是，传统的 SAST 和 SCA 工具对这种攻击几乎完全失效。

SAST 扫描的是你写的代码，不是 AI 写的依赖名。SCA 对比的是已知漏洞数据库，但一个刚刚被抢注的恶意包，漏洞库里连条目都没有。Sonatype 的2026年报告显示，恶意包从上传到被检测的平均窗口期是 8 小时。8 小时里，一个自动运行的 AI Agent 可以提交多少轮代码？DXC Technology 的数据是：Claude Code 能在8小时内完成一个中型银行系统的模块重构。

还有一个隐蔽性更强的问题：AI Agent 在执行代码时会自动 pip install 或 npm install。你的 CI/CD 流水线里配了依赖审查？Agent 可能绕过了它——不是恶意的，只是它"认为这个依赖是项目需要的"。人类开发者至少会在安装前看一眼包名和下载量，Agent 不会。Agent 只关心"这个函数能不能跑通"。

国内开发者正在成为重灾区

这个问题在国内比海外更严重。原因有三条。

第一，国内开发者大量使用 PyPI 和 npm 镜像源。镜像源的同步延迟给了攻击者更长的窗口期。一个恶意包从上传到 PyPI 官方源再到被镜像源同步，中间可能有12-24小时的延迟。恶意包在官方源被标记后，镜像源上依然可用。

第二，国内开发者的英文文档阅读习惯导致了一个特殊现象：很多人在搜索引擎里直接复制 AI 推荐的安装命令，不做二次验证。huggingface-cli 这个假包在中国区的下载量占全球总量的70%以上，就是因为中文技术博客和公众号文章互相抄来抄去，把 AI 的错误推荐当成了正确的安装指令。

第三，国内很多中小团队没有专职安全工程师。代码审查往往只走形式，依赖审查基本不存在。一个团队里可能没人真正看过 package.json 里的依赖列表——直到生产环境出了事。

你现在能做什么

这不是一个"等待厂商修复"的问题。模型厂商短期内解决不了幻觉问题，因为它本质上是生成式模型的固有特性，而非一个可以打补丁的 Bug。

能做的事只有工程层面的防御：

第一，在 CI/CD 中加入依赖白名单机制。但凡 AI 生成的代码引入新依赖，必须在 Pull Request 中显式标注来源，由人类审查后才能合并。这不是可选项，是红线。Shopify 的工程团队在今年 Q2 推行了"AI 依赖零信任"策略，AI 引入的任何新依赖必须经过两名高级工程师审批。结果第一个月就拦截了14个不存在的包名。

第二，给 AI Agent 设置沙箱执行环境。不允许 Agent 直接 pip install，所有依赖变更走审批流程。Anthropic 在 Claude Code 企业版里已经加了 --permission-mode 参数，但在国内使用场景中，这个配置很少被启用。云原生环境里可以考虑用 OPA 或 Kyverno 在集群层面做准入控制。

第三，监控你的 package.json 和 requirements.txt 中是否存在"只有 AI 才知道"的依赖名。如果你在项目中看到一个你不认识、同事也不认识的包名，它大概率是 AI 塞进来的。做一个简单的脚本，每天对比你的依赖列表和官方注册表，标记出注册表里不存在的条目。

第四，别低估攻击者的嗅觉。GitHub 上有大量自动化脚本在监控 npm 和 PyPI 的"热门搜索词"和"AI 常推荐的错误包名"。攻击者比你更清楚 AI 在哪些依赖名上容易出错。这场猫鼠游戏，老鼠已经跑在前面了。

Slopsquatting 不是一个遥远的安全议题。它正在发生，就在你的 AI 编程工具每一次"自信地推荐一个不存在的库"的时候。下一次 Code Review，别只看代码逻辑，看一眼依赖列表——那里可能藏着你整个项目的后门。

一句话总结：AI 编程工具的幻觉已经不只是"生成错误的代码"，它正在系统性地制造供应链攻击面。防御它的不是更好的模型，是更严格的工程纪律。