AI供应链攻击无需恶意软件，仅需投毒文档即可

一项帮助编程智能体保持API调用最新的新服务可能带来巨大的供应链漏洞。

两周前，AI企业家、斯坦福大学兼职教授Andrew Ng推出了Context Hub服务，专门为编程智能体提供API文档。

"编程智能体经常使用过时的API并虚构参数，"Ng在LinkedIn帖子中写道。"例如，当我让Claude Code调用OpenAI的GPT-5.2时，它使用的是旧版chat completions API而不是新版responses API，尽管新版本已经发布一年了。Context Hub解决了这个问题。"

也许确实如此。但与此同时，该服务似乎为欺骗编程智能体提供了一种方式，简化了软件供应链攻击：文档门户可用于向AI智能体投毒恶意指令。

替代策展服务lap.sh的创建者Mickey Shmueli发布了一个概念验证攻击，展示了这种风险。

"Context Hub通过MCP服务器向AI智能体提供文档，"Shmueli在说明博文中写道。"贡献者通过GitHub拉取请求提交文档，维护者合并它们，智能体按需获取内容。整个流程在每个阶段都没有内容净化。"

开发者社区长期以来就知道AI模型有时会虚构包名，安全专家已证明可以通过在虚构包名下上传恶意代码来利用这一缺陷。

Shmueli的概念验证跳过了虚构步骤，通过在文档中建议虚假依赖项，让编程智能体将其纳入配置文件（如requirements.txt）和生成的代码中。

攻击者只需创建一个拉取请求（向代码库提交更改），如果获得接受，投毒就完成了。目前，这种情况发生的可能性相当大。在97个已关闭的拉取请求中，58个被合并。

Shmueli通过电子邮件告诉The Register："审查流程似乎优先考虑文档数量而非安全审查。文档拉取请求合并很快，有些是核心团队成员自己合并的。我在GitHub代码库中没有找到任何自动扫描可执行指令或包引用的证据，尽管我不能确定内部发生了什么。"

他说没有提交拉取请求来测试Content Hub的响应，"因为公开记录显示安全贡献没有得到重视。"他指出了几个处理安全问题的开放议题和拉取请求作为证据。

Ng没有立即回应评论请求。

"智能体从Context Hub获取文档，读取投毒内容，然后构建项目，"Shmueli在帖子中说。"响应看起来完全正常。可工作的代码。清晰的指令。没有警告。"

考虑到这只是AI模型未解决风险——间接提示注入的一种变体，这些都不足为奇。当AI模型处理内容时，它们无法可靠地区分数据和系统指令。

在概念验证中，创建了两个投毒文档，一个针对Plaid Link，一个针对Stripe Checkout，每个都包含虚假的PyPI包名。

在40次运行中，Anthropic的Haiku模型每次都将文档中引用的恶意包写入项目的requirements.txt文件，输出中没有任何提及。该公司的Sonnet模型表现更好，在48%的运行中发出警告（19/40），但仍有53%的时间将恶意库写入requirements.txt（21/40）。该AI公司的顶级Opus模型表现最佳，75%的时间发出警告（30/40），没有将错误依赖写入requirements.txt文件或代码。

Shmueli说Opus"训练得更好，覆盖更多包，更加复杂。"

虽然高端商业模型似乎能够捕获虚构的依赖项，但问题比Context Hub更广泛。据Shmueli说，所有其他向AI模型提供社区编写文档的系统在内容净化方面都不达标。

暴露于不可信内容是开发者Simon Willison在其致命三元组AI安全模型中引用的三个风险之一。鉴于未经审查的文档是现状，建议确保AI智能体要么没有网络访问权限，要么至少无法访问私人数据。

Q&A

Q1：Context Hub是什么服务？

A：Context Hub是由AI企业家Andrew Ng推出的服务，专门为编程智能体提供API文档。它的目的是解决编程智能体经常使用过时API和虚构参数的问题，通过MCP服务器向智能体提供最新的API文档。

Q2：Context Hub存在什么安全风险？

A：Context Hub存在供应链攻击风险。攻击者可以通过GitHub拉取请求提交包含恶意指令的投毒文档，如果被合并，就能让AI智能体在生成代码时包含恶意依赖项。该平台在各个阶段都缺乏内容净化机制。

Q3：不同AI模型对投毒文档的抵抗能力如何？

A：测试显示不同模型表现差异很大。Haiku模型每次都会写入恶意包；Sonnet模型48%的时间发出警告，但53%的时间仍会写入恶意库；Opus模型表现最好，75%的时间发出警告，且不会将错误依赖写入文件。