LiteLLM 投毒事件全解析：网关排查、应急响应与安全加固指南

昨晚 AI Infra 群里有人扔了一条消息，瞬间炸了锅：“喔去，litellm 竟然被投毒了”。我第一反应不是震惊，而是“怕什么来什么”。LiteLLM 这个东西，说大不大，说小不小，但只要是做企业级大模型接入的人，十有八九都在用：它把 OpenAI、Anthropic、Gemini、国产各家模型全部封装成一套 OpenAI 兼容接口，还能做 Key 管理、路由、限流、预算控制。在很多公司里，LiteLLM Proxy 就是连接业务系统和模型厂商之间的唯一闸门。如果这个闸门里的代码出了问题，后果不是某个服务挂掉那么简单，而是所有上游模型 Key、所有经过网关的请求内容，都可能被劫持。

这篇文章想解决三件事。第一，这次说的“投毒”到底是怎么发生的，为什么偏偏是 LiteLLM 这种网关型组件容易被盯上。第二，如果你的机器或者服务器上跑过 LiteLLM，现在应该按什么顺序检查哪些文件、哪些配置、哪些日志，来判断自己有没有中招。第三，不管中招没有，以后怎么系统性加固，让同类攻击再进来也拿不到关键东西。文章不会劝你先重装系统，也不会让你删库跑路，但会给你一套可以照着抄的排查清单和应急步骤。

1. 先搞清楚“投毒”的对象：不是模型被改傻，是供应链和账号层被污染

很多人看到“投毒”两个字，第一反应是“大模型的回答被篡改了，模型智商下降了”。这一轮曝出来的问题并不是模型权重被篡改，而是 LiteLLM 这个基础设施组件本身被污染。基础设施一旦被污染，比单个模型出问题的覆盖面大得多：攻击者拿到的不是某一个模型的输出，而是你所有模型的调用入口、密钥、路由策略和原始流量。

1.1 LiteLLM 在生产环境里的真实位置

LiteLLM 最常见的两种用法，分别是 SDK 模式和 Proxy 模式。SDK 模式就是在业务代码里直接调用 litellm.completion()，把不同模型厂商的差异隐藏在一个库后面。Proxy 模式则是单独跑一个网关服务，业务系统只认这个网关的地址和 Key，网关再负责把请求转发给 OpenAI、Anthropic、Gemini 等真实厂商。

大多数上点规模的公司都会用 Proxy 模式，因为 Proxy 能集中管理 Key、做预算控制和请求日志，还能在不改业务代码的情况下切换模型供应商。这带来了一个非常危险的结果：这个进程天然握有大量上游厂商的真实 API Key，而且所有业务请求都会经过它。对攻击者来说，这就是“一把钥匙能开一栋楼”。投毒者选中这种组件，不是因为它叫 LiteLLM，而是因为它处在“代理所有模型流量”的枢纽位置。

1.2 这一轮“投毒”涉及的三种形态

把“投毒”这个词拆开看，至少能分成三类。第一类是最常见的供应链投毒，攻击者通过伪造同名包、依赖混淆或者篡改已发布包的方式，让安装者把恶意代码带进环境。第二类可以叫账号投毒，攻击者不一定会让引擎立即崩溃，而是在数据库里种下影子 Key、后门用户，之后随时可以用合法身份调用网关。第三类我习惯叫标签投毒或路由投毒，攻击者改掉模型列表、路由标签或 endpoint 配置，把正常请求悄悄引到攻击者自己的服务上。

这一轮曝光的事件里，三类形态几乎是串成一条链的：恶意安装包进入机器，先偷配置里的 Key；攻击者再用偷到的管理权限创建虚拟 Key、修改路由配置；最后整个网关都在替攻击者打工，但表面上看服务一直没有中断，监控报表也很正常，只有费用明细和某些日志能露出马脚。

1.3 为什么排查通知里会提到“mini shai-hulud 蠕虫”

这次社区流传的排查通知里出现了一个名字“mini shai-hulud”，越看越像是一次针对 LiteLLM 的横向扩散测试。它的思路大概是：如果一台 LiteLLM Proxy 的管理 Key 是弱密钥、默认密钥，或者已经通过供应链投毒泄漏出去，攻击者就会调用管理接口生成更多的合法 Key，然后从这台机器跳到同网段的其他实例，继续重复同样操作。

