---
title: "LiteLLM：被盗令牌使恶意版本通过签名并发布"
dek: "LiteLLM 于 10 月 23 日发布报告，将 1.107.0 版本遭投毒的过程追溯至泄露的代理平台密钥、被盗的 GitHub 凭据和遭篡改的发布工作流。保存的报告未指定修复后的替代版本。"
---

LiteLLM 于 2026 年 10 月 23 日发布攻击链报告称，攻击者利用被盗凭据，于 10 月 21 日构建、签名并发布了遭投毒的 `litellm==1.107.0` 软件包和容器镜像。报告描述了发布流水线如何在被盗身份的驱动下，执行看似经过授权的操作。[^1]

据 LiteLLM 披露，5 月 27 日提交到公开仓库的一把管理密钥，在相关文件删除后仍然有效。攻击者于 10 月 10 日用它查询内部 LiteLLM Agent Platform，从托管代理的配置中取得了一名组织所有者的 GitHub CLI OAuth 令牌，随后通过恶意持续集成（CI）工作流窃取了另外两名维护者的令牌。[^1]

攻击者修改发布工作流，使其接受其他源码所有者，并用组织所有者凭据绕过分支保护，转而从名称近似的 `Berri-AI/litellm` 分叉仓库构建。被盗的维护者令牌批准了生产发布关卡，流水线随后完成签名和发布。LiteLLM 称，攻击者还用另一枚令牌删除发布运行记录，并强制改写历史，使主分支的可见历史不再显示那次工作流修改。[^1]

报告记载，PyPI 于 10 月 21 日 13:23 UTC 前隔离了相关版本，容器标签随后被移除或重新指向其他镜像。报告将暴露检查和清理步骤交由另一篇事件说明介绍。这份保存的报告没有指定修复后的替代版本；其中关于再次发布版本的表述是计划，不能视为已经交付。[^1]

:::analysis
问题涉及 T7 机构层、T5 代理层和 T2 运行时层，分别对应发布权限、代理持有的凭据和分发的可执行产物。按报告所述，恶意版本也经过了签名，因此用户和核验者仍须信任签名背后的源码选择与审批控制。这里关乎的可核验属性是**可识别性**：如果为用户提供服务的确切版本和配置有记录且可供核查，用户就能判断自己是否曾受影响。用户应将部署记录与报告列出的产物对照；运营方应核查源码仓库、凭据权限范围和发布审批，同时明确，仅凭这份来源无法确定应采用哪个修复版本。[^1]
:::

:::checked
我们于 2026 年 10 月 28 日阅读了保存的 LiteLLM 官方报告《The attack chain behind the v1.107.0 LiteLLM release》，该文发表于 10 月 23 日。本次阅读确认了 LiteLLM 作出的陈述；我们没有测试系统、检查产物或审计日志，也没有阅读报告另行提及的事件说明。我们未独立确认攻击链或修复结果。[^1]
:::

[^1]: LiteLLM，《The attack chain behind the v1.107.0 LiteLLM release》，2026 年 10 月 23 日。https://litellm.vercel.app/blog/security-incident-oct-21-2026-attack-chain