在人工智能安全短暂的发展历程中，提示词注入已迅速成为头号威胁。大语言模型天生无法区分用户提供的合法指令与隐藏在邮件、源代码以及模型正在处理的其他第三方内容中的恶意指令。这使得恶意指令能够轻易地暗中注入，而大语言模型会毫无防备地执行。
由于无法在可信与不可信来源之间强制执行这一关键界限，AI 引擎开发者只能构建复杂的防护栏，旨在减轻损害，而非解决根本原因。
迄今为止，大多数提示词注入都属于所谓的“推送”类，即针对每个潜在受害者。例如，攻击者将恶意指令注入到个人邮件或日历邀请中。由于注入指令必须被发送（或推送）到每个特定目标，此类攻击的规模受到限制，从而阻碍了能够大规模影响整个互联网的广泛利用。
与此同时，基于“拉取”的攻击（即大语言模型主动寻找部署在网站上的对抗性提示词）仍然有限。由于无法引诱大量大语言模型访问恶意网站，这类攻击也无法规模化。
幻觉抢注登场
现在，研究人员设计出了一种改变这一切的“拉取”式攻击。研究人员将这种新攻击命名为“幻觉抢注”，它有可能组建大规模僵尸网络、执行大规模分布式拒绝服务攻击，并大规模感染设备，这在提示词注入攻击中尚属首次。该攻击针对 AI 编程助手和智能体，包括 Cursor、Cursor CLI、Gemini CLI、Windsurf、GitHub Copilot、Cline、OpenClaw、ZeroClaw 和 NanoClaw，这些工具均易受影响。在执行日常任务的正常过程中，这些助手和智能体会例行地从代码仓库和注册表中拉取代码及其他资源。
幻觉抢注威胁模型。
图片来源：Spira 等人。
幻觉抢注威胁模型。图片来源：Spira 等人。
对抗性幻觉抢注（HalluSquatting）简称自“对抗性幻觉抢注”，它建立在大语言模型固有的幻觉倾向之上，即模型会凭空捏造托管在代码仓库和注册表中的资源标识符。这种攻击针对的是编码智能体和编码助手，因为它们通常会访问高权限命令行，从第三方资源运行代码。攻击者通过预测大语言模型最可能幻觉出的标识符，然后抢先注册这些标识符，并在其中植入安装反向 shell 或其他恶意软件的指令，从而无需逐个锁定目标，就能不加区分地感染大量设备。
研究人员在周三发表的一篇论文中写道：“这种攻击的可扩展性，使得攻击者只需瞄准热门资源，就能以最小的代价入侵大量用户，从而最大限度地提高被抢注资源被检索到的可能性。通过利用智能体应用中的集成 shell 和终端来运行脚本和代码，攻击者可以在其注册的资源中嵌入安装反向 shell 的指令，从而有效地‘感染’许多独立的智能体应用。”
凭借大规模控制分布式设备的能力，HalluSquatting 有可能实现以往通过提示词注入无法达成的各种目标。大规模勒索软件攻击，以及用于分布式拒绝服务攻击或加密货币挖矿的大型僵尸网络，就是两个这样的例子。
名称中的“抢注”（squatting）一词借鉴了“域名抢注”（typosquatting）的概念，后者是指某个域名、仓库包或其他资源标识符刻意模仿热门资源的名称，以诱骗潜在用户访问或安装它。域名抢注最早在 2016 年引起广泛关注，当时一名大学生向 PyPI、RubyGems 和 NPM 仓库上传了 214 个精心伪装、名称与合法包极为相似的恶意包。结果是：这些冒牌代码在超过 17,000 个独立域名上被执行了 45,000 多次，其中超过一半的域名被赋予了全能的超级管理员权限。自那以后，域名抢注攻击便愈演愈烈。
大语言模型不知道如何说“我不知道”。
HalluSquatting 的起点在于大语言模型无法准确识别用户指定的资源位置。例如，当开发者指示编码智能体克隆一个热门的新仓库时，大语言模型有高达 85% 的概率会幻觉出错误的位置。当克隆一个热门的“技能”（即赋予智能体专业能力和领域知识的指令、脚本或资源）时，幻觉发生的概率可达 100%。HalluSquatting 聚焦于热门资源，是因为这些资源并未包含在大语言模型的训练数据中，同时它们会在短时间内获得大量下载。
研究人员表示，大语言模型无法提供正确位置是一个固有缺陷，源于训练偏差或对当前上下文中指令的误解。这意味着，当用户提示编码助手克隆一个仓库或技能时——例如以“clone repo name”或“install skill name”的形式——机器人常常会导航到错误的位置去获取它。
这些幻觉不仅不可避免，而且出现在所有六大主流大语言模型的基础层面，包括 Gemini-2.5-flash、Gemini-2.5-pro、GPT-5.1、GPT-5.2、Sonnet-4.5 和 Opus-4.5。此外，这些大语言模型最常幻觉出的错误位置，可以提前轻松预测。这六大模型在将提示词中的仓库或技能名称解析为仓库或技能仓库中的官方名称时，都遵循着共同的模式。
大语言模型遵循多种幻觉模式。HalluSquatting 所利用的模式被描述为自我指涉型。所有六大模型都会生成 repo-name/repo-name 这样的路径段，将仓库名称视为所有者。利用这一模式无需对模型进行探测。
该表格展示了在 100 次查询中，每个（目标仓库，基础大语言模型）组合下最常被模型幻觉的 owner/repo 候选。Owner 着色说明：黄色 = 真实的 GitHub owner，蓝色 = 可注册的抢注（该 owner 在 GitHub 上不存在），红色 = 误导（真实但非预期的 owner），紫色 = 无法注册为 GitHub 用户名的占位符字符串。⋆ 标记表示自指幻觉（owner == 仓库名称）。
来源：Spira 等人。
该表格展示了在 100 次查询中，每个（目标仓库，基础大语言模型）组合下最常被模型幻觉的 owner/repo 候选。Owner 着色说明：黄色 = 真实的 GitHub owner，蓝色 = 可注册的抢注（该 owner 在 GitHub 上不存在），红色 = 误导（真实但非预期的 owner），紫色 = 无法注册为 GitHub 用户名的占位符字符串。⋆ 标记表示自指幻觉（owner == 仓库名称）。来源：Spira 等人。
有趣的是，大语言模型能正确解析 2019 年之前发布的仓库，平均幻觉率仅为 0.9%。而对于 2025 年发布的仓库，这些大语言模型编造 slug 的平均幻觉率则高达 92.4%。
一旦攻击者识别出最可能被模型幻觉的名称，他们就会寻找那些可以注册的名称。然后，他们会上传一个模仿热门资源的仓库或技能。在该仓库或技能内部，README 文件或其他位置包含一段文本。这段文本包含一条指令，指示应用在 LLM 用户的机器上安装一个反向 shell。或者，攻击者也可以直接包含安装该 shell 所需的代码。无论哪种情况，编码助手或智能体都会利用其对命令窗口的访问权限来执行该指令。
大规模利用大语言模型
研究人员包括：特拉维夫大学的 Aya Spira、Elad Feldman、Avishai Wool 和 Ben Nassi，以色列理工学院的 Stav Cohen，以及 Intuit 的 Ron Bitton。周三，他们在此处发表了研究成果。在他们的论文中，他们写道：
通过利用智能体应用中的集成 shell 和终端来运行脚本和代码，攻击者可以在其注册的资源中嵌入安装反向 shell 的指令，从而有效地“感染”多个独立的智能体应用。获取攻击者控制下的分布式计算资源，为多种高影响后果打开了大门，使攻击者能够实现各种目标。例如，能够攻破带有终端的 LLM 应用，使得攻击者可以扩大对不同网络的勒索软件攻击规模，以实现经济利益最大化。或者，攻击者可以将被攻陷的机器聚合到一个僵尸网络中，用于执行依赖大量计算能力的任务，包括 (1) 大规模加密货币挖矿（例如 Smominru、WannaMine），或 (2) 对受害者执行分布式拒绝服务（DDoS）攻击（例如 Mirai）。
HalluSquatting 已经引起了未参与该研究的其他 AI 安全研究人员的兴趣。
“这是一项非常酷的研究，而且威胁非常真实，”安全公司 Zenity 的 CTO Michael Bargury 在一封电子邮件中写道。“就像域名抢注一样，这是一个不会消失的问题。归根结底，这关乎我们赋予智能体的自主程度。它们总会以某种方式被欺骗。这应该是我们的假设，并且我们应该对此具备韧性。”
独立研究员 Johann Rehberger 写道：
有趣的是，这表明 LLM 的资源解析可能成为一个攻击路径，攻击者可以先探测模型，找出高概率的幻觉候选（如仓库名称、技能标识符等），然后进行抢注，等待智能体解析并使用它们。
但主要的一点是，他们找到了一种巧妙的技术来发现那些模型更可能使用或混淆的资源名称。这可能意味着在现实环境中，许多智能体会落入此类攻击的陷阱。
AI 工具制造商常常夸大其平台的便捷性和效率。营销人员声称，这些平台通过自动化和简化繁琐任务来减轻工作负担。但对于那些可能毁掉整个项目的固有缺陷，他们却讳莫如深。像“HalluSquatting”这样的攻击有力地提醒我们，某些所谓的效率提升是被夸大了的，因为归根结底，用户必须反复核对项目中每个引用资源的位置等细节。这也提供了一个警示：当人们过度依赖AI助手时，可能会产生意想不到且可能极其严重的后果。
In the brief history of AI security, the prompt injection has quickly become the top threat. Large language models are inherently unable to distinguish between legitimate instructions provided by users and malicious ones sneaked into emails, source code, and other third-party content the models are processing. This makes it trivial to surreptitiously inject malicious commands that the LLM readily follows.
With no way to enforce this crucial boundary between trusted and untrusted sources, AI engine developers are left to erect elaborate guardrails designed to mitigate the damage rather than solve the root cause.
To date, most prompt injections have fallen into a class known as push, in which each potential victim is targeted. For example, the adversary injects malicious instructions into an individual email or calendar invitation. Because the injection must then be sent (or pushed) to each specific target, the scale of the attack is limited, hampering mass exploits that hit the Internet at large.
Meanwhile, pull-based attacks, in which an LLM actively seeks out the adversarial prompts planted on websites, remain limited. With no way to lure large numbers of LLMs to a malicious site, these sorts of attacks don’t scale either.
Enter HalluSquatting
Now, researchers have devised a pull-based attack that changes all that. A new attack the researchers have named HalluSquatting has the potential to assemble massive botnets, perform large-scale DDoSes, and infect devices at scale, a first for prompt-injection attacks. The attack works against AI coding assistants and agents, including Cursor, Cursor CLI, Gemini CLI, Windsurf, GitHub Copilot, Cline, OpenClaw, ZeroClaw, and NanoClaw, which are all susceptible. In the normal course of performing day-to-day activities, these assistants and agents routinely pull code and other resources from repositories and registries.
The HalluSquatting threat model.
Credit: Spira et al.
The HalluSquatting threat model. Credit: Spira et al.
Short for adversarial hallucination squatting, HalluSquatting is built on an LLM’s inherent tendency to hallucinate the resource identifiers hosted in repositories and registries. It works against coding agents and assistants, which commonly access high-privilege command lines to run code from third-party resources. By predicting the identifiers LLMs are most likely to hallucinate and then registering and seeding them with instructions to install reverse shells or other malicious wares, the attack can indiscriminately infect massive numbers of devices without having to target each one.
“The scalable property of the attack enables the attacker to compromise a large number of users with minimal effort by targeting popular resources, thereby maximizing the likelihood that the squatted resource will be retrieved,” the researchers wrote in a paper published Wednesday. “By exploiting integrated shells and terminals of agentic applications to run scripts and code, attackers can effectively ‘infect’ many independent agentic applications by embedding instructions to install reverse shells in the resources the attackers register.”
With the ability to take control of distributed devices at scale, HalluSquatting has the potential to achieve various objectives not previously possible with prompt injections. Large ransomware campaigns and large botnets for use in DDoSes or cryptocurrency mining are two such examples.
The “squatting” part of the name is an invocation of “typosquatting,” in which a domain, repository package, or other resource identifier closely mimics the name of a popular one in hopes of luring potential users to visit or install it. Typosquatting first gained widespread attention in 2016 when a college student uploaded 214 booby-trapped packages to the PyPI, RubyGems, and NPM repositories that closely mimicked names of legitimate packages. The result: The imposter code was executed more than 45,000 times on more than 17,000 separate domains, and more than half were given all-powerful administrative rights. Typosquatting attacks haveflourishedeversince.
LLMs don’t know how to say “I don’t know.”
The starting point for HalluSquatting is the inability of LLMs to accurately identify the location of a resource specified by the user. When a developer, for instance, instructs a coding agent to clone a popular new repository, the LLM hallucinates its correct location up to 85 percent of the time. When cloning a trending “skill,” a form of instruction, script, or resource that gives agents specialized capabilities and domain expertise, hallucinations can occur 100 percent of the time. HalluSquatting focuses on trending resources because they aren’t included in the LLM training. They also receive large numbers of downloads over a short period of time.
The researchers say the inability of LLMs to provide the correct location is an inherent flaw that arises from training biases or from misinterpretations of instructions within the current context. That means when a user prompts the coding assistant to clone a repository or skill—in the form of, say, “clone repo name” or “install skill name”—the bot frequently navigates to the wrong location to retrieve it.
Not only are these hallucinations inevitable, but they also occur at the foundational level of all six of the major LLMs, including Gemini-2.5-flash, Gemini-2.5-pro, GPT-5.1, GPT-5.2, Sonnet-4.5, and Opus-4.5. Additionally, the most commonly provided incorrect locations that these LLMs hallucinate are easy to predict in advance. All six LLMs follow common patterns when resolving the repository or skill name in a prompt with its official name in a repository or skill repository.
LLMs follow various hallucination patterns. The one HalluSquatting exploits is described as being self-referential. All six models produce repo-name/repo-name slugs that treat a repository name as the owner. Exploiting the pattern requires no model probing.
Table depicting the most frequently hallucinated owner/repo candidate per (target repository, foundational LLM) combination over 100 queries. Owner shading: yellow = real GitHub owner, blue = registrable squat (owner does not exist on GitHub), red = misdirection (real but unintended owner), purple = placeholder string that cannot be registered as a GitHub username. A ⋆ marks self-referential hallucinations (owner == repository name).
Credit: Spira et al.
Table depicting the most frequently hallucinated owner/repo candidate per (target repository, foundational LLM) combination over 100 queries. Owner shading: yellow = real GitHub owner, blue = registrable squat (owner does not exist on GitHub), red = misdirection (real but unintended owner), purple = placeholder string that cannot be registered as a GitHub username. A ⋆ marks self-referential hallucinations (owner == repository name). Credit: Spira et al.
Interestingly, the LLMs correctly resolve repositories published before 2019 with a low mean hallucination rate of just 0.9 percent. The same LLMs fabricate slugs for repositories published in 2025 with a mean hallucination rate of 92.4 percent.
Once an attacker has identified names that are most likely to be hallucinated, they search for ones that can be registered. Then they upload a repository or skill that mimics the trending resource. Buried inside the repository or skill is text inside a readme file or elsewhere. The text contains an instruction for the app to install a reverse shell on the LLM user’s machine. Alternatively, the attacker can simply include the code required to install the shell. In either case, the coding assistants or agents use their access to command windows to comply.
Exploiting LLMs at scale
The researchers are: Aya Spira, Elad Feldman, Avishai Wool, and Ben Nassi of Tel Aviv University, Stav Cohen of Technion, and Ron Bitton of Intuit. On Wednesday, they published their research here. In their paper, they wrote:
By exploiting integrated shells and terminals of agentic applications to run scripts and code, attackers can effectively “infect” many independent agentic applications by embedding instructions to install reverse shells in the resources the attackers register. Gaining access to distributed computational resources under attacker control opens the door to several high impact outcomes allowing attackers to achieve various goals. For example, having the ability to compromise LLM applications with terminals allows the attacker to scale the number of ransomware attacks on different networks to maximize financial gain. Alternatively, attackers can aggregate compromised machines into a botnet and use it for tasks that rely on substantial computing power, including (1) large-scale cryptocurrency mining (e.g., Smominru, WannaMine) or (2) performing distributed denial of service (DDoS) attacks against victims (e.g., Mirai).
HalluSquatting is already receiving interest from fellow AI security researchers not involved in the study.
“This is very cool research, and the threat is very real,” Michael Bargury, CTO of security firm Zenity, wrote in an email. “Like typosquatting, it’s a problem that’s not going away. At the end of the day, it’s about the level of agency we allow our agents. They are going to get fooled one way or the other. That should be our assumption, and we should be resilient to that.”
Independent researcher Johann Rehberger wrote:
What’s interesting is that it shows that LLM resource resolution can become an attack path and an attacker can first probe models to find high-probability hallucinated candidates (like repo names, skill identifiers,etc) to squat and wait for agents to resolve and use them.
But the main point is that they found a cool technique to find resource names that are more likely by models to be used/confused with. And that could mean many agents falling for such attacks in the wild.
AI tool makers frequently exaggerate the convenience and efficiency of their platforms. Marketers claim the platforms lighten workflows by automating and streamlining tedious tasks. They are much more reticent about the inherent flaws that can torpedo an entire project. Attacks like HalluSquatting provide a potent reminder that some of the efficiencies are exaggerated since, at the end of the day, users must double-check details such as the location for each resource incorporated into a project. It also provides a cautionary lesson on the unintended and potentially dire outcomes that can result when people rely too heavily on AI assistants.