这个蠕虫最讨厌的地方是它不破坏文件、不删数据，也不让进程崩溃，所以常规的“机器有没有变卡”“服务有没有挂”根本发现不了。它只是在账号体系和路由配置里慢慢“养蛊”。如果你的网络里有多个 LiteLLM 实例，或者同一个管理 Key 被多套环境共用，扩散速度会非常快。这也是为什么光看进程列表和 CPU 占用没有用，真正要看的是 Key 的产生记录和路由配置有没有异常变化。

2. 本地环境自测：5 分钟找出常见中毒痕迹

下面这套检查流程是给“怀疑自己中招”的人准备的。顺序很重要：先看安装物，再看进程和网络外联，然后翻配置和数据库，最后查日志和路由。每一步都不需要另外装什么高级工具，纯命令行就能完成。

2.1 先看装了什么，而不是急着卸载

多数人听到“投毒”后的第一反应是 pip uninstall litellm。先别急，卸载动作会把现场破坏掉。正确的做法是先确认当前环境里到底装了哪些包、来自什么位置、版本号对不对。

bash复制# 查看所有与 litellm 相关的包
pip list --format=freeze | grep -i litellm

# 查看 litellm 的安装详情
pip show litellm

# 确认运行时实际加载的文件路径
python -c "import litellm; print(litellm.__file__, litellm.__version__)"

需要特别注意的是，pip show 显示的版本号正常并不等于安全。供应链投毒有时会做成高仿包，比如把真实 LiteLLM 的版本号抄过来，但 Home-page、作者邮箱、文件结构都和官方不一致。也有另一种更隐蔽的情况：恶意代码被写成依赖项，藏在某个不起眼的小工具包里，LiteLLM 本体完全正常。所以要结合 pipdeptree 看依赖树，确认有没有突然多出来的包：

bash复制# 查看依赖树
pip install pipdeptree
pipdeptree | grep -i litellm -A 20

如果发现依赖树里多了不认识的库，或者 litellm 目录里出现了官方版本中没有的 .py 文件，就要提高警惕了。还有一种容易被忽略的检查点：Python 的 sitecustomize.py、usercustomize.py、.pth 文件，它们会在解释器启动时自动执行，只要被塞进一行恶意代码，整个虚拟环境里所有 Python 程序都会被殃及。

2.2 看进程和网络外联，建立域名白名单

如果 LiteLLM 或恶意代码正在和外部通信，进程级联查一般能看到蛛丝马迹。

bash复制# 查看是否有 litellm 相关进程
ps aux | grep -i litellm

# 查看 Python 进程建立的 TCP 连接
lsof -nP -iTCP -sTCP:ESTABLISHED | grep python

# 如果开了 Proxy，默认监听 4000 端口
ss -tnp | grep 4000

这一步的关键不是“有没有外部连接”，而是“连接到哪些地址”。LiteLLM 正常运行时会访问 OpenAI、Anthropic、Google 等模型的官方域名，也会有必要的 telemetry 上报。如果你发现某个 Python 进程正在连接一个与模型厂商无关、你没配置过的域名，或者干脆是一个裸 IP 地址，那中招的概率就非常大。

更好一点的做法是平时就维护一份“允许访问域名列表”，把模型厂商官方域名、OCR 服务、向量数据库等写清楚。排查时直接拿这份列表比对 lsof 或 ss 的输出。实际运维中，我们抓过很多次“异常外联”，最后发现是某个工程师偷偷在服务器上跑了一个代理工具，并不一定是投毒，但这类行为也应该一并处理干净。

2.3 翻配置文件和数据库，看 Key 有没有异常变化

LiteLLM Proxy 的配置默认位于 ~/.litellm/config.yaml，目录下还可能有运行时生成的 sqlite 数据库文件。先看配置本身：

bash复制# 列出 .litellm 目录所有文件
ls -la ~/.litellm/

# 查看当前配置内容
cat ~/.litellm/config.yaml

# 查看环境变量中是否有相关修改痕迹
env | grep -i litellm

检查配置时，重点看 model_list 里的每一项。正常配置应该长这样：

yaml复制model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_base: https://api.openai.com/v1
      api_key: os.environ/OPENAI_API_KEY

