LiteLLM 1.107.0 被投毒：PyPI 与 Docker 镜像带凭证窃取程序，用过的环境要轮换密钥

01哪些版本、哪段时间受影响

按 LiteLLM 官方事件说明，受影响的只有 10 月 21 日发布的 1.107.0。官方源码标签里没有恶意文件，恶意代码出现在编译好的发布包里，是从攻击者控制的仓库构建的。

官方还说，使用其私有企业版仓库的客户不受影响。判断自己是否中招：在窗口期内用 pip 装过 1.107.0，或启动过上述 Docker 标签，就按已被攻破处理；`pip show litellm` 可查版本。

02恶意代码做了什么

官方只概括为“窃取凭证并加载远程代码执行工具”。更细的技术分析来自安全公司 SafeDep，以下为该公司的分析，非 LiteLLM 官方结论，本站未自行复现：

• 安装后在 site-packages 里多出 cook.pth、cook.py、sitecustomize.py 三个文件。Python 每次启动都会加载它们，即使程序根本没有 import litellm。
• 窃取程序会收集 SSH 密钥、云服务凭证、CI/CD 密钥、各类 AI 开发工具的令牌、浏览器保存的密码，以及 LiteLLM 代理数据库里存的各家模型 API Key，加密后发往 litellm 仿冒域名。
• 后台守护进程每小时读取一个 GitHub 文件获得服务器地址，再次运行窃取程序，并下载执行远程代码。SafeDep 称该 GitHub 账号在事发约两小时后被删除，所以无法恢复服务器地址，已运行过守护进程的机器可能收到过后续代码。

03攻击是怎么进来的

LiteLLM 说，攻击者通过三位工程师的 GitHub 账号动手，看起来用的是被盗的 GitHub CLI OAuth 令牌：一个账号改动发布流程并触发发布，另一个账号批准，第三个账号删除了部分工作流记录。令牌是怎么被盗的，官方写明尚未查清，所以也不能保证没有其他访问。官方已撤销相关令牌，并把 GitHub 组织里的成员临时减到只剩一位未受影响的成员。

04中招后怎么处理

下面是官方事件说明里列出的步骤（由发现者 LidorMachluf 提供），本站未实际运行：

1. 先别 pip install。在受影响的环境里，任何 Python 启动（包括 pip）都会再次触发恶意代码。
2. 在 shell 里删除每个受影响 site-packages 里的 cook.pth、cook.py、sitecustomize.py 及对应的 __pycache__ 缓存文件。
3. 结束那个持有 /tmp/remote_code_loader.lock 的后台 Python 进程。
4. 重装并固定到 litellm==1.106.2，最好直接重建镜像和虚拟环境。
5. 只要 1.107.0 在能联网的机器上装过，就当作数据已被外传：轮换主机能接触到的所有密钥，包括实例的 IAM 角色、LiteLLM 代理库里存的每个模型 Key、主密钥和虚拟 Key、DATABASE_URL 密码，以及任何进程环境变量里的密钥。
6. 在云审计日志里查实例角色在安装前后是否被异常使用。

往后的做法：生产环境把依赖固定到明确版本（官方也建议先固定 1.106.2 或此前发布的版本），不要用 latest 这类浮动标签。官方表示会继续更新这份说明，细节以原文为准。