核心要点
攻击利用的是 AI 的幻觉而非人的手误：LLM 会自信推荐根本不存在的包名，攻击者抢注这些「幻觉包名」、植入恶意载荷，等开发者照 AI 建议安装时中招——对 AI 的信任被转化为对恶意包的信任。
规模由 PHR + 重复率决定：一项 57.6 万样本、16 个 LLM 的研究显示约 19.7% 的包推荐是幻觉，其中 43% 会跨生成重复——重复即可预测、可批量抢注。
跨生态混淆更隐蔽：约 8.7% 被幻觉出的 Python 包名恰是真实的 JavaScript 包，攻击者可跨生态抢注，人工审查极难发现。
agentic 时代成倍放大：编码 Agent 会自动执行安装命令，移除了人类审查这道最后缓冲；「安全层管得了聊天，管不了写进文件/执行的命令」。
双层防御：CI/CD 层（lockfile、包真实性/信誉校验、私有注册表 allow-list、SBOM、隔离构建）+ agentic 运行时层（install 门禁、命令拦截、能力最小化、安全姿态跟随行动）。
简要回答
包幻觉攻击（Slopsquatting）利用 LLM 会自信地推荐不存在的包：攻击者大规模测试 AI 收集高频幻觉包名，在 npm/PyPI 抢注并植入恶意载荷，等 AI 向开发者推荐、开发者执行安装时中招。研究显示约 19.7% 的包推荐是幻觉、43% 会重复出现（可预测即可批量抢注）。agentic 时代风险被放大，因为 Agent 会自动执行安装，移除了人类缓冲。防御需双层：CI/CD 层做 lockfile 锁定、安装前包真实性与信誉校验、私有注册表白名单、SBOM 审计；agentic 运行时层对 install 命令设门禁、拦截高危命令、最小化 Agent 能力。新增的关键关口是「校验这个包是否本来就不该存在」，这是经典供应链防御里没有的。
标准回答
一、攻击原理：幻觉即可被抢占的攻击面
LLM 基于「什么包名看起来合理」而非「什么包真实存在」生成代码，因此会自信地写出注册表里不存在的包名。攻击者反过来利用这一点：先用常见开发任务提示大规模测试多个模型，记录反复出现的高频幻觉包名（反复出现意味着未来大量开发者会被推荐到同一个名字）；然后在注册表抢注这些名字、植入载荷——包外观做得可信，甚至真实现所述功能，却在 import/安装钩子里执行恶意代码（窃取凭据、反向 shell、持久化）；最后坐等 AI 推荐、开发者安装。2026 年 7 月特拉维夫大学、Technion 与 Intuit 以 HalluSquatting 之名系统披露，并指出可被武器化为僵尸网络投递通道。
二、量化规模：PHR 指标
Package Hallucination Rate（PHR）= AI 推荐的不存在包数 / 推荐总数。一项覆盖 57.6 万样本、16 个 LLM 的研究给出关键数字：整体 PHR 约 19.7%（平均每五个推荐就有一个不存在）；43% 的幻觉包名会跨生成重复（这正是 Slopsquatting 可行的根本——重复意味着可预测、可批量抢注）；开源模型幻觉率约 21.7% 而 GPT-4 Turbo 低于 5%（但没有模型降到零）。还有个隐蔽变种：约 8.7% 被幻觉出的 Python 包名恰好是真实的 JavaScript 包，模型「联想对了真实的东西但搞错生态系统」，攻击者可专门跨生态抢注。
三、为什么 agentic 时代成倍放大
传统工作流里 AI 推荐幻觉包后还隔着一个人——人会犹豫、可能发现包不存在。但编码 Agent 会自己读文件、执行命令、安装包，一个被幻觉引导的 install 可能在几秒内自动执行完毕，人类审查这道缓冲被移除。2026 年 1 月研究者甚至观察到幻觉包 react-codeshift 在真实 Agent 间自然传播而无人刻意种植。结构性根源是：治理 Agent「在聊天里说什么」的安全层，并不能治理它「往文件里写什么、在终端执行什么」——安全姿态必须跟随 Agent 的行动，而非仅跟随提示词。
四、双层防御
CI/CD 层拦截「已进入代码库/构建」的恶意依赖：lockfile 强制版本锁定；安装前自动校验每个包真实存在且可信（下载量、维护历史、发布者）；私有注册表代理 + allow-list 让外部抢注包无法被解析；SBOM 持续审计；隔离构建环境阻断恶意包外联。agentic 运行时层拦截「Agent 正要自动执行」的危险命令：install 类命令显式门禁或延迟、运行时高危命令拦截、能力最小化（默认不给「自由安装 + 自由网络」组合）、把对话层安全策略延伸到运行时。一个实用快速判据：AI 推荐的包若「没听说过、下载量极低、发布时间新、发布者账号新」，极可能是幻觉包被抢注的产物——把这四个信号做成 CI 自动检查。
常见误区
⚠️ 常见踩坑
误区一：「只用知名模型、幻觉率低就安全。」 不够。即便 GPT-4 Turbo 的 PHR 也接近 5% 而非零，且攻击可行性取决于「幻觉重复率」而非单次幻觉率——只要某幻觉名反复出现就会被抢注，与用哪个模型无关。误区二：「lockfile 锁了版本就安全。」 不完全。lockfile 防的是「已锁定依赖被替换」，但新增一个 AI 推荐的依赖时 lockfile 里还没有它，第一次 install 仍可能装进恶意包；lockfile 必须与「新增依赖真实性校验」配合。误区三：「这是 npm/PyPI 该管的。」 注册表方难以区分「抢注幻觉包」和「正常注册新包」——因为幻觉包被抢注前本就不存在，没有「被仿冒的正主」可比对，防御责任必然落在使用者一侧。误区四：「给 Agent 完全权限效率最高。」 这正是风险——等于拆掉供应链攻击的最后人类缓冲，高风险操作应设门禁。
追问
追问 1：Slopsquatting 和 typosquatting、dependency confusion 的本质区别是什么？
**三者都是抢注类供应链攻击，但利用的信任来源不同。**Typosquatting 利用人的拼写错误——抢注与流行包差一两个字母的名字，等人手滑打错；dependency confusion 利用包管理器的解析优先级——抢注与企业内部私有包同名的公共包，等解析器误选公共版本；两者蹭的都是「既有的真实信任」（信任流行包、信任内部包）。Slopsquatting 则利用 AI 凭空创造的、本不存在的「需求」——攻击者不是在蹭已有信任，而是在收割 AI 制造的虚假需求，被抢注的名字在被抢注前根本不存在。这带来一个防御上的新维度：经典防御默认「这个包应该存在，只需验证它是否被篡改」，而 Slopsquatting 要求先问「这个包是否本来就不该存在」——一道经典供应链防御里没有的关口。
追问 2：「校验包真实存在且可信」具体校验哪些信号？如何避免误伤合法的新包？
**核心信号有四类：存在性、热度、历史、发布者。**存在性：包确实在目标注册表可解析（排除纯幻觉名）；热度：下载量是否达到阈值（恶意抢注包通常下载量极低）；历史：首次发布时间是否过新（刚发布就被 AI 大量推荐很可疑）、是否有持续维护与版本历史；发布者：发布者账号是否可信、是否为新注册账号、是否与该包宣称的归属一致。避免误伤合法新包的关键是分层处置而非一刀切阻断：对「四信号全绿」的包放行；对「部分可疑」的包不直接阻断，而是标记并要求人工确认或延迟到隔离环境先做动态分析（监控安装时的网络外联、文件写入、凭据读取）；同时维护组织级白名单，让确认可信的新包快速通过。这样既挡住抢注包，又不把正常的技术更新卡在门外。
追问 3：为什么说「安全层管聊天管不了执行」？这对 Agent 安全架构意味着什么？
**因为对话层的安全护栏作用在「模型的输出文本」上，而 agentic 运行的真实危害发生在「被执行的系统调用」上，两者之间存在断层。**一个编码 Agent 即使每句聊天回复都通过了内容审查，它在运行时依然可以执行 npm install 恶意包、curl 外发数据、读取 ~/.aws/credentials——这些是 shell 层面的动作，对话层护栏根本看不到也拦不住。2026 年 7 月一周内连续披露的工作流越狱、HalluSquatting、GuardFall 都指向这一点。对 Agent 安全架构的含义是：安全必须从「内容层」下沉到「执行层」——在 Agent 的 shell/文件/网络执行点设置独立的策略执行点（policy enforcement point），对命令、文件访问、网络外联做实时拦截与审计；安全姿态要「跟随 Agent 的行动」而非仅「跟随它的提示词」。本质上，Agent 需要一套类似传统主机 EDR + 权限边界的运行时防护，而不能只靠 LLM 的对齐。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习