同一个包、同一个手法：LiteLLM 又被投毒，这次端走了网关里的全部模型 key
LiteLLM 今年第二次被投毒了。同一个包、同一个手法、同一个目标——这次被端走的，是网关里存的所有模型厂商 key。先记一条自查：
pip show litellm | grep -E '^(Version|Location)'
版本是 1.107.0 就是中招了。
手法跟上次几乎一模一样：往 site-packages 根目录丢几个文件，靠 Python 的启动机制自动跑。恶意 wheel 会放进去三个文件——cook.pth（内容只有一行 import cook）、cook.py、还有一个 sitecustomize.py。
.pth 和 sitecustomize 这两个东西，Python 每次启动都会执行。所以根本不需要你 import litellm——pip、pytest、Jupyter，随便哪个一起来，cook.py 就跑起来了。
跑起来干什么，才是这次最扎心的：cook.py 收集 AWS / GCP / Azure 的凭证（还会用 STS 的 GetCallerIdentity 先验证能不能用）、K8s / Docker / Git 配置、npm / PyPI 的 token、SSH / GPG / TLS 私钥、浏览器里的密码和 cookie、/proc/*/environ，以及——最关键的一项——LiteLLM Proxy 自己的凭证表和路由表，也就是网关里存的所有模型厂商 key。
一个集中管模型的网关，被从里面把钥匙串整个端走。
收集完，AES-256 加密、RSA-4096 包一层，POST 到一个外泄域名，UA 还装成 IE7。sitecustomize.py 会再起一个后台守护进程，每小时去拉一次更新的地址、执行一段没签名的代码——等于挂了个级联，C2 地址随时能换。
怎么进来的：发布流水线被攻破，恶意包是从一个仿冒仓库构建的（正牌仓库名少一个字母）。最要命的一点在这——GitHub 上 v1.107.0 那个 tag 是干净的，只对比 tag 的 review 什么都看不出来。
影响版本：litellm==1.107.0（7 个 wheel + sdist）；Docker 镜像 tag v1.107.0 / latest / main-latest / main-stable。时间窗（UTC）：10/21 11:39–13:23 之间 pip install 拉到过 1.107.0 的环境；11:46–14:20 之间拉过上面那几个镜像/tag 的容器。tag 后来被删了，但已经被拉下去的镜像还在。企业私有 registry 里的版本不受影响。
没有「修复版」：回退并锁定 litellm==1.106.2（按 hash 锁），镜像按 digest 锁。
处置上有个坑要单独提：受影响的环境里别急着先跑 pip install——一跑 pip，cook.pth 又被触发一次。正确顺序是先把那三个文件手工删掉、把守护进程杀掉，再重建 venv 或镜像。而且注意，光卸掉 litellm 这个包目录，不会删掉这三个启动文件，也不会停掉 loader。最后一条：只要这台机器出过网，就假设东西已经出去了，key 全部轮换。
（这次是 2026 年 LiteLLM 第二次被投毒。3 月那次是 TeamPCP 经 Trivy 偷到 PyPI token，发的 1.82.7 / 1.82.8。）
出处：LiteLLM 官方安全公告《Security incident - Oct 21, 2026》docs.litellm.ai。
页:
[1]