LiteLLM 1.107.0 被投毒：自建 AI 网关 10 分钟自查清单，和要不要换托管网关

先给结论：只要你的机器、CI 或容器在 2026-10-21 装过 LiteLLM 1.107.0，或拉过那天的 latest / main-latest / main-stable 镜像，就按「已泄露」处理：先把 LiteLLM 里配的所有上游 API Key 和这台机器上的云凭证全部轮换，再查有没有残留，最后把版本钉死在 1.106.2 或之后的官方修复版。 没装过这个版本的，也值得借这次把「网关升级方式」和「Key 放在哪」重新想一遍。

以下事实来自 Wiz Research 2026-10-21 的分析（原文）和 BerriAI 的事后说明，时间均为 UTC，北京时间加 8 小时。

发生了什么，一张表说清

项目	内容
恶意版本	LiteLLM 1.107.0（PyPI 包 + GHCR / Docker Hub 镜像）
上架时间	10-21 11:39 UTC 上传 PyPI，13:20 UTC 被隔离
下载量	约 49,000 次（ClickPy 数据）
受影响镜像标签	v1.107.0、latest、main-latest、main-stable，约 13:53 UTC 下架
最近的安全版本	v1.106.2
偷什么	浏览器密码和 Cookie、AWS / GCP / Azure 凭证、OpenAI / Anthropic 等 LLM 的 API Key、SSH / GPG 私钥、Shell 历史；还会直接查 LiteLLM Proxy 的 PostgreSQL 表 LiteLLM_CredentialsTable，把你配的上游 Key 一次拿走
外发地址	仿冒域名 www.litellm[.]dev/healthcheck
已观察到的利用	外发约 4.5 小时后，攻击者开始用偷到的 AWS 凭证调 Bedrock 列模型，典型的「盗用你的额度跑模型」

入口也值得记一下：BerriAI 说攻击者先进了他们一个暴露在公网的内部 LiteLLM 部署，从日志里拿到了被写进响应体的 GitHub CLI OAuth Token，再用三位工程师的账号走完了发版流程。网关本身是被攻破的第一站，日志是第二站。

10 分钟自查：四步，按顺序做

1. 查版本：装过 1.107.0 没有

pip show litellm 2>/dev/null | grep -i '^version'
# 用 uv / poetry 的，顺便查锁文件里有没有写进去
grep -rn "litellm" requirements*.txt uv.lock poetry.lock 2>/dev/null | grep "1.107.0"

当前版本不是 1.107.0 不代表安全：10-21 那两个小时里如果 CI 跑过一次 pip install -U litellm，后来又被别的版本覆盖，凭证照样已经发出去了。翻一下那天的 CI 日志和构建产物。

2. 查残留文件：恶意包落在 site-packages 根目录

恶意包会往 site-packages 根目录放三个文件：cook.pth、cook.py、sitecustomize.py。.pth 和 sitecustomize.py 的特点是每次启动 Python 解释器都会执行，所以卸载 LiteLLM 不等于清干净。

python3 - <<'PY'
import site, os
for d in site.getsitepackages() + [site.getusersitepackages()]:
    for f in ("cook.pth", "cook.py", "sitecustomize.py"):
        p = os.path.join(d, f)
        if os.path.exists(p):
            print("发现:", p)
PY
ls -la /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null && echo "运行标记存在，说明窃取程序已执行过"

注意 sitecustomize.py 有少数项目自己也会用，发现后先看内容再删，别误删自家的。Wiz 也给了各文件的 SHA256，可以对着哈希核实。

3. 查镜像：看 digest，不看标签

那天拉过 latest 的容器，标签名现在已经指向别的镜像了，只看标签会误判。看本机实际跑的镜像 digest：

docker images --digests | grep -i litellm
docker ps --format '{{.Image}} {{.ID}}' | grep -i litellm

对照 Wiz 公布的受影响 digest，比如 ghcr.io/berriai/litellm:v1.107.0 的 amd64 是 bd1aeee4…、arm64 是 56b74573…（完整列表见原文）。Kubernetes 里也一样，查 Pod 实际的 imageID。