如果发现某个 model_name 仍然是 gpt-4o，但 api_base 被改成了一段你不认识的地址，或者 model 字段从 openai/gpt-4o 变成了某个自定义字符串，这就属于非常典型的路由投毒迹象。攻击者用这种方式，可以让你的请求先送到他的服务器，再由他的服务器转发给真正的模型厂商，于是所有明文请求内容都被他截获一份。

数据库层面，如果 LiteLLM Proxy 使用的是默认 sqlite，可以直接用 sqlite3 查询。实际生产环境大多使用 Postgres，表名以你实际部署版本为准，一般包含 LiteLLM_VerificationToken、LiteLLM_UserTable 这类表。检查思路是看有没有不认识的虚拟 Key 被创建：

sql复制SELECT *
FROM "LiteLLM_VerificationToken"
ORDER BY "created_at" DESC
LIMIT 100;

重点看三点：创建时间是不是在最近几天；key_owner 是不是你认识的人或服务；expiry 是不是被设置成了非常远的未来。如果你看到一堆 key_alias 是乱码、创建时间还是凌晨三点的记录，基本就能判定账号层已经被动过了。

2.4 翻日志和费用报表，看流量有没有被改道

LiteLLM Proxy 默认会记录请求的模型、用户、花费和耗时。先看本地日志文件，再看 /health 和 /spend/logs 接口。

