llms.txt 本是写给AI的说明书，如今成了攻击面

llms.txt 是 2024 年提出的一个网页规范：在网站根目录放一个简短的 Markdown 文件，向 AI 智能体说明站点用途、并指引它们到哪里获取更详细的资料。两年之后，安全研究人员证明，这个本为 AI 准备的说明文件，正悄然成为一类全新的攻击面——因为受害者甚至不需要被入侵。

2026 年 8 月底，以色列安全创业公司 Pandex（由前 8200 部队成员 Alon Hertz 领导）发布研究，展示了大型企业发布的机器可读文件如何被用来武器化、反噬读取它们的 AI 智能体。这项被 Ars Technica 与 Cybernews 报道的研究，核心指向一个结构性弱点：llms.txt 文件常常引用根本不存在的软件包名与域名。这些引用不是错别字仿冒，而是拼写正确、却从未被注册的一手名称。

问题的规模是具体的。在 Cybernews 的另一项独立调查中，研究人员扫描了大型公司（科技巨头、金融科技企业、国防承包商）发布的 llms.txt 文件，发现 237 处引用了不存在的包和域名。由于 AI agent 将 llms.txt 视为操作输入而非被动文本，攻击者只需注册这些未注册的名称，就能诱使 agent 从看似官方的来源安装恶意代码。

四分钟：从文件到代码执行

Pandex 扫描了大型组织公开的 llms.txt / llms-full.txt 文件，发现数百处悬空引用——指向 PyPI、npm、RubyGems、NuGet、crates.io、Packagist 等仓库中无人认领的安装命令，以及已过期域名和被弃用的部署子域名。随后研究者做了任何攻击者都会做的事：注册其中几个无人认领的名字，并挂上回连信标。

结果触目惊心。第一家回连的财富 500 强企业在四分钟内完成呼叫，其余企业在一小时内陆续响应。进程溯源显示，执行代码的并非粗心的人类，而是被授权的 AI 编程智能体——Anthropic Claude、OpenAI Codex 与 Nous Research Hermes——它们把 llms.txt 的指引当作操作指令，而非不可信文本。正如 Pandex 报告所言：「智能体不区分网页与命令。它读到的一切都是输入，而每一个输入都可能是指令。」

Hertz 则一针见血地概括了问题根源：「信任模型已经破碎。智能体把厂商文档当作真理，从不质疑——监督它们的人类也一样。」

现实案例：恶意包潜伏在 Clerk 自家文档点名的位置

这类攻击并非纸上谈兵。2026 年 7 月，开源安全生态记录了一起真实案例：身份认证服务商 Clerk 在面向智能体的文档中，给出了裸命令 npx clerk-next-fix-auth-protection——该辅助程序被打包在作用域包 @clerk/eslint-plugin 内。由于该名称在公共 npm 仓库中解析，第三方早已悄然注册了它。最终出现的恶意包被记录为 MAL-2026-11069，2026 年 7 月 24 日发布，恶意版本为 7.7.7 与 8.8.8，被 OpenSSF Package Analysis 与 OSV.dev 标记，可窃取运行机器的用户名、主机名、工作目录与时间戳。全程未入侵任何目标服务器——漏洞完全存在于一份指向无人认领名称的文档里。

插件层：WordPress 生态的前沿

围绕 llms.txt 的生态正在累积自身暴露面。2026 年 4 月，WordPress 的 Website LLMs.txt 插件曝出两个 CVE：CVE-2026-6711 是该插件 8.2.6 及以下版本中 tab 参数的反射型 XSS，CVSS 6.1；CVE-2026-6712 是存储型 XSS 变体，CVSS 4.4，均由 Wordfence 作为 CNA 分配。单看它们危害有限，但合在一起说明：llms.txt 供应链已包含一层大多数站长从不审计的生成插件。

2026 年 6 月 webhosting.today 对托管行业的普查印证了这一点。在接受调查的 736 个托管行业域名中，110 个发布了 llms.txt——其中没有一个对文件签名或校验，也没有一个对篡改进行监控。110 个文件里有 28 个由 SEO 插件自动生成，意味着文件完整性实际上等同于插件更新渠道的完整性：生成器被攻陷，恶意指引就会传播到每一个使用它的站点。而规范本身不含任何安全条款——没有认证、没有签名、没有验证机制。

NameOcean 对同一审计数据的分析，将暴露面归纳为三类攻击。信息泄露——文件结构和内容可能暴露基础设施细节、插件配置与内部命名规范。AI 操纵——由于 agent 逐字消费 llms.txt，被篡改的文件可注入指令，潜移默化地引导 AI 对网站、服务或客户的理解。供应链投毒——28 个由插件自动生成的文件形成传播路径：攻陷插件更新通道，恶意指令即可扩散至所有使用该插件的站点。

采用悖论

一个悖论让局面雪上加霜。llms.txt 的采用率持续上升——Originality.ai 追踪了 300 万个站点：2025 年 6 月的 4,088 个文件增长至 2026 年 5 月的 36,120 个，增幅 8.8 倍；2026 年 5 月发布的 Google Lighthouse 13.3 甚至在新默认开启的「Agentic Browsing」类别中增加了对该文件的审计项，实际上鼓励网站发布它。但 Google Search 同样明确表态：该文件不影响排名，也不影响 AI Overviews。Google 的 John Mueller 早在 2025 年 6 月就说过「目前没有任何 AI 系统使用 llms.txt」。Ahrefs 对 137,210 个域名服务器日志的分析也显示，97% 的已发布文件未收到任何 AI 爬虫请求。

「发布有激励、维护无激励」的组合，让文件在沉默中腐烂：链接失效、描述过时，而人类、可用性监控与搜索引擎都毫无察觉。当攻击者最终篡改这类文件时，企业既没有可用于检测变更的基线，也没有能暴露异常的合法流量——这无异于一场没有目击者的网站涂鸦。

更广泛的背景：无人守卫的信任锚点

风险并不止于 llms.txt 本身。OWASP 于 2026 年 8 月 4 日发布了第三版 LLM 应用 Top 10，提示注入连续第三年位列第一大威胁。llms.txt 并非经典意义上的提示注入，但它是一个相邻的攻击面：它是被 AI agent 当作可信指令处理的不受信任内容。该文件正处于供应链安全与提示注入的交汇处——一个传统应用安全框架从未被设计来覆盖的领域。

暴露在双向累积。托管行业普查显示，110 个已部署文件没有一个配备能检测篡改的控制措施——没有文件完整性监控、没有版本锁定、没有变更告警。与此同时，agent 把读到的文件当作权威指令，因此攻击对传统防护完全隐形：从官方域名发起 HTTPS 抓取、再从官方仓库安装软件包、由被授权智能体执行——这一链路在端点检测与代理监控看来毫无异常。受信公司发布的内容，被 AI 智能体当作指令来执行——漏洞不在对文件的注入，而在于文件本身作为一个无人验证的信任锚点。

需要改变什么

安全研究者正在收敛出一套缓解方案：将 llms.txt 视作安全敏感资产并做文件完整性监控（计算哈希、变更告警、记录访问）；发布前审查每一个外部引用——237 个未注册包引用本可避免，悬空引用是最易封堵的路径；预先注册自家文档会指向的包名与域名；在智能体执行来自网页内容的 shell 命令前加入所有权验证或人工审批；并加固规范本身——2026 年 8 月发布的 llms.txt v2 改善了机器可读的链接能力，却依然没有建立信任模型，「谁来验证智能体信任的那份文件」，答案仍然悬而未决。

这个文件是为让公司对机器可读而生的。它做到了。问题在于，它也让公司变得脆弱。