当你的编程助手凭空编造出一个包时，攻击者会抢先注册它
让 AI 编程助手清理导入项，它可能会给你一个并不存在的包名。这个名字看起来很合理。它会结合两个真实工具，或者遵循你认得的命名惯例。你粘贴安装命令，而如果有人已经注册了那个名称，你刚刚安装的就是他们发布的任何东西。
安全研究人员称之为 slopsquatting。它是误植抢注（typosquatting）的近亲，区别在于攻击者不需要你打错任何字。他们只需要知道模型倾向于编造什么，然后抢先占下这个名字。
规模并非个例
2025 年 USENIX Security 的一项研究用 576,000 个 Python 和 JavaScript 代码样本测试了 16 个代码生成模型。研究发现超过 205,000 个在任何注册表上都不存在的唯一包名。商业模型的幻觉率至少为 5.2%，开源模型为 21.7%。2026 年的一项后续研究测试了五个更新的前沿模型，测得的比率为 4.62% 到 6.10% 之间，虽然更低，但在每个被测模型中仍然存在。
把一个怪癖变成攻击面的关键在于可重复性。当研究人员重新运行相同的提示时，很大一部分幻觉名称每次都会再次出现。模型并不是随机猜测；它们会收敛到相同的错误答案，因为它们从相同的训练数据中学到了相同的模式。这种可预测性就是漏洞。攻击者可以运行相同的提示，收集重复出现的名称，并在其他人之前注册它们。
2026 年的研究识别出 127 个包名，五个被测模型都产出了这些名称，尽管它们并不存在，其中 53 个在注册表防护措施生效之后仍可供注册。
真实的包，真实的安装
这种情况已经发生了。2026 年初，研究人员发现一个名为 react-codeshift 的包在 237 个 GitHub 仓库中被引用。这个名称融合了两个真实工具：jscodeshift 和 react-codemod。它从未被发布过。一个包含这个虚构包的 AI 生成 skill 被复制和 fork，让这个引用自行传播开来。
npm 上一个名为 metro-evaluator 的包在 2025 年 12 月发布的四个版本中带有恶意代码，五天后被移除，并替换为安全占位符。被测模型曾十次建议过这个名称。另一个名为 unused-imports 的包模仿了真实的 eslint-plugin-unused-imports，并不断从那些被助手引导过去的开发者那里获得安装量。
更大的行动是安全公司 Koi Security 称为 PhantomRaven 的活动，至少从 2025 年 8 月起就活跃。Koi 将其归因于 126 个恶意 npm 包和超过 86,000 次下载。那里的手法与幻觉名称不同。package.json 看起来干净，有时只包含一行日志之类的内容，但它指向一个托管在纯 HTTP URL 上的依赖项，而不是另一个 npm 包。大多数扫描器不会跟随原始 URL，因此会窃取 npm token、GitHub 凭据和 CI 密钥的载荷会在安装时不可见地加载。Endor Labs 记录了同一活动在 2025 年 11 月至 2026 年 2 月间的另外三波攻击，新增 88 个包，通过大约 50 个一次性账户上传。
注册表阻止了大多数名称，但不是全部
研究中有一个好消息。包注册表在阻止模型倾向于编造的名称方面做得更好了。它们会规范化相似名称，维护禁用列表，并监视在许多生成样本中出现的模式。当 2026 年的研究检查其 127 个共享幻觉名称列表时，大多数已经被合法项目或注册表防御措施占用或阻止。
问题在于，“大多数”并不是“全部”。同一项研究发现，在防护措施生效后，仍有 53 个名称可供注册。一个多个前沿模型都认同的可注册名称，就足以围绕它构建攻击，因为攻击者只需要猜模型，而不需要猜开发者。注册表运营方已经关上了大部分门；剩下的缺口很窄，但敞开着。
同样的模式现在已经蔓延到包管理器之外。安全研究人员已经记录了攻击者注册模型幻觉出的域名，以及智能体可能编造出的仓库和 skill。每种情况下的机制都相同：模型预测一个看似合理的名称，而一个被构建为信任该预测的系统会据此行动。智能体能够触及的每一个新表面，都会成为另一个植入智能体会去拿取的名字的地方。
为什么智能体会让情况更糟
人类开发者可能会注意到可疑的包名。智能体不会。智能体会自主安装依赖项，通常没有人先阅读命令。研究人员已经演示了提示注入技术，诱骗智能体请求攻击者控制的包名，在 Cursor、Windsurf 和 GitHub Copilot 等工具上报告的成功率高达 100%。
这种组合改变了风险状况。幻觉提供名称。智能体提供执行。攻击者只需要等待两者相遇。
泄露问题也是同一个问题
公司 Glow 的一份相关报告发现，智能体在 GitHub 上暴露了超过 13,000 张内部图片，来自 300 多个组织。机制很普通：智能体及其用户把截图、图表和文档放入公共仓库，有时并不理解“公共”意味着可被搜索且永久存在。让开发者更快的同一批工具，也让他们更容易把内部材料移动到不该去的地方。
这两个问题有同一个根因。智能体会以机器速度对可能错误（幻觉名称）或敏感（内部截图）的指令采取行动。过去位于意图与行动之间的人类检查点，正是智能体移除的东西。
实际该怎么做
这些防御措施并不复杂，考虑到威胁移动得如此之快，这是好消息。
把智能体生成的每一条安装命令都视为不可信输入。安装前检查包是否存在。检查它有多旧；一个已被注册的幻觉名称会很年轻。检查发布者是否有历史记录。对于 npm 和 PyPI，快速元数据查询就能在几秒内回答这三个问题。
要求智能体在添加依赖项之前必须获得人工批准。这是单项价值最高的改变，因为它能一次性抓住幻觉名称、恶意注册和提示注入请求。它会让智能体稍微变慢，并堵上最大的洞。
保持智能体的触及范围很小。编程智能体需要仓库访问权限；它很少需要生产凭据，也不应该在没有检查的情况下让包管理器指向私有注册表。像 Socket 和 Snyk 这样的工具可以在 IDE 或 CI 流水线内自动完成注册表查询，一旦团队在多个仓库中使用智能体，这笔成本就值得花。
令人不安的一点是，这些都不是能被修补的 bug。幻觉已经内置于这些模型预测文本的方式中：它们生成下一个看似合理的名称，而不是经过验证的名称。修复必须存在于模型周围的工作流中，而这是大多数团队本周就可以开始的流程。