源码是干净的，安装包不是
10 月 21 日中午，LiteLLM 的 1.107.0 版上传到 PyPI，两个小时内被官方撤下。这个 wheel 是赃物：内含一个凭据窃取器和一个远控后门。Docker 侧的 latest、main-stable 镜像多活了几个小时才摘。注意标题里的「又」——今年 3 月的 TeamPCP 供应链攻击里，Lit…
源码是干净的，安装包不是
10 月 21 日中午，LiteLLM 的 1.107.0 版上传到 PyPI，两个小时内被官方撤下。这个 wheel 是赃物：内含一个凭据窃取器和一个远控后门。Docker 侧的 latest、main-stable 镜像多活了几个小时才摘。注意标题里的「又」——今年 3 月的 TeamPCP 供应链攻击里，LiteLLM 已经中过一回，连恶意文件的名字都没换，还叫 cook.pth。
这次事件最值得讲的地方：源码仓库是干净的。事后清点，三个恶意文件不在 GitHub 上，也不在源码压缩包里——它们是在构建环节混进去的。LiteLLM 用 maturin 构建 Rust 桥接层，构建配置里多了一行 data = "cook"：把构建机上那个名为 cook 的目录打进 wheel 的数据区。构建树在检出和构建之间被人动过手脚，赃物文件和正经文件的时间戳、元数据一模一样，不是事后手工重打包的。pip 安装时，wheel 数据区的内容被倒进 site-packages 根目录——这个位置是精心挑的，因为 Python 会在每次解释器启动时自动执行这里的特殊文件。
三个文件分工明确。cook.pth 一共 12 个字节，内容只有 import cook——.pth 文件是 Python 的启动钩子，机器上任何 Python 进程一启动它就跑，不需要你 import LiteLLM，甚至不需要你运行 LiteLLM。cook.py 是窃密器本体：一行高度混淆的代码，解压执行一个 61KB 的载荷。sitecustomize.py 是远控：同样在解释器启动时自动执行，它会拉起一个后台守护进程，每个小时去攻击者的基础设施取一次命令——攻击者发什么 Python 代码，它就执行什么。
偷的东西列出来像一份「公司全部数字资产」清单：浏览器里解密保存的密码和浏览记录、~/.ssh 里的私钥、Shell 历史、AWS/Azure/GCP 的云凭据（还会现场查询云实例的元数据端点再薅一把）、Docker 配置和 Swarm 机密、Kubernetes 服务账号令牌、CI/CD 机密、环境变量、各种 AI 工具的凭据文件。以及 LiteLLM 自己的代理配置表——这张表存着这家公司所有上游模型供应商的 API key，OpenAI 的、Anthropic 的、各家云的，一把不落。赃物打成压缩包，POST 到 litellm.dev/healthcheck——一个和项目重名的仿冒域名，把数据外传伪装成健康检查上报。为什么盯着 LiteLLM 来两次？因为它是替全公司保管全部 AI 供应商钥匙的那把钥匙串。
追责环节卡在一个尴尬的地方。发布是从一个仿冒仓库构建的——正牌仓库叫 BerriAI/litellm，攻击者的是 Berri-AI/litellm，差一个连字符，现在已 404。耐人寻味的是：每份 Docker 镜像的 SLSA 溯源元数据都如实记录了这个恶意来源和对应的提交——溯源系统诚实地写下了赃物的出身，但整条链路上没有任何一环要求「来源必须是正牌仓库」，于是没人拦。官方至今没找到发布用的 GitHub Actions 工作流，也不确定构建环境或发布凭据是怎么丢的，初步怀疑是内部部署上一个刚打过补丁的漏洞。
处置建议里藏着一个反直觉的坑：别上来就 pip install。pip 本身也是 Python 进程，在受感染的机器上一启动，cook.pth 就再跑一遍。正确顺序是从 shell 手动删掉三个文件和对应缓存、杀掉那个持有 /tmp/remote_code_loader.lock 锁文件的守护进程，然后重装 1.106.2 并按 digest 钉死；重装前那些凭据先全部轮换。官方的说法更直接：只要 1.107.0 在一台能出网的机器上装过，就假定外传已经成功——窃密器在第一次 Python 启动时就开始干活了。
上架 11 点 40，撤下 13 点过，窗口不到两小时。三月的战役到十月的复发隔了七个月，同一个包、同一种手法、同一个文件名。对一个替用户保管着所有模型供应商钥匙的代理项目来说，攻击者的执念从来不随机。