bash复制# 查看 .litellm 目录下的日志文件
tail -n 200 ~/.litellm/*.log 2>/dev/null

# 如果 Proxy 正在本机运行，可以直接请求 spend 日志接口
curl -s http://127.0.0.1:4000/spend/logs \
  -H "Authorization: Bearer $LITELLM_KEY" | jq '.data[] | {model, user, spend, request_id}'

排查时需要留意的几个异常信号。第一，某个平时用量很小的 model，突然出现大量调用；第二，某个 user 字段对应的根本不是你们内部的服务账号；第三，同一个 model_name 在不同时间段的 api_base 或响应头不一样。如果前两个信号都没排查出问题，第三个信号特别能说明路由被改道了：攻击者会把自己的服务伪装成你常用的模型名，但真实响应速度、错误格式、响应头都会和官方有细微差异。

这部分排查还有一个很实用的动作：把最近的 model spend 报表导出来，按 model_name 和 daily_cost 排序，看看有没有“幽灵模型”在产生费用。大模型投毒测试里常说的一句话是：模型本身不会自己烧钱，烧钱的背后一定有一个正在使用它的人或服务。这句话反过来也成立，费用异常是账号被投毒的最直接信号之一。

3. 疑似中招后的处置：别急着删除，先按顺序处理

如果上面的自测已经发现明显异常，接下来进入应急阶段。很多团队会在这时候犯一个致命错误：看到恶意包就删掉，看到可疑进程就杀掉，结果把自己的取证链切断了，也让攻击者提前感知到你在处置。正确顺序是“先隔离、再吊销、后清理、最后重建”。

3.1 为什么要先隔离而不是先清理

投毒类攻击和普通故障不一样。普通故障是环境坏了，你修好就能用。投毒是现场可能有“活人”，你这边刚把后门关掉，他那边立刻会用备用通道重新进来。所以第一步永远是把“被攻陷的环境”和“可信网络”隔离开。

建议按这样的步骤操作：

1. 先记录当前进程列表、网络连接、Docker 容器列表和系统时间，便于后续分析。
2. 在防火墙或安全组层面封掉该机器的出网流量，阻断恶意外联。
3. 停止 LiteLLM 服务，使用正常的停止命令，不要先 kill -9。
4. 只读备份 ~/.litellm/config.yaml、数据库文件和相关日志。
5. 确认备份完成后，再进入清理阶段。

这里要特别提醒：备份配置和数据库文件时不要直接“复制后继续在原文件上修改”，尽量保留原始副本。之后如果你要找官方支持或做安全分析，这些原始文件是第一手证据。

3.2 撤销密钥的顺序比想象中更重要

不少人被投毒后第一个动作是去改上游供应商的 API Key，这没错，但顺序可能不对。如果攻击者已经拿到了你的 LiteLLM master key，那你改完上游 Key 后，他照样能通过网关看到新 Key，或者直接用 master key 再次生成新的虚拟 Key。所以正确的吊销顺序是：

1. 去 OpenAI、Anthropic、Azure 等真实模型供应商的控制台，吊销可能被泄漏的上游 API Key。
2. 轮换 LiteLLM Proxy 的 master key，也就是 LITELLM_MASTER_KEY 对应的值。
3. 停用或删除数据库中所有由攻击者创建的虚拟 Key。
4. 轮换数据库连接凭据，避免攻击者直接连库删库。
5. 最后才允许业务系统用新 Key 连回新的网关。

如果你用的是 LiteLLM Proxy 的管理 API，可以在隔离环境下先调用 /key/delete 或 /user/delete 来清理异常 Key。注意不要一边把新 master key 写进配置，一边让还没清理的旧服务继续运行，因为旧进程可能还在内存里留着旧 Key，甚至会自动把新 Key 再次外传。

3.3 清理恶意包和残留文件，别在原环境上打补丁

供应链投毒最麻烦的是，恶意代码可能分散在多个位置。常见挂载点包括 Python 包本体、依赖包、sitecustomize.py、.pth 文件、pip 配置文件、shell 启动脚本和环境变量。靠手工逐个删除容易漏，所以我的建议是：

• 如果这台机器还能重建，直接把原环境标记为“已污染”，不要继续在上面修。
• 在干净虚拟机或容器里重新安装 Python 环境。
• 原环境先保留一份完整快照，等后续分析完成后再销毁。
• 如果因为业务原因必须保留原环境，至少先删掉可疑的 sitecustomize.py、usercustomize.py 和异常 .pth 文件，再检查 pip 配置里有没有被加入额外的 index-url。

为什么会强调“别在原环境上打补丁”？因为投毒包的恶意代码往往会在安装阶段写入多个复用点。你删掉一个文件，下次某个进程启动时又会被写回来。与其和攻击者玩猫鼠游戏，不如直接换一个干净基础环境，让所有启动文件都从可信来源重新生成。

3.4 重建环境时，锁定版本、锁定来源、锁定哈希

重建 LiteLLM 环境不是简单执行一句 pip install litellm 就完事。如果要避免二次踩坑，需要引入依赖锁和哈希校验。推荐的流程是：

bash复制# 在干净环境中安装 pip-tools
pip install pip-tools

# 编写 requirements.in，里面只写顶层依赖
echo "litellm==具体版本" > requirements.in

# 生成带哈希的锁定文件
pip-compile --generate-hashes requirements.in -o requirements.txt

# 安装时强制校验哈希
pip install --require-hashes -r requirements.txt

如果你用的是 Docker 镜像，更建议在 Dockerfile 里用多阶段构建，先在一个临时阶段下载好所有 wheel 包，再复制到运行阶段，运行阶段不保留 pip 和网络权限：

dockerfile复制FROM python:3.11-slim as builder
WORKDIR /wheels
COPY requirements.txt .
RUN pip wheel --no-cache-dir --no-deps -r requirements.txt

FROM python:3.11-slim
COPY --from=builder /wheels /wheels
RUN pip install --no-index --find-links=/wheels -r requirements.txt

这种做法的核心理念是：安装阶段和生产阶段隔离，运行时进程没有权限再下载新包。对投毒类攻击来说，断掉“运行中下载”这条路，比任何杀毒软件都有效。

4. “账号投毒”和“标签投毒”到底藏在哪里

这一节要把两个容易忽略的概念讲透。社区通知里反复提到“账号投毒事件”和“标签投毒”，这两个词听起来像一回事，实际上藏的位置完全不同。

4.1 影子 Key：账号投毒的常见形态

账号投毒的典型产物是“影子 Key”。它不会以一个独立的恶意进程存在，而是作为一条合法记录存在于 LiteLLM 的数据库里。攻击者拿到 master key 之后，调用管理接口生成一个新的虚拟 Key，名字可能是“ops-test”，owner 可能是空字符串，然后它就可以通过这个 Key正常调用网关。

影子 Key 的危险性在于，它完全复用了你正常的认证体系，因此日志审计里不会有异常登录记录，也不会有陌生 IP 爆破。它就像有人偷偷配了一把你们公司大门的钥匙，然后每天从正门进出，门禁系统只认钥匙不认人，当然查不出来。

清理影子 Key 的时候，不要只看“现在有几个在用”。“使用中”的 Key 只是冰山一角，攻击者可能会做很多的 Key 并存，有的用于调用模型，有的用于调用管理接口，有的只是备胎。检查数据库时，我最看重的字段是 expiry 和 created_at。如果某个 Key 的过期时间被设置到三年后，而 owner 字段是空，那基本可以直接判为可疑。

4.2 标签投毒：流量被静默改道的一种隐蔽方式

标签投毒藏在路由配置层。LiteLLM Router 在分发请求时，会根据模型名、模型组、负载均衡策略和标签信息选择实际的上游。如果攻击者可以修改配置或数据库，他不需要删除原来的模型，只需要插入一个新条目：model_name 仍然显示 gpt-4o，但 api_base 指向攻击者服务器的地址，并给它打上一个较低延迟的标签。Router 发现这个新条目后，可能就会优先把请求发过去。

你可能觉得“我检查过配置，模型名都对得上”，但请记住，LiteLLM 的配置不一定只来自 YAML 文件。它还可能从数据库动态读取模型列表，或者通过管理接口修改内存中的路由规则。如果你只检查磁盘上的 config.yaml，漏掉数据库里的动态配置，那就看不到被篡改的路由。

所以，标签投毒的排查思路应该是“校验路由目标”：

• 逐个模型发起最低成本的测试请求，确认实际返回链路和你配置的一致。
• 对比响应头、耗时、错误格式是否与厂商官方服务匹配。
• 查看 model spend 报表中是否存在“你以为调用 A 厂商，实际账单记录却指向 B 厂商”的情况。
• 如果开启了日志，检查日志中记录的 target endpoint 或 api_base 字段，而不是只看用户提交的 model_name。

给模型打标签并不是坏事，很多团队会合理利用 labels、tags 做模型分组和成本归因。问题在于，一旦标签体系被滥用，就能让恶意模型混入正常模型组里，审计人员按正常模型名搜索永远搜不到异常。因此，对标签和别名的变更要做到“可审计、可回滚”，最好进入 Git 管理，而不是让运维直接在服务器上改配置。

4.3 蠕虫传播给我们的三点启示

讨论 mini shai-hulud 这种蠕虫的意义，不只是“有个恶意样本很厉害”，而是它点出了三个防御盲区。

第一，LiteLLM Proxy 的管理端口不能默认暴露在业务内网所有机器可达的位置。很多公司把网关部署在 Kubernetes 里，用 NodePort 或者 LoadBalancer 直接暴露，结果整个集群里任何 Pod 都能访问，一旦其中一个 Pod 被攻破，横向扩散只是时间问题。

第二，管理 Key 和业务 Key 必须分离开。一个业务服务只需要调用 /chat/completions 的能力，根本不需要调用 /key/generate 的权限。如果你给所有应用都发同一个拥有全部权限的 Key，那就等于给了攻击者一把万能钥匙。

第三，数据库权限要独立。LiteLLM Proxy 如果使用 Postgres 保存虚拟 Key、用户和预算数据，应用账号不应该拥有销毁整张表的权限。把数据库连接地址和凭据严格控制住，相当于给已经失守的 Proxy 层又加了一道隔离墙。

5. 日常防御：几条可以直接抄的加固配置

聊完投毒的机制，再看未来怎么防。这里不是推荐大家上多贵的商业安全产品，而是把一些不花什么钱、但很有效的配置习惯整理出来。我自己的生产环境已经按下面这套方式跑了很长时间，效果很好。

5.1 Master Key 一定要强随机，不能 “dev-123456”

LiteLLM 的 master key 相当于整个网关的管理员密码。如果你还在用 sk-1234 或者项目名加年份这种格式，那和没锁门没有区别。生成方式可以用系统工具：

bash复制openssl rand -base64 48

环境变量里配置为：

bash复制export LITELLM_MASTER_KEY="你生成的随机字符串"

同时注意不要把 master key 写进代码仓库。最保险的做法是通过密钥管理服务注入，比如 Kubernetes Secret、AWS Secrets Manager、Vault。如果你只是在一台服务器上跑，至少也要把 .env 文件的权限改成只有运行用户可读。

5.2 Proxy 监听地址不要裸奔到公网

很多本地部署教程为了让用户方便测试，会直接教 docker run -p 4000:4000。这在生产环境等于把大门敞开。更稳妥的做法是只监听回环地址或内网地址：

bash复制docker run -d --name litellm-proxy \
  -p 127.0.0.1:4000:4000 \
  -e LITELLM_MASTER_KEY="...自己的key..." \
  ghcr.io/berriai/litellm:main-latest

如果业务系统部署在另一台机器，也应该把网关放在专有网络内部，通过防火墙规则只允许可信来源访问，而不是对全公网开放。毕竟管理接口和业务接口在同一个端口上，暴露公网意味着任何人都可以尝试访问 /health、/key/list，一旦 master key 强度不够，爆破只是时间问题。

5.3 业务侧一律使用虚拟 Key，不要发 master key

LiteLLM 本身支持生成虚拟 Key，可以让每个应用、每个开发环境都有自己的独立 Key。这样做的收益是：即使某个应用的 Key 泄漏了，你只需要吊销这一把，不会影响其他业务；同时还能通过 spend 统计定位到具体是哪个应用在烧钱。建议在创建虚拟 Key 时设置过期时间，并在 metadata 里标明归属人。

如果某个业务服务只是需要调用模型，千万别给它开通 /key/generate 这样的管理权限。最小权限原则在网关层同样适用。我见过不少团队为了省事，直接在所有应用配置里填 master key，结果一次日志泄露，整个网关的钥匙都被偷了。

5.4 用锁文件和哈希锁住所有 Python 依赖

供应链投毒最主要的入口就是 pip 安装过程。没有锁文件时，每次构建可能拉到一个恶意版本。有了 requirements.txt 的哈希锁，构建时只要哈希对不上就会直接报错，可以在安装阶段就把投毒包拦下来。

如果你维护的是 Docker 镜像，建议把 requirements 锁文件单独 COPY 到镜像中，并设置 pip 不要访问外部 index：

dockerfile复制RUN pip install --no-cache-dir --require-hashes \
    -r requirements.txt

同时可以加一个 --no-index 参数，配合本地 wheel 目录使用，彻底断掉构建时从外部源下载的可能。这个习惯一旦养成，后续想升级版本也会更谨慎，因为你会主动对比新旧版本的哈希和来源。

5.5 给数据库权限做减法，并保留审计日志

LiteLLM 用 Postgres 保存数据时，不要直接在连接串里写 postgres 超级用户。单独建一个账户，只授予必要的表级权限。这样即使 Proxy 被攻破，攻击者也没法通过这个连接串直接清空数据库。另一个建议是开启数据库的查询日志，至少保存一段时间。前面提到的“影子 Key”排查，如果数据库自己有审计日志，你可以知道攻击者是什么时候、用哪个客户端调用了 INSERT 或 UPDATE。

备份策略也要跟上。建议至少保留 7 天的数据库自动备份，发生投毒后可以从攻击发生前的时间点恢复。恢复前要注意，配置文件和密钥文件必须一并恢复到同步时间点，否则会出现“数据库里的 Key 已更新、代理配置还是旧 Key”的问题。

5.6 为关键行为设置告警

很多投毒攻击不是一瞬间完成的，而是花了几天甚至几周潜伏。如果你有日志系统，建议给两类行为设置告警：一类是新 Key 产生的行为，尤其是管理员 Key 创建虚拟 Key；另一类是路由配置发生变化的行为。LiteLLM 本身没有完整的告警体系，但你可以定时轮询数据库或管理接口，检测新增行和配置变更。

监控不需要一开始就做得很重。可以先写一个最简单的脚本，每小时统计一次虚拟 Key 数量，如果比前一小时多，就发一条钉钉或 Slack 消息。这样即便攻击者真的创建了影子 Key，你也能在几个小时内发现，而不是等月底账单出来才察觉。

5.7 定期做“干净基线”对比

投毒攻击最怕你有一个“干净基线”。建议专门维护一台不用于生产的纯净环境，定期从官方源安装指定版本的 LiteLLM，把包列表、文件列表、哈希值全部保存下来。生产环境安装完后，用同样的方式生成一份清单，两份做 diff。

bash复制# 在干净环境生成基线
pip freeze > baseline.lock

# 在生产环境生成审计清单
pip freeze > current.lock

# 对比差异
diff baseline.lock current.lock

另外，把 LiteLLM 的 config.yaml 纳入 Git 仓库管理。以后不管谁在服务器上改了配置，只要提交记录里没有对应变更，就能立刻发现异常。Git 的历史记录同时也是非常好的取证工具，能告诉你某个模型路由是什么时候开始变的。

6. 我踩过的排查坑和常见问题速查

最后整理几个我实际操作中遇到的典型问题，不看可能会少走不少弯路。

6.1 版本号正常就一定安全吗

不一定。我就遇到过一起类似事件，某台机器上 pip show litellm 显示的版本号和官方一致，看起来完全正常，但 site-packages 里的文件已经被替换过了。原因是攻击者把恶意代码作为包安装后的 hook 注入了已有的 litellm 目录，或者用依赖混淆方式覆盖了部分文件。所以版本号正常只是必要条件，不是充分条件。更可靠的做法是比对文件哈希，或者直接把整个 site-packages 目录和干净环境做 diff。

推荐方式：

bash复制# 检查 litellm 包内所有文件
find $(python -c "import litellm, os; print(os.path.dirname(litellm.__file__))") -type f

# 检查是否有非官方常见的可疑文件
find $(python -c "import litellm, os; print(os.path.dirname(litellm.__file__))") -name "*.py" | xargs ls -la

如果你能拿出官方 sdist 的 tarball，直接用 diff 对比文件内容，是最稳的方案。

6.2 只用了 LiteLLM SDK，没跑 Proxy，需要排查吗

需要。SDK 模式虽然不会打开 4000 端口，但它的安装入口同样面临供应链投毒风险。恶意代码不一定要通过 Proxy 的 Web 功能起作用，它可以趁你 import litellm 时读取环境变量里的 OpenAI Key，然后把数据传到攻击者服务器。排查思路和 Proxy 一样：看安装物、看进程外联、看配置目录。另一个额外检查点是你写业务代码的机器上有没有多出可疑的定时任务：

bash复制crontab -l
cat /etc/cron.d/* 2>/dev/null | head

有些供应链投毒会注册一个定时任务，让恶意代码即使被清理也会在下一次定时触发时重新装回来。这个位置非常容易漏掉。

6.3 Docker 只更新镜像，是不是就安全

不一定。Docker 镜像本身降低了“本机 Python 环境被污染”的概率，但如果你不是直接拉官方发布镜像，而是用内部 CI 构建镜像，一旦构建机被投毒，镜像里可能已经带了恶意文件。还有另一种风险是，容器启动时会挂载宿主机上的配置文件和 .env，如果宿主机上的这些文件早就被改动过，那即使镜像再干净，运行时依然会加载恶意配置。因此 Docker 部署也要遵循同样的检查流程：镜像来源要可信，挂载的配置要纳入版本管理，启动命令要做成只读，避免运行时被手动修改。

6.4 所有 Key 都轮换过了，能不能恢复服务

技术上可以，但要注意几个前提。数据库里残留的影子 Key 必须清理干净，路由配置必须恢复到可信基线，进程环境变量里不能还有旧 Key 的缓存。最稳妥的做法是：用干净配置重新初始化数据库，再恢复业务所需的模型路由和用户数据，而不是在旧数据库上简单删除几行记录。

我在实际处置中更倾向于“推倒重来”而不是“原地修复”。原地修复的问题在于你永远不知道恶意代码还埋了什么后门。只要上游 Key 已吊销、数据库已重建、配置已回到 Git 基线，恢复服务后的安全感会高很多。

6.5 如何确认后门已经清理干净

没有绝对意义上的干净，但可以从几个信号判断风险已经大幅下降。第一，进程列表中不再有指向可疑域名的外联。第二，数据库里不再出现新的未知 Key。第三，代理配置与 Git 仓库中的基线完全一致。第四，模型供应商控制台里看不到未知的调用记录。建议在恢复服务后的头一周保持高敏感度，每天检查一次虚拟 Key 列表和 spend 报表。

6.6 常见问题速查表

我个人在实际排查中最深的体会是：投毒类攻击最怕的不是技术不够，而是“不知道正常长什么样”。如果你平时没有为网关维护一个干净基线，就算攻击者已经把路由改到面目全非，你也很难一眼看出来。把配置纳入 Git、把依赖做成锁文件、把关键行为加上告警，这三件事看起来不起眼，但在真正出问题时，它们是帮你快速定位最直接的工具。

最后再分享一个小技巧：我每次上线 LiteLLM 新版本前，都会在一个完全隔离的容器里先跑一遍“干净安装 + 功能自测 + 哈希记录”，再把这套结果存成一个只读文件。生产环境出任何问题，我都可以拿这个文件作为参照物。这个过程大概每次多花 10 分钟，但已经帮我避过好几次“版本号没错、文件却不对”的坑。希望这次事件也能给你提个醒：网关越方便，越要把它看紧一点。