AI编码智能体的文档投毒供应链攻击

针对人工智能供应链攻击甚至不需要恶意软件……只需发布被污染的文档即可。

针对 Context Hub 的概念验证攻击表明，其内容过滤机制并不完善。一项帮助编码人员及时了解其 API 调用情况的新服务，可能会造成供应链的巨大漏洞。

两周前，人工智能企业家、斯坦福大学兼职教授吴恩达推出 Context Hub，这是一项为编码代理提供 API 文档的服务。

吴恩达在领英上发帖写道：“编码代理经常使用过时的API，并且会错误地使用参数。例如，当我让Claude Code调用OpenAI的GPT-5.2时，它使用的是较旧的聊天补全API，而不是较新的回复API，即使新的回复API已经发布一年了。Context Hub解决了这个问题。”

安全研究人员发现，这项服务似乎也提供了一种通过简化软件供应链攻击来欺骗编码代理的方法：文档门户网站可以用来向人工智能代理植入恶意指令。

Mickey Shmueli 是另类精选服务 lap.sh 的创建者，他发布了一个概念验证攻击，证明了这种风险。

Shmueli 在一篇解释性博文中写道：“Context Hub 通过 MCP 服务器向 AI 代理提供文档。贡献者以 GitHub pull request 的形式提交文档，维护者合并这些请求，代理按需获取内容。整个流程在每个阶段都没有进行任何内容清理。”

开发者社区早就知道，人工智能模型有时会虚构软件包名称，安全专家已经证明，可以通过在虚构的软件包名称下上传恶意代码来利用这一缺陷。

Shmueli 的 PoC 通过在文档中建议虚假依赖项来省去产生幻觉的步骤，编码代理随后将这些虚假依赖项合并到配置文件（例如 requirements.txt）和生成的代码中。

攻击者只需创建一个拉取请求（即向代码仓库提交更改），如果该请求被接受，则投毒就完成了。目前来看，这种情况发生的概率相当高。在 97 个已关闭的拉取请求中，有 58 个已被合并。

Shmueli在给The Register 的一封电子邮件中表示：“审核流程似乎更注重文档数量而非安全审查。文档 PR 合并速度很快，有些甚至是核心团队成员自己提交的。我在 GitHub 代码库中没有发现任何证据表明提交的文档中存在自动扫描可执行指令或软件包引用的机制，但我无法确定内部究竟发生了什么。”

他说他没有提交 PR 来测试 Content Hub 的响应，“因为公开记录显示安全方面的贡献并未得到重视”。他还列举了几个与安全问题相关的未解决问题和拉取 请求作为证据。

Shmueli在他的帖子中写道：“代理从[Context Hub]获取文档，读取被污染的内容，然后构建项目。响应看起来完全正常。代码运行正常。指令清晰。没有任何警告。”

考虑到这不过是人工智能模型尚未解决的风险——间接提示注入——的一种变体，这一切并不令人意外。人工智能模型在处理内容时，无法可靠地区分数据和系统指令。

为了进行概念验证，我们创建了两个恶意文档，一个用于 Plaid Link，一个用于 Stripe Checkout，每个文档都包含一个虚假的 PyPI 包名称。

在 40 次运行中，Anthropolic 的 Haiku 模型每次都会将文档中提到的恶意软件包写入项目的 requirements.txt 文件，且输出结果中没有任何提示。该公司的 Sonnet 模型表现稍好，在 48% 的运行中（19/40）发出警告，但仍有 53% 的运行（21/40）将恶意库写入 requirements.txt 文件。

这家人工智能公司最先进的 Opus 模型表现更佳，在 75% 的运行中（30/40）发出警告，并且最终没有将恶意依赖项写入 requirements.txt 文件或代码中。

Shmueli 表示 Opus“训练有素，处理过的包裹更多，而且更加复杂”。

因此，尽管高端商业模型似乎能够识别虚构的依赖关系，但问题远不止 Context Hub 一个。Shmueli 指出，所有其他将社区编写的文档提供给 AI 模型使用的系统在内容清理方面都存在不足。

接触不受信任的内容是开发者西蒙·威利森在其致命三重人工智能安全模型中提到的三大风险之一。鉴于未经审核的文档已成为现状，您最好确保您的人工智能代理没有网络访问权限，或者至少没有访问私人数据的权限。

技术报告：

《“面向人工智能代理的 Stack Overflow”听起来很棒——直到有人在答案中投毒为止》

https://medium.com/@mickey.shmueli/stack-overflow-for-ai-agents-sounds-great-until-someone-poisons-the-answers-d322258095c4