LiteLLM 被指遭投毒，代理凭据成目标

AI 网关把多个模型服务的调用和密钥收在一起，也让攻击者有了集中下手的目标。原文串起 LiteLLM 发布包投毒、OpenCode Console 密钥泄露和多种编程代理漏洞，核心判断是：代理工具链里，存放凭据的位置正在成为攻击重点。

对接入 AI 编程工具的团队，这篇文章最有用的提醒是：检查代码之外，还要检查实际安装的包，以及代理拿着密钥究竟能访问什么。以下事件细节均来自原文转述，调查尚未完成的部分需要保留问号。

没有导入 LiteLLM，为什么也会中招

据原文，10 月 21 日披露的 LiteLLM 1.107.0 投毒涉及 PyPI 和 Docker。该版本全部七个平台的 wheel 包都包含 cook.pth、cook.py 和 sitecustomize.py。

关键在 .pth 文件：它能在 Python 启动时触发执行。因此，应用没有显式导入 litellm，也不能据此排除风险。

窃取范围远超模型服务密钥，包括 SSH、GPG 密钥、浏览器数据、云服务与 Kubernetes 凭据、CI/CD secrets、AI 工具凭据、环境变量，以及 LiteLLM 中保存模型供应商凭据的数据表。收集结果会被发送到一个仿冒域名。

另一个载荷每小时轮询一次 GitHub 上的中转文件，具备下载并执行远程代码的能力。JFrog 检查时文件为空，所以该载荷当时处于休眠状态；但远端文件可以更新，不能把「当时没执行」理解为风险消失。

这里的风险边界是运行环境，而不只是业务代码有没有调用这个依赖。

看过源码，为什么仍然挡不住发布包投毒

LiteLLM 安全负责人称，恶意操作经过三名工程师的 GitHub 账号执行，疑似使用被盗的 GitHub CLI OAuth tokens。令牌如何失窃，原文明确说仍不清楚，调查还在继续。

更关键的证据是：JFrog 发现源码发行包 sdist 内的 pyproject.toml，与对应 git tag 中的文件不同。团队即使审查过仓库和标签，也可能漏掉最终发布物中的变化。

这也是为什么原文强调按哈希固定依赖，并比较构建产物与源码。标签只是一个名字，哈希用于确认实际拿到的是哪份内容；不过，固定哈希之前仍须确认目标产物可信。

原文还回顾了 2026 年 3 月的另一轮事件：被攻陷的 Trivy action 暴露发布凭据，随后 LiteLLM 1.82.7 和 1.82.8 被发布。JFrog 没有发现两次事件存在关联的证据，不能把它们直接归为同一攻击者。

OpenCode 的入口不同，目标却相近。据原文，攻击者于 10 月 19 日侵入 Console 背后的旧系统，影响 1.4% 的 Console 用户。有开发者报告 OpenAI、Anthropic 和 Google 账户出现未经授权的扣费，部分达数百美元，少数超过 $1,000。OpenCode 表示开源应用和 CLI 未受影响，事件仍在处理中。

集中管理密钥方便运维，也会扩大一次失窃的波及范围。

我的判断

我认同作者把注意力放在凭据和权限边界上。只检查提示词是否安全，覆盖不了发布凭据失窃、依赖包投毒和 Console 入侵这些入口。

但原文列举的是多起事件，没有提供攻击数量变化或与其他目标的对照数据。因此，「攻击者正在集中追逐代理密钥」更适合作为风险判断，尚不足以证明整个行业的攻击重心已经迁移。

代理沙箱漏洞清单也要分开看。Adversa 的 10 月汇总提到 GitSpawn、Plugin4Shell、Codex 沙箱逃逸和编号为 CVE-2026-82533 的 DeepSeek Harness 沙箱逃逸。其中 GitSpawn 涉及多个编程代理中的 git config 执行入口，八个缺陷中四个在汇总发布时未修复。但页面没有披露各漏洞的公开日期，不能拿它拼出一条连续爆发的时间线。

攻击能力同样不能夸大。原文转述 10 月 27 日的 OWASP《LLM Exploit Generation Guide 2.0》：代理降低了漏洞发现和研究的技能门槛，却没有可靠实现全自动攻陷；一次测试中，模型供应商的防护拦住了最后一步操作。这支持加强防御，不支持「AI 已能稳定自动攻破系统」的说法。

此外，作者最后引导读者使用开源的 Humanbound engine 和 CLI，并注册免费 Community plan。原文没有给出它与其他测试方法的效果对照，工具推荐应与前面的事件证据分别判断。

能拿来做什么

• 排查开发机、CI 和构建镜像是否存在 litellm 1.107.0。原文建议发现后从干净环境撤销并更换凭据，再按 digest 固定到 1.106.2；这是一条处置建议，不能当成对该版本长期安全性的保证。
• 审查 AI 依赖升级时，把最终 wheel、sdist 和镜像也纳入检查。固定哈希并比较产物与源码，可以补上只看 git tag 留下的空档。
• 为不同 agent、不同任务划分网关密钥权限。先确认一个代理凭据失窃后能触达哪些供应商和资源，再决定是否需要拆分。
• 给日常 AI 编程流程增加对抗测试：代理持有现有密钥能访问哪里，工具结果提供虚假信息时会采取什么操作。测试对象要包括代理实际能执行的动作。