用一句话概括问题
下次 AI助手推荐了一个要安装的软件包你会真的去检查那个软件包是否存在吗？大多数开发者都不会。建议和验证之间的这种脱节正是恶意抢注软件包攻击的根源所在，也正因如此，了解恶意抢注软件包攻击的演变过程以及切实可行的预防措施，已成为应用安全和开发安全运维团队的当务之急。
什么是蹲姿攻击？
蹲姿攻击是一种变体 注册近似域名 （注册域名或软件包名称时，通过常见的拼写错误来模仿合法域名或软件包名称的做法，例如） 请求 而不是 要求（希望用户自己的拼写错误直接导致他们访问该域名），但两者的一个重要区别在于错误来源。拼写错误抢注利用的是人为的拼写错误，而拼写错误抢注攻击则利用的是大型语言模型（LLM）的错误：LLM“臆想”出一个听起来完全合法但实际上并不存在于任何公共注册表中的包名，攻击者抢先一步注册了这个名称，从而抢占了先机。
典型的蹲伏攻击背后的机制很简单，而正是这种简单性使其有效：
- 一位开发者请求人工智能助手帮助解决一个编程问题。
- 该模型生成的解决方案会导入或建议安装一个从未存在过的软件包。
- 攻击者注意到多个模型不断重复使用同一个虚构的名称，便将该软件包注册到 npm、PyPI 或其他公共注册表中，并在其中植入恶意代码。此时，虚构的名称就变成了真正的域名抢注攻击。
- 下一个收到相同建议但没有进行验证的开发人员，安装了现在已生效的软件包，这相当于在其环境中打开了一个后门。
“slopsquatting”一词是由 Python 软件基金会的常驻安全开发人员 Seth Larson 创造的，并由 Andrew Nesbitt 推广开来，用来描述这种模式：一种“软件包幻觉”变成了一种攻击途径。
非法占地演变：一项研究的好奇心如何演变成真正的威胁
值得注意的是，非法占屋行为的演变不仅仅在于其概念；更在于它从一项研究观察迅速发展成为一种有记录、可衡量的攻击类型。
2023年：第一个警告信号。 安全研究员巴尔·拉尼亚多 注意到几位法学硕士反复推荐一个名为“ 拥抱脸-cli该软件包并不存在（真正的软件包是通过以下命令安装的）： pip install -U “huggingface_hub[cli]”为了演示这种风险，他将该软件包的一个空版本上传到了一个公共注册表。短短三个月内，该软件包的下载量就超过了30,000万次，而且他没有做任何推广。这个虚构的名称甚至出现在了与阿里巴巴研究相关的一个代码库的README文件中，这很早就表明了这些“虚假”名称是如何泄露到真实文档中，并为随后出现的域名抢注攻击埋下伏笔的。
2024 年：风险从研究人员的博客文章转移到主流科技报道。 在三月2024， 注册 报道称，人工智能模型能够自信地创建软件包名称，而开发者随后会下载这些软件包，其中一些可能已被植入恶意软件。该报道的意义不在于其技术层面的揭示，而在于其所传递的信息：huggingface-cli 案例不再是孤例；它是主流科技媒体关注的、足以引起重视的模式的首次显现，而一年后，一项大规模学术研究证实了这一模式的严重性。
2025 年：首次对该问题进行严格的大规模测量。 论文“我们为您准备了一个包裹！代码生成LLM对包裹幻觉的综合分析”（Spracklen等人，发表于……） USENIX 安全研讨会研究人员测试了 16 种代码生成模型，包括商业模型（GPT-4、GPT-3.5）和开源模型（CodeLlama、DeepSeek、WizardCoder、Mistral），测试样本包含 576,000 个 Python 和 JavaScript 代码。研究结果标志着“代码抢注”现象发展的一个明确节点，使其从轶事变成了数据：
- 模特推荐的套餐中有 19.7% 并不存在。
- 开源模型出现幻觉的频率（平均为 21.7%）远高于商业模型（5.2%）。
- 在所有测试模型中，研究人员记录了超过 205,000 个独特的幻觉软件包名称，这个数量足以支持跨多个生态系统的持续抢注攻击。
这项研究的一个关键细节，或许也是域名抢注攻击加速发展而非逐渐消亡的原因，在于虚构的名称并非随机生成，而且并非每次尝试都会改变。相同的模型在面对相似的提示时，往往会重复使用相同的虚构名称，这意味着攻击者无需猜测。他们只需观察模型的行为，识别出反复出现的名称，并在真正的开发者之前注册它们即可。对这种可重复性的后续分析发现，当研究人员对相同的提示重复运行十次时，43% 的虚构包名称在每次运行中都会出现，这表明大多数虚构名称是可重复的产物，而非一次性的噪音。正是这种可重复性，使得一次性的虚构名称能够演变成可扩展的域名抢注攻击。
2026年：从孤立包裹到自主代理。 从独立包裹到自主代理。 今年出现了迄今为止最清晰的证据，表明“恶意抢注”不再局限于开发者复制粘贴建议的 pip install 或 npm install 命令。2026 年 1 月，安全研究员 Charlie Eriksen 发现，人工智能编码代理已经将指向一个名为 react-codeshift（这个名称很可能混淆了两个真实工具 jscodeshift 和 react-codemod）的虚构 npm 包的指令传播到 237 个代码仓库，并且这些代理至今仍在尝试每天安装它。Eriksen 出于防御目的，在攻击者利用该名称之前将其注册。此外，一个名为 unused-imports 的真实恶意软件包（它被虚构出来，用来代替合法的 eslint-plugin-unused-imports）在 2026 年初仍然保持着每周约 233 次的下载量，尽管 npm 已将其置于安全限制之下。这表明，即使已被标记，“恶意抢注”攻击仍能持续吸引受害者很长时间。最近，在 2026 年 7 月，研究人员描述了一种相关技术，称为“HalluSquatting”，它将 AI 幻觉与提示注入联系起来，以便 AI 编码代理在代表用户获取幻觉资源时可以被劫持，从而运行攻击者提供的代码，将 slopsquatting 的演变从被动安装风险扩展到代理开发工作流程中的主动远程代码执行向量。
为什么“氛围编码”扩大了蹲姿攻击的范围
如果人工智能生成的代码只是小众做法，那么域名抢注攻击的影响就不会太大。但事实并非如此。编码助手、自主代理以及“直觉编码”工作流程的兴起（开发者在运行代码前审查代码的次数越来越少）从两个方面切实地改变了软件攻击面，而这两方面都在加速域名抢注攻击的演变：
- 切入点不再仅仅是开发者。 过去，域名抢注攻击通常依赖于单个用户的拼写错误。而现在，错误可能源于模型内部，并传播给数百名提出类似问题的开发者，导致他们得到相同的错误建议，从而成倍扩大了域名抢注攻击的影响范围。
- 攻击面已经进一步上移。 仅仅监控人类编写的代码已经远远不够了。团队还需要监控 AI 助手建议的依赖项、它连接的 MCP 服务器，以及那些无需人工审核即可自主安装软件包的代理。传统的应用安全机制旨在审查代码库和人工审核。 commits 从未被设计用来观察开发者、人工智能和软件包注册表之间的这种新的交互，而这正是 lopsquatting 攻击现在隐藏的地方。
这并不意味着生成式人工智能本质上是不安全的。而是说它引入了一种新型的供应链风险，这种风险是传统安全工具无法应对的，因此需要遵循我们已应用于任何外部依赖项的验证原则：不要默认信任，要验证来源，并且要自动化验证过程，而不是依赖每个开发人员的记忆或警惕性。这种自动化是任何真正有效的防止恶意抢注策略的基础。
防止球队蹲守：球队今天可以做些什么
好消息是，防止滥用代码并不需要特殊的工具。它只需要系统地应用现有的依赖关系管理实践，但许多团队一旦被他们信任的人工智能“推荐”了代码，就会放松警惕。有效的滥用代码预防方法通常结合以下几点：
- 安装任何新软件包之前，请手动验证其完整性。尤其当它是人工智能助手推荐的内容时更应如此。务必确认它是否存在于官方注册表中，由谁维护，发布时间，以及下载量是否真实。养成这个习惯是任何团队都能采取的最经济有效的防止域名抢注的方法。
- 永远不要想当然地认为人工智能生成的代码默认是安全的。 一段“能运行”的代码片段并不意味着它的依赖项就是合理的。依赖项审查应该是代码审查的一部分，而不是例外。
- 使用锁文件和哈希验证 锁定确切版本，防止静默更新替换为与最初审核的软件包不同的软件包。
- 部署依赖项扫描，以标记已知 CVE 之外的风险模式异常软件包、名称与现有软件包极其相似的软件包、没有历史记录的新维护者，或者行为异常的安装脚本。一个几乎没有历史记录、名称与某个“几乎”熟悉的软件包高度相似的新发布软件包，正是目前记录的大多数恶意抢注软件包攻击的典型模式。
- 对公共登记簿应抱持同样的怀疑态度。cism 与其他未经核实的外部来源一样。 事实 点安装 or npm安装 不抛出错误并不代表合法性。
- 列车开发团队 人工智能辅助编码并不能免除验证安装内容的责任；它只是增加了一个步骤，需要将其纳入工作流程，作为任何严肃的防止恶意安装计划的一部分。
这些措施本身并不新鲜。改变的是规模：当依赖项建议不再来自 Stack Overflow 或同事，而是来自一个可能将同样的错误重复给成千上万不同开发者的模型时，人工验证虽然仍然必要，但已不足以应对。这就是为什么越来越多的团队在其内部自动化这一层防止滥用依赖项的机制。 软件组成分析（SCA工具而不是完全交给开发人员个人自律。
这是预cis伊利为什么 ASPM 平台 喜欢 西吉尼 将可疑依赖项检测功能（涵盖域名抢注、依赖项混淆和已知恶意软件）集成到同一个开源和人工智能依赖项分析中。 pipeline因此，防止恶意占用依赖项并不取决于每个开发人员每次 AI 助手建议添加新依赖项时都记得检查它。
常见问题解答
slopsquatting 攻击和 typosquatting 攻击是一样的吗？
不完全是这样。两者都涉及注册虚假的软件包名称来欺骗安装者，但错误的根源不同。“拼写错误抢注”（typosquatting）利用的是人类的拼写错误。“拼写错误抢注”（slopsquatting）攻击则利用人工智能模型虚构（生成）的软件包名称，攻击者在软件包合法存在之前就将其注册。
软件包管理器能否自动阻止此类攻击？
并非完全如此，这正是防止恶意软件包抢注不能止步于包管理器层面的原因。如果攻击者在开发者尝试安装之前注册了伪造的软件包，即使该软件包是恶意的，安装过程也会顺利完成，因为该软件包确实存在。有效的预防措施需要对软件包的来源和行为进行额外的验证。
这是否仅影响开源模型？
不。Spracklen 等人的研究发现，所有测试模型（包括商业模型）都存在幻觉，尽管发生率显著较低（5.2% 对比开源模型的 21.7%）。没有哪个模型能够完全避免这个问题，这也是为什么“垃圾代码占位”的演变与人工智能辅助编码的整体发展保持同步的原因之一。
这仅仅是理论上的风险，还是已经被利用了？
此 拥抱脸-cli 一个研究人员上传的空包在三个月内被下载了超过 30,000 次，而且没有任何推广，这表明风险不仅仅是理论上的：一个虚构的名字只需要在不同的提示中足够一致，就足以让某人将其变成真正的域名抢注攻击。
