当前位置：首页>下载方法>周下载 2300 万的 LiteLLM 被投毒:1.107.0 只上线 2 小时,装过就得换掉所有 Key

周下载 2300 万的 LiteLLM 被投毒:1.107.0 只上线 2 小时,装过就得换掉所有 Key

2026-10-22 12:02:30

10 月 21 日晚（北京时间），很多人拿来统一调用各家大模型的开源网关 LiteLLM，在 PyPI 和官方 Docker 镜像里发出了一个带毒的 1.107.0。

它只活了大约 2 小时，但装上就会偷云账号、SSH 私钥、各家模型 API Key，连 Claude、Codex、Cursor 的登录会话都在名单里。

如果你在本机、服务器或 CI 里用过 LiteLLM，尤其是 Docker 拉的 latest，这篇的自查命令值得现在就跑一遍。

📌 本文看点

来龙去脉

对程序员意味着什么

能上手的部分

TOPIC 1

来龙去脉：2 小时、3 个 Token、1 个连字符

先说影响范围。据 LiteLLM 官方事故报告，带毒的 litellm==1.107.0 七个 wheel 全部中招，在 PyPI 上从北京时间 19:39 挂到约 21:23。Docker Hub 和 GHCR 上的 v1.107.0、latest、main-latest、main-stable 四个标签也被指向了带毒镜像，Docker Hub 一直到 22:20 才全部清掉。

再说它干了什么。 Datadog 安全实验室的分析显示，毒包往 site-packages 里多塞了三个文件：cook.pth、cook.py、sitecustomize.py。Python 每次启动都会自动执行它们，哪怕你的代码从没 import 过 litellm。

偷的东西包括：AWS / GCP / Azure 凭证，K8s、Vault、Terraform 密钥，SSH 和 GPG 私钥，Git、npm、PyPI 的 Token，.env 文件、shell 历史，浏览器保存的密码和 Cookie，各家大模型 API Key，以及 AI 编程工具的登录会话。如果你跑的是 LiteLLM Proxy 并接了数据库，它还会直接查库，把你配置的上游 Key 一起带走。另外还有一个每小时联网取代码执行的后门。

最值得程序员琢磨的，是攻击链。官方说法是：攻击者拿到了 3 名工程师的 GitHub CLI OAuth Token，其中一个属于组织所有者，用它关掉了分支保护，把发布流程指向一个假仓库 Berri-AI/litellm。真仓库叫 BerriAI/litellm，只差一个连字符。再用第二个账号通过审批，第三个账号删掉了流水线记录。GitHub 上的源码 tag 是干净的，毒只在构建产物里。

Token 从哪来？LiteLLM 称，他们观察到 Claude Code 在特定情况下会把用户的 GitHub CLI Token 写进响应内容；如果网关记录了响应日志，Token 就会进日志。而他们一个暴露在公网的内部 LiteLLM 部署里出现了可疑账号，攻击者据此从日志里拿到了 Token。官方也说，攻击者怎么进的内部部署还没确认，怀疑是一个最近才修的漏洞。截至发稿，我没查到 Anthropic 对这一说法的公开回应。

这已经是 LiteLLM 今年第二次被投毒，上一次是 3 月的 1.82.7 和 1.82.8。官方建议：钉死在 1.106.2，装过 1.107.0 的环境一律当作已失陷。

TOPIC 2

对程序员意味着什么

我的看法：这次真正的教训不在 Python，而在三件 Java 程序员每天都在做的事。

第一，浮动版本。很多人 docker-compose 里写的是 litellm/litellm:latest，跟 Maven 里写 LATEST、版本范围 [1.0,)，前端 package.json 里写 ^，本质上是同一种赌：下一次构建拉到什么，由别人决定。

第二，把模型的输入输出全量记日志。排查 Spring AI 问题时，很多人会打开 SimpleLoggerAdvisor 的 DEBUG 日志，再把日志接进 ELK。这次的链条说明：Agent 的输出里可能混进 Token，而日志系统往往比生产库更少人设防。

第三，AI 网关本身就是一个“钥匙串”。为了让 Spring Boot 项目、Claude Code 都走同一个入口，我们把所有模型 Key 塞进了一个服务。它一旦失守，丢的不是一个 Key，是全部。

所以别只是“没装过 1.107.0 就松口气”。这次没中，下一个被投毒的包也可能是你 pom.xml 里的某个依赖。

TOPIC 3

能上手的部分：自查、补救、加固

① 先自查（只用 shell，别先跑 python 或 pip）

官方特别提醒：在可能中毒的环境里，任何 Python 进程启动都会再触发一次恶意代码，包括 pip。所以下面只用 find、ls、grep、docker 命令。

bash

