LiteLLM 1.107.0 带有凭据窃取程序（2026 年 10 月）：受影响的 PyPI 版本与 Docker 镜像，以及用户该怎么做

公司列出了以下受影响的构建产物。所有时间均为 2026 年 10 月 21 日。

公司称，如果你在该窗口内未固定版本就用 pip 安装了 LiteLLM，或在该窗口内用这些标签之一启动了容器，就属于受影响。如果 CI 在每次构建时都运行 pip install litellm，或者你的 Dockerfile 使用 FROM 指向 latest 标签构建，那么即使没有人做任何操作，也可能安装了受影响的版本。

• 如果某个环境可能受影响，不要启动 Python 或 pip 来检查其版本。先将其隔离，再在另一台干净的机器上查看部署记录或镜像摘要。如果无法排除暴露的可能，就按受影响处理，并继续进行下面的重建和凭据轮换（本站提示）。公司的版本检查命令同样会启动 Python，因此在清理之前不要运行
• 公司已公布需要查找的文件名和镜像摘要。找到它们可确认已暴露，但找不到并不能证明环境是干净的
• 如果你明确固定了 1.106.2 或更早版本，或 1.107.0rc1 或 rc2，则不受影响（公司称更早的版本不在此次入侵范围内）
• 从私有企业版镜像仓库拉取的客户未受影响（公司）

根据公司通知中引用的报告者分析，该恶意软件以 Python 每次启动时自动加载的文件形式安装。对于任何 Python 进程，包括从不导入 litellm 的进程以及 pip 本身，它都会再次运行。

公司给出的清理顺序如下（文件名和位置见其通知页面）：

• 在不启动 Python 的情况下，从 shell 中删除每个受影响 site-packages 目录里公司点名的恶意文件（及其缓存文件）
• 停止在后台遗留运行的 Python 进程
• 然后才重新安装，并固定到 litellm==1.106.2。公司称从头重建镜像和虚拟环境更好

如果你在容器中运行，通常最快的做法是停止由受影响镜像创建的容器，并用固定到干净版本的镜像重新创建（本站提示）。

公司在第一篇帖子中请用户固定使用 1.106.2 或本次事件之前发布的任何明确版本。10 月 24 日（UTC），公司随后发布了 1.103.8、1.104.6、1.105.4 和 1.106.3。PyPI 上的最新版本是 1.106.3，1.107.0 仍处于移除状态。据发布说明，这些版本从 SDK、代理和 Docker 镜像信任的所有证书包中移除了 eMudhra 根证书颁发机构。eMudhra 问题见Python 用户针对 eMudhra 中间 CA 密钥需要做什么。

在 Docker 中，请用版本标签引用镜像，最好用摘要（根据镜像内容计算出的值），而不要使用 latest 或 main-stable 这类内容会变化的标签。这样，标签指向的内容发生变化时就不会影响到你。

据发布说明，从 10 月 24 日的版本起，Docker 镜像和 Helm chart 使用新的 cosign 密钥签名（cosign 是用于对容器镜像签名和验证的工具），用旧密钥验证会失败。如果你在 cosign verify 脚本、CI 检查或检查签名的 Kubernetes 策略（如 Kyverno）中固定了旧的 cosign.pub，请换成发布说明中所指提交里的新密钥。发布说明还列出了新密钥的 SHA-256，切换前请将你下载的密钥与之比对（本站提示）。

公司称，如果 1.107.0 曾安装在可以访问外网的主机上，你应假定被窃取的数据已成功被发送出去。公司特别点名了以下内容：

• 附加在服务器或容器上的云角色（如 AWS 实例或任务的 IAM 角色）
• LiteLLM 代理数据库中保存的所有 LLM 提供商密钥
• 代理主密钥和你签发的所有虚拟密钥
• 数据库连接字符串（DATABASE_URL）中的密码
• 主机上运行的任何进程环境中的所有机密

