LiteLLM 投毒复盘：泄露密钥未被吊销

LiteLLM 的一次密钥泄露，最终演变成了发布产物投毒。据所给节选转述的官方复盘，管理密钥进入公开仓库后，团队删除了文件，却没有吊销密钥。攻击者随后利用它逐步获取更高权限，最终让 PyPI 上的 litellm 1.107.0 和 Docker latest 镜像遭到投毒。

目前能确认什么

泄露发生在 5 月 27 日：公开仓库中的 opencode.json 包含内部 Agent Platform 的管理密钥。约三小时后文件被删除，但密钥持续有效，包含它的提交也仍留在公开历史中。

10 月，攻击者用该密钥访问 Agent Platform API，从托管 agent 的配置中取得一名 GitHub 组织所有者的 GitHub CLI OAuth token，随后通过工作流窃取更多维护者凭证，并修改发布流程，把构建来源指向名称相似的攻击者仓库。

节选称，恶意发布包含窃取凭证、加载远程代码执行工具的编译产物，而 GitHub 上官方 v1.107.0 源码标签没有恶意文件。

删除文件只改变仓库的新快照，吊销凭证才会终止它的访问权限。

Git 历史、已有克隆和分叉都可能保留旧内容，因此清理仓库不能替代凭证处置。

我的判断

对程序员最直接的提醒是：发现密钥进入提交后，应先吊销或轮换，再检查访问记录和权限扩散。这次泄露的管理密钥能进一步取出高权限 token，问题已经超出了单个配置文件。

依赖排查也不能只看 GitHub 源码。使用过相关版本或镜像的团队，需要核对实际下载、部署的包和镜像；Docker latest 会移动，仅凭当前标签无法还原当时运行的内容。

现有节选还不足以确定恶意代码的全部行为、各环境的受影响范围，以及完整恢复步骤。这些需要官方处置说明确认，不能把删除依赖当成处置完成。