LiteLLM 1.107.0 遭供应链攻击入侵：凭据窃取器与后门通过 PyPI 与 Docker 分发

原创

NightTeam
NightTeam

夜组安全

2026年10月23日 07:30
青海

去阅读

免责声明

由于传播、利用本公众号夜组安全所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号夜组安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！所有工具安全性自测！！！VX：NightCTI

朋友们现在只对常读和星标的公众号才展示大图推送，建议大家把夜组安全“设为星标”，否则可能就看不到了啦！

2026 年 10 月 21 日，流行的开源 LLM 网关与代理工具 LiteLLM 再次遭遇严重软件供应链攻击。攻击者利用被盗的开发者凭据，通过官方发布流水线向 PyPI 发布了恶意版本 1.107.0，同时污染了官方 Docker 镜像。该版本携带凭据窃取器（内部名称为 privcollect）和远程代码执行后门，影响范围涵盖所有平台的 PyPI wheels 以及相关 Docker 标签。

LiteLLM 作为连接数十家 LLM 提供商（OpenAI、Anthropic、Google 等）的常用代理，周下载量可达千万级，常部署在持有云凭据、AI API 密钥与内部数据库的环境中，因此此次事件影响面较大。

攻击时间线与影响范围

恶意版本于 UTC 11:39 左右上传至 PyPI（全部 7 个 wheels：Linux、macOS、Windows 等），约两小时后（约 13:20–13:23）被隔离并移除。Docker Hub 与 GHCR 上的 v1.107.0、latest、main-latest、main-stable 等标签也在约 11:46 至 14:20 期间指向被污染镜像，之后被移除或重定向。

官方 GitHub 源码标签 v1.107.0 本身干净，恶意代码仅存在于构建产物中。安全版本建议固定为 1.106.2（或 10 月 21 日之前发布的版本）。企业私有仓库用户未受影响。

恶意载荷如何工作

安装后，三个文件被直接放入 site-packages 根目录：cook.pth、cook.py 和 sitecustomize.py。它们通过 Python 启动钩子（.pth 与 sitecustomize.py）在任何 Python 解释器启动时自动执行，即使代码从未 import litellm。这是首次公开观察到同时使用这两种技术的案例。

• 凭据窃取器（cook.py 中的 privcollect）：针对 16 个模块收集数据，包括浏览器密码与 Cookie（Chromium 系列与 Firefox）、SSH/GPG 密钥、shell 历史、云凭据（AWS、GCP、Azure，含 IMDS）、Kubernetes/Docker 配置、CI/CD 与包管理器令牌、多种 AI 编码工具（Claude、Cursor、Codex、Copilot 等）的凭据，以及 LiteLLM Proxy 自身 PostgreSQL 数据库中的 LiteLLM_CredentialsTable（最多 500 条提供商密钥）。数据经 AES-256-CBC + RSA-4096 加密后，通过 HTTP POST 发送至仿冒域名 www.litellm[.]dev/healthcheck。
• 后门（sitecustomize.py，主要在 Linux/macOS）：每小时检查 GitHub 死信（dead drop，letters9813 相关仓库中的 domain.txt），若存在域名则下载并执行远程 Python 代码，实现持久远程控制。相关仓库后被 GitHub 下架。

Wiz 等厂商观察到被盗 AWS 凭据的后续滥用行为（约 16:20–17:01 UTC）。

攻击如何发生

1. 载荷注入与发布机制

恶意代码并非直接提交到官方 BerriAI/litellm 仓库的公开分支。攻击者准备了仿冒仓库 Berri-AI/litellm（注意连字符），并在其上叠加了约 10 个提交。这些提交在 08:56–10:46 UTC 之间完成，作者邮箱为 [email protected]。前几个提交添加了 cook.pth、cook.py 和 sitecustomize.py，后续提交修改版本号，并在 pyproject.toml 的 [tool.maturin] 节中注入一行：

data = \"cook\"