在报告者的分析中，该恶意软件还被设计为收集 SSH 密钥、Git 和包发布凭据、Kubernetes 令牌、浏览器中保存的密码以及 AI 编码助手的设置。如果你在开发者笔记本电脑上运行过 1.107.0，该电脑上的凭据也需要轮换。

在各服务的控制台中签发新密钥，并吊销旧密钥（本站提示：先设置新密钥，再吊销旧密钥，以避免服务中断）。API 密钥的处理见.env 文件和 API 密钥为什么有风险。

公司请你在 AWS 审计日志（CloudTrail）中，查找安装前后由实例角色发出的身份检查调用（GetCallerIdentity），然后查找该角色的凭据是否被从你自己的基础设施之外使用。

本站提示：还请在 LLM 提供商的控制台中，检查自 10 月 21 日 11:39 UTC（日本时间晚上）以来用量或费用是否有异常上升。被盗的 LLM 密钥被使用时，可能会反映在用量和账单上。被盗密钥的后果见被盗 API 密钥如何导致账号被封。

受影响的环境是那些未固定版本就用 pip 安装的环境，或使用 latest、main-latest 和 main-stable 这类内容会变化的标签的环境。固定了 1.106.2 并用摘要引用 Docker 镜像的环境，即使在该窗口内重建过，也未受影响。

第一步，请用包含哈希的锁定文件来固定生产环境和 CI 中使用的依赖（pip install --require-hashes，或 uv、Poetry 的锁定文件）。避免使用刚发布不久的版本的设置（如 uv 的 exclude-newer，它会忽略在给定时间之后发布的所有内容）也有助于应对几小时内就被撤下的发布。具体做法见用 OSV-Scanner 审计依赖。

代理数据库中保存着你所连接的每个提供商的密钥。像现在这样必须轮换时，如果不知道哪个密钥属于哪个环境，你就只能在可能遗漏一些和全部停机之间做选择。

为开发、测试和生产使用各自独立的提供商密钥，并在提供商一侧设置支出上限和告警，可以缩小轮换范围，也能更早发现滥用。密钥泄露后怎么办，见AI 编写的代码中泄露的 API 密钥。

据根因分析，起点是 5 月被误提交到公开仓库的一个主密钥。该提交很快被覆盖，已暴露的密钥也被认定需要吊销，但主密钥没有被吊销，大约四个半月后它被用上了。公司称，这起事件有力地说明了不轮换可能已暴露的密钥有多大风险。

如果你把机密推送到了公开仓库，请先吊销并更换密钥，再去处理历史记录。轮换之后，请对照你已更换的密钥清单，确认没有遗漏（本站提示）。这一问题见仍然有效的泄露凭据。

据该分析，被窃取的第一个令牌是为了让智能体平台能够创建拉取请求而配置在其中的。它没有绑定到服务账号，也没有缩小权限范围：它是某位组织所有者的个人 GitHub CLI 令牌。公司指出，GitHub CLI 令牌是在双重认证之后签发的，不受 GitHub 在敏感操作前要求的重新认证约束。

请为智能体和机器人使用仅限其职责范围的专用令牌（GitHub App 或细粒度令牌），并把所有者权限与日常工作所用的账号分开（本站提示）。让 CI 机密只对需要它们的工作流和环境可用，也能限制被盗令牌的影响范围（本站提示）。保护 GitHub 账号的方法见设置 GitHub 双重认证。

事后证明这并不是原因，但公司的第一篇帖子指出，在特定情况下，AI 编码助手可能把用户的 GitHub CLI 令牌嵌入响应正文，而在记录响应正文的地方，这些令牌可能出现在 LiteLLM 日志中。

对于自己运行的网关，请检查三件事：管理界面和 API 不能从互联网直接访问；审查保留响应正文的日志设置；如果要保留，保留期应当较短。保护 GitHub 账号的方法见设置 GitHub 双重认证。