据 [1M AI News](https://t.me/OneMillion_AI) 监测，DeepLearning.AI 创始人、斯坦福大学兼职教授吴恩达两周前推出的 AI 编程文档服务 Context Hub，近日被安全研究者指出存在明显的供应链攻击风险。
Context Hub 的核心用途，是通过 MCP 服务器为编程 Agent 提供 API 文档支持。其运作方式看似高效：贡献者通过 GitHub PR 提交文档，维护者完成合并后，Agent 再按需读取并使用这些内容。然而，问题恰恰出在这条流程链路上。
替代服务 lap.sh 的创建者 Mickey Shmueli 发布了一份概念验证攻击（PoC），直指 Context Hub 的安全薄弱点。他的评价非常直接：这条流水线“几乎每个环节都缺乏内容审核”。
为了验证风险，Shmueli 专门制作了两份伪造文档，分别针对 Plaid Link 和 Stripe Checkout，并在其中植入了一个虚假的 PyPI 包名。随后，他使用 Anthropic 的三个不同级别模型分别进行了 40 次测试，结果颇具警示意味：
### 测试结果一览
1. **Haiku**
在全部测试中，Haiku 每一次都会将恶意包直接写入 `requirements.txt`，而且输出过程中完全没有给出任何警告。
2. **Sonnet**
Sonnet 的表现略好一些，在 48%（19/40）的测试中发出了警告；但与此同时，仍有 53%（21/40）的测试结果将恶意依赖写入了项目。
3. **Opus**
Opus 是三者中表现最稳健的模型，在 75%（30/40）的测试中成功发出警告，并且没有将恶意依赖写入代码。
### 风险点在哪里？
更值得警惕的是，这类攻击的实施门槛并不高。
攻击者理论上只需要提交一个 PR，并让其顺利被合并，就有机会完成“投毒”。而从审核现实来看，这并非难事：在 Context Hub 已关闭的 97 个 PR 中，有 58 个最终被合并，整体通过率并不低。
Shmueli 认为，这本质上是“间接提示注入”的一种变体。问题的根源在于，AI 模型在处理这类内容时，无法稳定、可靠地区分哪些是“数据”，哪些其实是“指令”。一旦恶意信息被包装进看似正常的文档中，模型就可能在无意间把它当成合法输入继续执行。
### 不只是 Context Hub 的问题
Shmueli 还进一步指出，这并非 Context Hub 一家服务独有的漏洞。其他类似的社区文档服务，在内容审核和安全把关方面，同样普遍存在不足。
截至目前，吴恩达方面尚未回应相关置评请求。
原创文章，作者：admin，如若转载，请注明出处：https://www.23btc.com/163579/