4. 查外连：有没有连过仿冒域名

在 DNS 日志、出口代理、云防火墙日志里搜 litellm.dev（注意是 .dev，不是官方域名），以及请求头 X-Token: XWiA8gZNa7NcX2XRoAEb。有命中，就是确认外发了。

轮换顺序：先止血最贵的

确认或怀疑中招后，按「被盗用最花钱」的顺序轮换，不要只换一个：

1. LiteLLM 里配置的所有上游 LLM Key：窃取程序直接读了凭证表，有一个算一个；到各家控制台作废旧 Key，顺便看近几天用量有没有异常峰值。
2. 云凭证：AWS Access Key、实例角色涉及的权限、GCP 服务账号、Azure Token。Wiz 观察到的利用就是拿 AWS 凭证调 Bedrock。
3. GitHub / CI Token：这次事件本身就是从 GitHub CLI Token 开始的。
4. SSH / GPG 私钥、浏览器里保存的密码和会话：那台机器上登录过的后台都算。

换完再升级：把 LiteLLM 钉在 1.106.2 或官方发布的后续修复版，pip install 用 --require-hashes，Docker 用 image@sha256:… 引用 digest，别再在生产里拉 latest。

继续自建，还是换托管网关？

这次事件之后，很多团队会问这个问题。两种都有道理，取舍如下：

	继续自建 LiteLLM / one-api	用托管网关
上游 Key 在哪	你的服务器和数据库里，一台机器被攻破就全丢	在网关服务商那里，你手里只有一个网关 Key
出事后的作废范围	每家上游 Key 都要逐个作废、重配	作废一个网关 Key，重新生成即可
升级与供应链	自己钉版本、核哈希、跟安全公告	服务商负责，你看不到也管不了
信任对象	开源项目 + 它的发版流程	网关服务商
模型覆盖	你接什么就有什么	取决于服务商
成本	软件免费，运维时间自己出	按量付费，含中间层成本

说实话，托管不是「更安全」的同义词，它只是把风险换了个地方：你不用再管升级和供应链，但要信任服务商，而且服务商也可能出事。它真正改变的是爆炸半径——你的应用里只有一个网关 Key，泄露时作废它就行，不用连夜去五家控制台换 Key。

所以可以这样选：

• 要 GPT、Claude、Gemini，或必须把 Key 握在自己手里：继续自建，但把上面的钉版本、核哈希、不把管理后台暴露到公网、日志不记完整响应体这几条做成默认配置。
• 主要用国产模型、团队没人专职管网关：托管网关更省心。以 不墨 Router 为例，一个 Key 调用 GLM、Kimi、DeepSeek、Qwen、MiniMax 等国产模型（2026-10-24 核对 /v1/models 返回 28 个），兼容 OpenAI 和 Claude 接口，人民币按量付费。它没有 GPT、Claude、Gemini，如果你的业务离不开它们，它不适合你。

从 LiteLLM 迁过去，客户端通常只改 Base URL、Key 和模型 ID：

export OPENAI_BASE_URL="https://router.bumo.cc/v1"
export OPENAI_API_KEY="sk-你的RouterKey"
# 模型 ID 以 /v1/models 返回为准，例如
export OPENAI_MODEL="deepseek/deepseek-v4-pro"

LiteLLM 里写的 deepseek/deepseek-chat 这类名字要换成网关自己的 ID，先调一次 /v1/models 确认，能省掉大部分 404。

一句话总结

装过 1.107.0 就当已泄露：先换 Key、再查残留、最后钉版本。至于自建还是托管，看你需要的模型和有没有人专职管网关，不要因为一次事件就把整套架构推倒，也不要假装这次和你无关。

前往不墨 Router 查看当前模型和价格，一个 Key 接国产模型，泄露了作废一个就行。

Router 开发者接入与价格

• OpenRouter 国内访问和付款不方便？4 种替代方案对比
• DeepSeek API 接 OpenAI SDK：Python / Node.js
• Kimi K3、GLM、DeepSeek、MiniMax API 价格对比