Claude, Codex, and Hermes installed unowned code inside corporate networks

Claude、Codex 和 Hermes 在企业网络中安装了未经授权的代码 - Ars Technica

AI 代理再次失控

Claude、Codex 和 Hermes 在企业网络中安装了未经授权的代码

在企业文档中发现了 227 条安装命令，这些命令指向无人拥有的代码。

Dan Goodin

–

2026 年 8 月 27 日 上午 10:00

|

156

图片来源：Aurich Lawson

按钮

文本设置

面板

故事文本

大小

小号

标准

大号

宽度

*

宽屏

链接颜色

橙色

• 仅限订阅者

了解更多

最小化到导航栏

超过 100 个网站的文档文件正在引用可能包含危险的可执行内容，当被许多 AI 代理访问时，这些内容会自动安装。数十家公司（其中一些是财富 500 强企业）已执行了概念验证代码。至少有一个配置错误的网站正在将访客（无论是人类还是 AI）引导至实时恶意软件。

潜在的危险内容位于 llms.txt 和 llms-full.txt 文件中，这是网站正在采用的一种新惯例，用于提供网站内容及其高层结构的机器可读摘要。这些文件相当于指导搜索引擎如何索引网站内容的 robots.txt 标准。Google Lighthouse（一个帮助网页开发者的工具）在此处有更多相关信息。Cloudflare 正确配置的 llms.txt 和 llms-full.txt 文件可在此处和此处查看。

研究人员是如何发现的

以色列一家隐身初创公司的研究人员扫描了 6,214 个属于国防承包商、财富 500 强企业和大型科技公司的实时域名。在他们发现的 8,265 个 llms.txt 和 llms-full.txt 文件中（许多网站同时托管了 llms.txt 和 llms-full.txt 文件），有 120 个文件分别来自不同网站，指向一个或多个未注册的代码包或域名。为了测试当 AI 代理处理此类文件时会发生什么，研究人员注册了其中几个未被认领的名称，并托管了这些代码包，任何执行它们的机器都会向他们的服务器发出连接请求。一小时内，研究人员就收到了来自一家财富 500 强公司的回拨响应。随着时间推移，他们又收到了数十个类似的响应，其中一些来自更多财富 500 强公司，另一些则来自初创公司。他们的信标还记录了每个安装操作的父进程链，最终揭示出 Claude、OpenAI 的 Codex 和 Nous Research 的 Hermes 等编码代理参与其中。Anthropic、OpenAI 和 Nous Research 在文章发表时未回应评论请求。

“信任模型已经崩溃，”研究人员之一 Alon Hertz 在采访中写道。“代理将供应商文档视为事实，不会质疑它们，监督它们的人类也是如此。代理 AI 的使用正在爆炸式增长，代理正在渗透到每一层——SaaS、云和终端。随着代理数量的增加，供应链的攻击面也在扩大，而目前的防护措施无法覆盖这一点。”

这些文件配置错误，因为它们列出了来自 PyPI、npm 和其他注册表中不存在的软件包，并附有安装说明。例如，一个文件包含提示“安装：pip install [研究人员要求删除]”。另一个文件显示：“npm install [研究人员要求删除]”。由于这些软件包名称未在注册表中注册，攻击者可以注册同名软件包，用以托管勒索软件或其他有害软件包。当具有运行 shell 命令权限的编码代理将文件视为权威的设置文档时，就会出现此漏洞。一些 AI 代理随后会下载并运行该软件包。在其他情况下，LLM 文件指向不存在的域名。例如，其中一处显示：“作为为 [研究人员要求删除] 应用程序编写集成测试的示例，您可以使用 [Citrus] 测试框架。”攻击者随后可以注册该网站，并在其中植入恶意指令。

研究人员的 PoC 演示表明，编码代理确实执行了类似操作，其中包括一些运行在世界最强大公司内部的代理。这种威胁并非理论上的假设，至少已有一起活跃攻击正在利用这种混淆。研究人员发现，一个 LLM 文件托管在合法网站 clerk.com 上，其中包含文本：“npx clerk-next-fix-auth-protection”。与常规安装命令不同，npx 可以将软件包下载到 npm 的缓存中，并在不将其添加到项目依赖清单的情况下执行其暴露的二进制文件。研究人员很快发现，有人已经占用了此前空置的名称，并用其托管了实时恶意软件。

