LiteLLM 的 1.107.0 版本已被确认植入窃密代码，装过的环境要按凭据泄露处理。2026年10月21日，安全公司 Wiz 披露：当天 11:39 UTC，一个带木马的 LiteLLM 1.107.0 被上传到 PyPI，同一恶意版本还进入了 GHCR 和 Docker Hub 的多个镜像标签，相关镜像已在 13:53 UTC 左右被移除。目前最近的安全版本是 1.106.2。
它偷的不是一条密钥，而是整台机器的家底
恶意包安装后会在 Python 的 site-packages 根目录落下三个文件，只要启动 Python 解释器就会被执行。内置的窃密模块会横扫浏览器保存的账号和 Cookie、AWS 与 GCP、Azure 的云凭据、SSH 私钥，还专门盯住环境变量和配置文件里的 OpenAI、Anthropic 等大模型 API 密钥。更麻烦的是，LiteLLM Proxy 本来就把上游各家的 API 密钥存在自己的数据库里，窃密代码会直接查询这张凭据表，一次最多拖走 500 条。也就是说，中招的往往不是某个个人项目，而是团队共用的模型网关——一台机器失守，全公司的模型账单钥匙一起丢。
窃取到的数据会被加密后发往一个仿冒 LiteLLM 基础设施的攻击者域名，外观上伪装成健康检查接口，粗看日志很容易放过去。
现在该做的三件事
第一，立刻确认版本：凡是装过 1.107.0 或拉过 latest 等受影响镜像标签的环境，一律按已泄露处理，不要等异常账单出现。第二，轮换凭据的范围要够大：云厂商密钥、大模型 API 密钥、SSH 密钥和浏览器里保存的重要账号都要换，只换 LiteLLM 自己的配置远远不够。第三，回查主机痕迹：检查 site-packages 根目录是否多出异常的启动文件、临时目录里是否有陌生的运行标记，并核对那段时间的外发请求记录。
LiteLLM 是很多团队统一接入多家模型的常用网关，用户量越大，这类供应链投毒的回报越高。这次事件的教训不只在 LiteLLM 本身：网关类工具权限高、经手的密钥多，版本升级更应该先在隔离环境验一遍，再进生产。
