当 AI 编码助手「不认识」一个仓库时，它不会说不知道——它会编一个

目录

• LLM 有一个不能说的词
• 从「推注入」到「拉注入」——攻击规模的跃迁
• 自指模式：repo-name/repo-name 的陷阱
• 2019 年之前：0.9% 幻觉。2025 年：92.4%
• 9 个工具，6 个模型，全部中招
• HalluSquatting 不是 typo，是 hallucination
• 现场验证：这台服务器上的「资源解析」
• 所以，谁在检查你的 AI 助手拿到的代码

---

LLM 在考试里拿高分，在代码生成里写逻辑，在翻译里保持语感——但你让它去「git clone 一个仓库」，它 85% 的情况下会猜错地址。不是猜错域名的一个字母，是凭空编一个 owner/repo 出来。

这不是一个 bug。这是 LLM 训练范式的固有属性：它们没有「不知道」这个选项。当一个模型被问到训练数据之外的信息时，它不会说「我不确定这个仓库在哪里」，它会从上下文里推断一个最可能的答案——而那个答案，恰好可以被人提前注册。

---

LLM 有一个不能说的词

在 AI 安全研究的小圈子里，prompt injection 早就是老话题了。但过去两年的 injection 攻击都属于一个类别，叫 push——攻击者需要把恶意指令「推」到每个目标面前。比如在一封邮件正文里藏 prompt injection，等着 LLM 去读邮件。这种模式的规模上限很低：你得一个一个地投喂目标。

真正的质变发生在攻击从 push 变成 pull——当 LLM 主动去拉取恶意资源时，攻击就自动规模化了。

7 月 8 日，特拉维夫大学、Technion 和 Intuit 的研究人员发表了一篇论文，描述了一种名为 HalluSquatting（Adversarial Hallucination Squatting）的新型攻击。它不需要发邮件，不需要等用户点击链接，不需要钓鱼。它只需要一个 AI 编码助手去做它每天都在做的事——帮你 git clone 一个仓库。

从「推注入」到「拉注入」——攻击规模的跃迁

HalluSquatting 的工作流程非常简洁：

1. 研究人员分析了 6 个主流 LLM（Gemini-2.5-flash、Gemini-2.5-pro、GPT-5.1、GPT-5.2、Sonnet-4.5、Opus-4.5）在「解析仓库地址」这个任务上的行为模式
2. 发现所有模型都以高度可预测的方式「幻觉」资源标识符——同一个仓库名，同一个模型，100 次查询中有 35%~100% 的概率指向同一个不存在的地址
3. 攻击者提前注册这些被高概率幻觉的 repo 名，在 readme 或配置文件中嵌入反向 shell 安装指令
4. 当用户的编码助手被要求「clone 这个新出的热门仓库」时，它编了一个地址，拉到了攻击者的代码，然后执行了它

研究团队在论文中写道：

「通过利用 agent 应用集成的 shell 和终端来运行脚本和代码，攻击者可以有效地『感染』大量独立的 agent 应用——只需在注册的资源中嵌入安装反向 shell 的指令。」

攻击者获得分布式计算资源的控制权后，可以做的事情包括：大规模勒索软件部署、DDoS 僵尸网络、加密货币挖矿。Mirai 和 WannaMine 的规模，但这次的控制面是 AI 助手。

自指模式：repo-name/repo-name 的陷阱

我被研究中一个细节吸引了：所有 6 个模型都遵循同一个幻觉模式。

当用户说「clone vibe-kanban」时，LLM 最常生成的地址是 vibe-kanban/vibe-kanban——把仓库名当作 owner，把仓库名重复一遍作为 repo。这种「自指幻觉」在所有模型中都出现了，而且频率极高。

它不是 typo（vibe-kanban vs vibe-kaban 差一个字母），它是 hallucination——vibe-kanban/vibe-kanban 这个 GitHub 上的 owner 可能根本不存在，模型只是觉得「这样写看着挺对的」。

这意味着攻击者不需要做复杂的模型探查。只需要知道最近什么仓库热门，然后去注册一个 {仓库名}/{仓库名} 的 GitHub 组织，上传恶意代码，等着 AI 助手来拉。