LiteLLM 使用 maturin 构建平台 wheel。data 选项会将本地 cook/ 目录打包进 wheel 的 .data/purelib/ 路径。pip 安装时，该路径下的文件会被直接释放到 site-packages 根目录，而不是 litellm 包内部。官方 GitHub 标签 v1.107.0 和 sdist 中并不包含完整恶意目录，因此源码审查难以发现，但所有 7 个平台 wheel（以及对应 Docker 镜像）都携带了载荷。

发布流程被通过被盗的 GitHub CLI OAuth 令牌劫持：攻击者覆盖分支保护、修改私有发布工作流，使其从仿冒仓库构建，并通过第二套凭据通过生产审批门。最终由官方流水线完成签名并推送到 PyPI 与镜像仓库。

2. 启动钩子：无需 import 即可执行

安装后，site-packages 根目录会出现三个文件：

• cook.pth（约 12 字节）：内容仅为 import cook。Python 的 site 模块在启动时会执行所有以 import 开头的 .pth 行，这是经典的启动持久化技术（此前 3 月事件也使用过类似 litellm_init.pth）。
• cook.py（约 22 KB）：单行混淆代码，使用 zlib + base64 解压后执行约 61 KB 的明文 Python 载荷。
• sitecustomize.py（约 25 KB）：Python 启动时会自动导入同名模块（在处理完 .pth 之后）。部分系统 Python（如 Debian/Ubuntu）可能因路径优先级被自身的 sitecustomize.py 覆盖，但 .pth 路径不受影响。

这两个机制叠加，使任何在该环境中启动的 Python 进程（包括 pip、pytest、Jupyter、LiteLLM proxy 本身）都会触发载荷，即使应用代码从未导入 litellm。Wiz 指出，同时使用 .pth 与 sitecustomize.py 的组合是公开记录中的首次案例。

3. 凭据窃取器 privcollect（cook.py）

cook.py 解压后的配置块大致如下（摘自分析报告）：

PC_URL = 'http://www.litellm.dev/healthcheck'
PC_TOKEN = 'XWiA8gZNa7NcX2XRoAEb'          # 作为 X-Token 请求头
PC_PUBKEY = '-----BEGIN PUBLIC KEY----- ...'  # RSA-4096 公钥
PC_ONCE_PATH = '/tmp/.pc_once_72129118c59f5636c0bb'
PC_ASYNC = True
PC_MODULES = ['sysinfo', 'netinfo', 'browser_pw', 'browser_hist', 'ssh_keys',
              'shell_hist', 'cloud_creds', 'dev_secrets', 'container_creds',
              'cicd_secrets', 'ai_devtools', 'env_vars', 'db_litellm',
              'cloud_metadata', 'gpg_keys', 'tls_privkey']

执行流程要点：

• 若环境变量 PRIVCOLLECT_ACTIVE 已设置，则立即返回（避免同一进程树重复执行）。
• 在守护线程中异步收集，减少对主进程的可见影响。
• 收集完成后，若外传服务器返回 HTTP 200，则写入标记文件 /tmp/.pc_once_...，后续不再完整收集；若外传失败，则每次启动都会重试。
• Windows 上标记路径 /tmp/ 通常不存在，相关逻辑会静默失败。

收集模块覆盖范围（16 个）：

外传方式：收集结果打包为 tar.gz（含 hdr.json、data.bin、key.bin），数据使用随机 AES-256-CBC 密钥加密，该密钥再用嵌入的 RSA-4096 公钥进行 OAEP 封装。随后以 HTTP POST 发送至 http://www.litellm[.]dev/healthcheck，请求头包含硬编码 X-Token，User-Agent 伪装为 Internet Explorer 7。

Wiz 等分析指出载荷有明显 LLM 辅助开发痕迹：冗长变量名、过度防御性的 try/except、未充分测试的平台路径（Windows 上 /tmp/ 与 fork 相关调用易失败），以及未使用的死代码。

4. 远程代码加载后门（sitecustomize.py）

该模块主要在 Linux 与 macOS 上有效。关键配置包括：

