模型网关出事，钥匙可能出在自家日志里

模型网关的调用日志，这次被厂商自己指认成了泄露发布权限的入口；网关不再只是一个省事的中转站，而是一座要单独设防的密钥库。

北京时间 10 月 21 日晚 7 点 39 分，开源模型网关 LiteLLM 的一个新版本出现在 Python 官方包仓库里。版本号、签名、构建记录看上去都正常，装上它的机器却会在每次启动 Python 时悄悄打包本机的各种密钥发往一个仿冒域名。两个小时后它被撤下，但凡在这段时间里装过它的环境，官方都要求按已失陷处理。

先给结论：依赖投毒并不新鲜，这次值得多看一眼的是钥匙从哪里来。按 LiteLLM 自己的说法，攻击者用来改发布流程的 GitHub 令牌，是从 LiteLLM 内部一套自用网关的日志里拿到的，而令牌之所以进了日志，是编程智能体把它回显在了响应里。这条链路还在确认，但它把一个容易被当成运维细节的问题摆上了桌面：网关记下的东西，和它保管的密钥一样值钱。

发生了什么

据 LiteLLM 官方事故报告（企业宣称，最后更新于北京时间 22 日凌晨 4 点 30 分）：恶意的 1.107.0 版本七个安装包于北京时间 21 日 19:39 至 21:23 可从 PyPI 下载；Docker Hub 上的 v1.107.0、latest、main-latest、main-stable 四个标签在 19:46 至 22:20 指向受污染镜像。官方称 GitHub 上正式的 1.107.0 源码标签不含恶意文件，恶意制品是从攻击者控制的仓库构建出来的；走私有企业版仓库的客户不受影响。

据 Datadog 安全实验室的分析（第三方评测），LiteLLM 每周下载量约 2300 万次，这是它今年第二次被投毒，3 月那次影响的是 1.82.7 和 1.82.8，两次之间尚未发现关联。攻击者用三名工程师的 GitHub 命令行令牌，分别完成了启动、审批和删除记录三步，把正规的发布流程指向一个只差一个连字符的仿冒仓库 Berri-AI/litellm。Datadog 特别指出，产出的安装包带着「看上去合法」的构建出处记录，记录本身忠实地写着那个仿冒仓库。

钥匙是怎么流到攻击者手里的

LiteLLM 在报告的 20:30 UTC 更新里给出了它目前的判断，原话的意思是：他们观察到在特定情况下，Claude Code 会把用户的 GitHub 命令行 OAuth 令牌写进响应正文，而在记录响应正文的部署里，这些令牌就会出现在 LiteLLM 的日志中。他们在自家一套对公网暴露的内部 LiteLLM 部署里发现了一个名字不起眼的陌生账户，认为攻击者由此进入、从日志里取走了令牌。攻击者最初怎么进入这套部署，官方说还没确认，怀疑是一个近期修补过的漏洞。

这一段要分清证据等级。令牌回显和日志取走，都是 LiteLLM 的说法，报告自己也写着「仍在确认」；Datadog 发稿时写的是凭据最初如何泄露尚不清楚。我们采信的是事故报告里可核对的部分：攻击者手里确有三套开发者令牌，其中一套属于 GitHub 组织所有者，被用来关掉分支保护、强推改动。

分析推断：如果这条链路成立，问题不在某一款编程智能体，而在网关的位置。依据是 LiteLLM 对自身架构的描述——网关站在所有模型请求和响应的必经之路上，开了正文日志，就等于把智能体说过的每一句话都存了下来，包括它不该说出来的令牌。

为什么这件事落在网关上

上周 OpenCode 控制台那次事故，丢的是网关替团队托管的模型密钥。这一次多了一层：网关不只保管密钥，还会被偷。据 JFrog 安全研究团队对恶意包的拆解（第三方评测），窃密程序有一个专门针对 LiteLLM 代理的模块：通过 DATABASE_URL 连上网关数据库，直接导出存放上游厂商凭据的表和模型配置表。JFrog 的判断是，一台中毒的代理主机可能一次暴露多家上游 AI 厂商的凭据。同一份报告还列出它收集的范围覆盖 Cursor、Claude、Codex、Gemini、Copilot、opencode 等十几种编程工具的会话与配置。

所以网关在这次事故里扮演了两个角色：入口处，它的日志可能交出了发布权限；出口处，它的数据库是窃密程序最想要的那一张表。这就是我们说它该按密钥库来管的理由。

JFrog 的拆解还说明了另一点：这一版的源码压缩包里没有那三个恶意文件，恶意代码只在平台安装包里。只看源码或 Git 标签做审查，看不到它。

最强反方

最有力的反驳是：这本质上是一次经典的发布链攻击，钥匙来自哪里只是细节。攻击者拿到组织所有者的令牌就能关掉分支保护，换成任何一种泄露途径——钓鱼、笔记本被盗、终端历史——结果都一样；把账算到「网关日志」头上，反而可能让人忽视真正的教训：临时扩大的发布权限、长期有效的命令行令牌、对仿冒仓库名缺乏校验。况且日志这条链路目前只有当事方一家之言。

我们在两处让步：令牌是如何进入日志的，在 LiteLLM 完成调查前只能当企业宣称看；Datadog 的结论——发布流程应锁定到核准的仓库、把开发者命令行令牌当高价值密钥——同样是这次事故的核心教训。但我们仍坚持论点：在智能体大量代人执行命令的环境里，令牌出现在模型输出中不再是偶发事故，而网关是唯一一个系统性地记下所有输出的位置；它同时还存着所有上游密钥。这两点都不依赖这次的具体入口是否最终确认。

我们不知道什么

• 攻击者最初如何进入 LiteLLM 那套对公网暴露的内部部署，官方尚未确认。
• 令牌被写进响应正文的具体触发条件，LiteLLM 没有公开复现细节，我们没有查到 Anthropic 对此的公开说明。
• 有多少环境在两小时窗口内装上了恶意版本，以及被盗凭据是否已被滥用，目前没有公开数字。
• 官方提到 10 月 27 日将披露另一个漏洞，与这次入口是否有关，现在不清楚。

接下来看什么

一是 LiteLLM 后续更新里对入口和日志链路的确认或修正；二是主流模型网关是否默认关闭响应正文日志，或在写入前对令牌做脱敏；三是 PyPI 与 Docker Hub 的下载统计能否给出受影响规模。我们的看法是：智能体越多地替人跑命令，网关日志里就越可能躺着不该出现的令牌，下一次事故的入口未必还在发布流程上。