LiteLLM 1.107.0:在 Python 启动时窃取凭据的被投毒版本
2026 年 10 月 21 日,被植入后门的 LiteLLM 1.107.0 出现在 PyPI 和容器镜像仓库中。其 .pth 启动钩子在每次 Python 启动时运行,收集云和 AI 服务商凭据。
这是什么?
2026 年 10 月 21 日,一个恶意构建的 LiteLLM 1.107.0 被发布到 PyPI,并随官方容器镜像分发。微软安全研究团队于 2026 年 10 月 23 日记录了该事件;据一份第三方时间线,LiteLLM 同日发布了根因分析。微软未列出任何 CVE,而是以内部编号 TVM-2026-0003 跟踪。目前仅 1.107.0 被报告受影响,1.106.2 被称为最后一个安全版本。该软件包当天即从 PyPI 撤下,受影响的容器标签也被删除或重新指向干净的制品。
工作原理
这些 wheel 包在 site-packages 中额外安装了三个文件:一个 .pth 文件、它所导入的 Python 模块,以及一个 sitecustomize.py。Python 在解释器启动时会执行 .pth 中以 import 开头的行,因此只要在该环境中启动 Python,载荷就会运行,即使应用从未导入 LiteLLM。这对应 MITRE ATT&CK 技术“Python startup hooks”(T1546.018)。
据微软介绍,载荷是一个凭据收集器,目标包括开发者和 AI 工具配置、云凭据、浏览器数据、SSH 密钥、进程环境变量以及 LiteLLM 代理数据库中的表。数据经加密后发送到攻击者控制的域名。在 Unix 上还有第二条路径,会读取托管在 GitHub 上的文件中的指针并可能获取更多代码;分析时该指针为空,未确认存在第二阶段。
被篡改的是构建过程,而非源代码。LiteLLM 表示,多名工程师被盗的 GitHub 凭据使攻击者得以把发布工作流重定向到一个仿冒仓库,并通过了生产环境审批步骤。一份第三方时间线认为起点是 2026 年 5 月提交到公开仓库、且未被撤销的一把密钥。微软说明其尚未独立确认这些开发者凭据是如何获取的,各来源之间的部分时间也不一致。
示例提示
仅为示意并已脱敏:展示弱点的形态,而非可用的载荷。
# 可疑 Python 环境的启动钩子排查(示意性、防御性、已脱敏)
# 模式:以 'import' 开头的 .pth 行会在每次解释器启动时执行。
# [startup files] -> site-packages 中的 .pth + 辅助模块 + sitecustomize.py [REDACTED]
# [collector] -> 收集环境变量、云与 AI 提供商密钥 [REDACTED]
# [exfil domain] -> 加密上传至攻击者控制的主机 [REDACTED]
# 防御:在干净系统上检查(切勿在可疑环境中运行 Python),按 digest 固定镜像,
# 从已验证产物重建,并轮换主机可读取的所有密钥。
为什么重要
LLM 网关按设计就掌握服务商 API 密钥、云角色和数据库,一次被污染的发布就会集中大量机密。启动钩子机制还使常规清理失效:删除 litellm 目录并不会移除钩子文件。LiteLLM 建议,只要 1.107.0 曾在某环境中运行,或容器使用了受影响的镜像摘要,就应假定已被入侵。目前未公布安装数量。
防御措施
- 在锁文件、缓存、内部镜像、构建日志和运行中的容器里查找 1.107.0。按摘要(digest)而非可变标签固定镜像。
- 不要在可疑环境中运行 pip 或 Python 来排查,因为启动会重新执行钩子。请在干净系统上检查。
- 从经验证的制品重新构建,并确认 site-packages 中不再有这三个启动文件。
- 轮换该主机可读取的一切:服务商密钥、主密钥和虚拟密钥、云与 CI 机密、SSH 密钥、数据库 URL,并撤销活动会话。
- 检查网络和云审计日志,留意流向外传域名的流量以及实例角色凭据的异常使用。
- 使用带哈希的锁文件、可验证的来源证明、受限的出站访问,以及权限范围收窄并强制多人审批的发布令牌。
Status
| 项目 | 详情 |
|---|---|
| 受影响 | LiteLLM 1.107.0(PyPI wheel、容器标签) |
| 最后安全版本 | 1.106.2 |
| 恶意版本发布 | 2026-10-21 |
| 微软分析 | 2026-10-23 |
| 标识 | 无 CVE;微软 TVM-2026-0003 |