Clerk 已经解决了这个问题。该公司还指出，如果代理已经安装了软件包 @clerk/eslint-plugin 中包含的二进制文件，则不存在威胁。否则，恶意软件包将被安装。尚不清楚这种混淆是否已导致实际感染。

新发现的威胁再次提醒人们 AI 的基本局限性。LLM 无法在用户直接输入到提示中的真实指令与在不可信第三方来源中找到的内容之间划出可靠界限。除非设置好适当的防护措施，否则模型在检索到的内容中遇到的指令与用户输入的任何内容一样，都可能被立即执行。这种迄今为止无法解决的缺陷导致了提示注入攻击。

研究人员周四写道：“代理无法区分页面和命令。它读取的任何内容都是输入，任何输入都可能是指令。这意味着代理现在被设计为消费的全部公开数据集，已悄然成为执行表面——而其中几乎没有数据能提供我们对实际代码所施加的完整性保证。”

研究人员发现的 120 个配置错误文件中包含 227 条安装不存在软件包或查看未注册域名的指令。尚不清楚这些错误条目是如何出现的。在许多情况下，这些条目早于 AI 时代，最初包含在网站上的非 LLM 文件中。这表明这些错误条目是由人类手动生成的。研究人员怀疑其他条目是由 AI 生成的，这些 AI 要么出现了幻觉，要么像浏览文件的 AI 代理一样，无法区分合法和非法指令。

数据与代码之间的边界正在崩溃

在周四的帖子中，研究人员进一步解释：

安全控制措施可能无法发现这一点，因为系统依赖的每一个信号都指向错误的方向。当AI代理遇到llms.txt文件时，它看到的是通过HTTPS在公司官方域名上提供的文件，采用专为AI设计的标准格式，由公司本身或其信任的合作伙伴发布。代理没有理由对其中的任何内容产生疑问。该文件本身就是权威来源——这正是它的全部目的。因此，当文件中出现“pip install internal-tool”时，代理不会暂停检查internal-tool是否真的属于公司，不会验证PyPI上的命名空间，也不会注意到文档链接指向一个三个月前已过期的域名。它只是执行文件中的指令。信任链也是传递性的。llms.txt文件无需位于《财富》500强公司的自有网站上。代理可以从受信任的第三方获取上下文——合作伙伴的文档、供应商的SDK参考、社区项目的设置指南。如果代理信任该第三方，而该第三方的文件指向一个未被认领的包，信任链的运作方式是一样的。端点检测也没有任何反应。对于任何EDR或代理来说，这看起来就像开发者正在运行一个合法的包管理器：从pypi.org（一个企业代理早已允许的域名）执行pip install操作，而该编码代理是公司特意安装的父进程。没有异常，没有警报。失败发生在指令与执行之间的间隙。端点可能根本没有机会，因为它从未提出正确的问题。

这项研究有力地证明，在AI时代，数据与可执行代码之间曾经清晰的界限正在消失。只要代理能够处理任何内容，它都可能在获得执行命令的权限后将其视为潜在的指令。

研究人员写道：“‘办事员’案例是最清晰的证明。该指令看起来完全像供应商会发布的内容——因为它就在供应商自己的指令文件中。唯一缺失的是注册表中的名称。除了没有人想到要检查的那一层，所有信任层级都完好无损。”

这一新暴露问题的根源与提示注入的根本原因相同。然而，这种较新的弱点影响范围更广。

赫兹解释道：“在提示注入中，有人故意植入恶意指令。而在这里，指令本身可能完全无害，且来自合法来源——一家真实公司的文档——在编写时并没有涉及任何恶意行为。危险出现在稍后，当它指向的包或域名被遗弃，而其他人又声称拥有它时。”

这意味着，问题的影响范围远超仅限于网站上托管的llms.txt和llms-full.txt文件。无论显性还是隐性，指令几乎存在于代理遍历的每个地方。这种逐渐消失的边界，加上大型科技公司急于将AI部署到所有场景，让人对未来感到不安，但无疑会让安全人员（或取代他们的AI代理）忙得不可开交。

高级安全编辑

Dan Goodin是Ars Technica的高级安全编辑，负责监督恶意软件、计算机间谍活动、僵尸网络、硬件黑客攻击、加密和密码方面的报道。在空闲时间，他喜欢园艺、烹饪和关注独立音乐场景。Dan目前常驻旧金山。您可以在Mastodon的此处和Bluesky上关注他。通过Signal联系他，联系方式为DanArs.82。

156条评论