GITHUB_RAW_URL = \"https://raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt\"
CODE_PATH = \"/codepy\"
LOOP_INTERVAL = 3600  # 1 小时
LOCK_FILE = \"/tmp/remote_code_loader.lock\"

执行逻辑：

1. 对锁文件获取独占锁，确保每主机仅一个守护进程。
2. fork() + setsid()，将标准输入/输出重定向到 /dev/null，工作目录切到 /，实现完全脱离父进程。
3. 每小时循环：

• 从 GitHub 死信（dead drop）读取 domain.txt，提取有效域名。
• 再次运行嵌入的窃取器（无一次标记限制）。
• 向 http://<domain>/codepy 发起 GET，将返回内容直接 exec() 执行。

攻击者可通过修改 GitHub 上的 domain.txt 动态切换 C2 地址。该仓库（letters9813）在事件公开后约数小时内被 GitHub 下架，此后死信失效。但在下架前已运行的主机可能已拉取并执行过第二阶段代码。

5. 关键 IOC 摘要

• 文件：site-packages 中的 cook.pth、cook.py、sitecustomize.py；标记文件 /tmp/.pc_once_72129118c59f5636c0bb；锁文件 /tmp/remote_code_loader.lock。
• 网络：www.litellm[.]dev / litellm[.]dev（外传）；raw.githubusercontent.com/letters9813/.../domain.txt；X-Token: XWiA8gZNa7NcX2XRoAEb；Python 进程访问 169.254.169.254（IMDS）。
• 环境：PRIVCOLLECT_ACTIVE=1；父进程为 PID 1、工作目录为 / 的 detached Python 进程。
• 镜像：受影响 Docker 镜像索引摘要（示例）sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e。

以上技术细节表明，攻击者针对 LiteLLM 作为 AI 密钥集中点的特性进行了定向设计（尤其是数据库直查模块），同时通过双重启动钩子最大化感染面。任何在 2026 年 10 月 21 日窗口内安装或运行过该版本的环境，均应视为完全失陷并按最高优先级轮换所有可达凭据。

应急建议

1. 立即检查环境：搜索 cook.pth、cook.py、sitecustomize.py 或 litellm-1.107.0.dist-info。注意：不要在已感染环境中直接运行 pip，因为启动 Python 会再次触发载荷。
2. 从干净环境删除相关文件并终止可能的后台守护进程（检查 /tmp/remote_code_loader.lock）。
3. 固定版本至 litellm==1.106.2（建议使用 digest），重建虚拟环境或容器。
4. 假设凭据已泄露：轮换所有可能暴露的密钥，包括云 IAM 角色、LiteLLM Proxy 数据库中的全部提供商密钥、主密钥、环境变量中的秘密、浏览器与开发工具凭据等。检查 CloudTrail 等日志中异常的 sts:GetCallerIdentity 或后续操作。
5. 监控外连 litellm.dev 相关域名。

总结

此次事件再次凸显 AI 基础设施供应链安全的重要性：即使短暂窗口，也可能导致大规模凭据与密钥泄露。建议所有用户优先检查并轮换凭据，并在依赖管理中采用版本固定与供应链安全扫描工具。

往期精彩

往期推荐

灵眼 DSH安全测试模式：探索图记录信念，证据约束结论，侦察、利用、复测与报告连成可复核的一条链

跨平台应急响应分析工具，支持日志、进程和离线流量分析、IOC 匹配、AI 辅助分析、报告导出及 Windows/Linux 应急命令速查

CTF 逆向 AI 解题工作台：AI 工具循环 + 本地验证闭环，MCP 接入 IDA/JEB/Burp；自动求解 APK/PE/ELF等

OmniNex一个可视化网络安全靶场编排平台 | 渗透测试演练、漏洞验证复现、攻防对抗教学

AuthKit — 首个多维度辅助检查鉴权安全的burpsuite插件 | 辅助发现未授权访问、水平越权、垂直越权及 BOLA / IDOR 风险