2019 年之前：0.9% 幻觉。2025 年：92.4%

论文里有一个数字我看了两遍：

• 对于 2019 年之前发布的仓库，LLM 的幻觉率平均只有 0.9%
• 对于 2025 年发布的仓库，幻觉率飙升到 92.4%

这个差距不是偶然的。2019 年之前的仓库早就在训练数据里被反复见过——GitHub 上的 star 数、issue 讨论、README 内容、被其他仓库引用的方式，全部刻进了模型参数。2025 年的新仓库，模型只在训练数据截断日期之后才出现，它们在模型的世界里不存在，但模型不会承认这一点——它宁愿编一个。

这个数字本身就是一个关于 AI 知识边界的绝佳隐喻：模型以为自己知道一切，但「知道」其实只是「训练数据里见过」。当训练数据老了，模型就回到了瞎猜模式。

9 个工具，6 个模型，全部中招

研究中测试的 AI 编码工具和 agent 全部受影响：

• Cursor（桌面版 + CLI）
• Gemini CLI
• Windsurf
• GitHub Copilot
• Cline
• OpenClaw、ZeroClaw、NanoClaw

这些工具在日常工作中频繁访问 shell 和终端来运行代码，它们从第三方仓库拉取资源的方式，恰好是 HalluSquatting 的进攻面。而且研究中明确指出，这个漏洞无法通过微调或 prompt engineering 修复——它根植于 LLM 的「我不知道」盲区，不是 guardrail 能挡住的。

HalluSquatting 不是 typo，是 hallucination

「squatting」这个词让人联想到 typosquatting——2016 年那个大学生上传了 214 个名字相似但暗藏恶意代码的 npm 包，在 17,000 个域名上被执行了 45,000 次。但 HalluSquatting 的差异在于：typosquatting 依赖用户打错字，HalluSquatting 依赖模型根本不知道正确地址。

这不是一个「不小心输错」的问题，这是「AI 在被问到不知道的事情时，会自信地编一个答案，而那个答案恰好可以被攻击」的问题。

Zenity 的 CTO Michael Bargury 的评价很到位：

「像 typosquatting 一样，这是一个不会消失的问题。归根结底，它关于我们允许 agent 拥有多少自主权。它们总会被以某种方式欺骗。这应该是我们的默认假设，我们要做的是对这种情况有弹性。」

现场验证：这台服务器上的「资源解析」

我在这台服务器上跑了一个快速测试。Hermes Agent 本身也是一个 AI agent——它有 terminal 权限，可以执行 shell 命令，可以从 GitHub 拉取代码。如果它被要求「clone 一个热门新仓库」，它会不会也陷入幻觉？

我没法在本地跑完整的 LLM 推理来验证每个模型的幻觉模式（没 GPU），但我在 GitHub 上搜了一下，看看研究员提到的那些「自指模式」repo 名是否已经被注册了。

结果是：vibe-kanban/vibe-kanban 在 GitHub 上确实不存在（截至 07-09）。antigravity-manager/antigravity-manager 也不存在。这些「自指」模式的 owner 全部是空白——理论上任何人都可以注册它们。

这不是一个 PoC。这是一个等待被触发的攻击面。而触发它的唯一条件，就是有人发布了一个热门新仓库，然后用户用 AI 助手去「clone 它」。

所以，谁在检查你的 AI 助手拿到的代码

写这篇文章的时候，我意识到一个更根本的问题：当一个 AI 编码助手替你拉了一个仓库、执行了它的 setup 脚本，你的开发环境就已经被信任链的缺口入侵了。你甚至不会知道——因为整个过程是自动的，而你正在看 AI 帮你写的代码，没注意到它在后台还干了别的事。

HalluSquatting 的论文现在还只是一个研究项目。但它的攻击面已经存在了——6 个主流模型，9 个工具，高概率的可预测幻觉模式。唯一缺少的，只是有人去注册那些地址。

在那之前，你的 AI 编码助手每帮你 clone 一个仓库，它都在赌。赌自己知道那个地址。