# 1) 找毒包目录和三个投毒文件（sitecustomize.py 有时是系统自带，cook.pth 才是强信号）

find / -path "*site-packages*" \( -name "litellm-1.107.0.dist-info" -o -name "cook.pth" -o -name "cook.py" -o -name "sitecustomize.py" \) 2>/dev/null

# 2) 感染标记和后门锁文件（找不到也不代表干净）

ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null

# 3) 依赖清单里有没有 litellm、写没写死版本

grep -rn "litellm" --include="requirements*.txt" --include="pyproject.toml" --include="poetry.lock" --include="uv.lock" .

# 4) Docker：本地镜像 digest 是否命中官方公布的带毒镜像

docker images --digests | grep -i litellm | grep 1bbcb1443bc9

② 中招了怎么办（按官方顺序）

• 用 shell 删掉 site-packages 里的 cook.pth、cook.py、sitecustomize.py，以及 __pycache__ 里对应的 .pyc。

• 杀掉占着 /tmp/remote_code_loader.lock 的后台 Python 进程。

• 最好整个重建虚拟环境或镜像，再装 litellm==1.106.2。

• 从一台干净的机器上，轮换这台机器能碰到的所有凭证：云账号角色、网关里存的每个模型 Key、网关主 Key 和虚拟 Key、数据库密码、环境变量里的一切。

• 回头查云厂商的审计日志，看这些凭证有没有在你的基础设施之外被用过。

③ Java 项目：用 Maven Enforcer 禁掉浮动版本

banDynamicVersions 规则会拦下版本范围、LATEST / RELEASE 和 -SNAPSHOT。下面这段放进 pom.xml 的 <build><plugins>：

xml

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-enforcer-plugin</artifactId>

<id>ban-dynamic-versions</id>

<goals><goal>enforce</goal></goals>

</execution></executions>

</plugin>

Docker 镜像同理：别用 latest，用镜像名@sha256:digest 钉死你核对过的版本。

④ 生产环境别全量记录模型输入输出

Spring AI 的 SimpleLoggerAdvisor 只在 DEBUG 级别输出完整请求和响应。在 application-prod.properties 里压住它：

properties

logging.level.org.springframework.ai.chat.client.advisor=INFO

⑤ 别让 Claude Code 碰到你的 GitHub Token

在项目的 .claude/settings.json 里加一条 deny 规则（语法以 Claude Code 官方 permissions 文档为准）：

json

{

"permissions": {

"deny": ["Bash(gh auth token*)"]

}

再跑一下 gh auth status，看看本机 Token 有哪些权限。服务器和 CI 上别用个人账号的 gh 登录，换成权限最小的 fine-grained Token。

∞

THE END

写在最后

一个连字符的假仓库，加上几把从日志里捡到的 Token，就能让一个周下载 2300 万的项目，用“正规流程”把毒包发出去。

AI 编程让我们装依赖、接网关、开 Agent 的速度都快了好几倍。锁版本、少记日志、Token 最小权限，这三件事反而更不能省。

💬 互动一下：你的 AI 网关或 docker-compose 里，现在还有几个 latest？自查完把结果发在评论区，顺便说说你是怎么管模型 Key 的。

「每天一条 AI 编程大事，讲清它对程序员的影响，关注不迷路。」

参考来源

1. LiteLLM 官方事故报告（时间线、受影响版本、攻击链、补救步骤，持续更新）：https://docs.litellm.ai/blog/security-incident-oct-21-2026

2. Datadog Security Labs，LiteLLM supply chain compromise（约 2300 万周下载、投毒文件、窃取范围、IOC）：https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/

3. JFrog Security Research，LiteLLM Hijacked Again（七个 wheel 全中、sdist 不含投毒文件）：https://research.jfrog.com/post/litellm-hijacked-again/

4. Wiz Blog，LiteLLM Compromised, Steals Credentials（窃取模块、查询网关数据库）：https://www.wiz.io/blog/litellm-compromised-steals-credentials

5. Aikido Security 在 X 上的首发预警：https://x.com/AikidoSecurity/status/2112892021170151795

6. GitHub issue #47826（社区跟进）：https://github.com/BerriAI/litellm/issues/47826

7. Apache Maven Enforcer，banDynamicVersions 规则：https://maven.apache.org/enforcer/enforcer-rules/banDynamicVersions.html

8. Claude Code 官方文档，Configure permissions：https://code.claude.com/docs/en/permissions

—— END ——

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。

周下载 2300 万的 LiteLLM 被投毒:1.107.0 只上线 2 小时,装过就得换掉所有 Key

来龙去脉：2 小时、3 个 Token、1 个连字符

对程序员意味着什么

能上手的部分：自查、补救、加固

写在最后

2026年企业AI转型白皮书(附下载)

2026年购物应用洞察报告(附下载)