群青色黑洞今天早上一睁眼，手机里全是同一件事：litellm 被投毒了。群里转截图、转链接、转“谁跑 litellm proxy 的快查一下”，说实话这种场面我不太意外。过去几年 PyPI 上出现过多轮仿冒包和恶意组件，可当“被投毒”三个字落到自己天天在用的包上，第一反应一定是：我的服务器会不会已经中招了？
如果你也在这台机器、公司跳板机，或者哪怕本地电脑上执行过 pip install litellm，并且把它当成团队内部的模型网关在用，那这篇就是给你写的。我不会把网上流传的截图和哈希列表翻来覆去复读，我更想做的是把一套能在 30 分钟内跑完的自查流程完整拆给你看：litellm 到底是什么、恶意组件一般会藏在哪里、怎么确认自己的机器有没有被种下后门、万一中招了先处理哪件事、以及以后跑 litellm proxy 时可以参考的长期安全习惯。看完你至少能回答一个关键问题：我到底该不该慌。
1. 先别慌，搞清楚“litellm 投毒”背后到底是怎么回事
1.1 litellm 为什么会被盯上
litellm 从来不是冷门小工具。它本质上做的事情很像一个“模型总闸”：统一封装 OpenAI、Anthropic、Gemini、各类国产模型和自建模型接口，然后把 API Key、路由策略、负载均衡、失败重试全部集中到一层。很多团队用它跑 litellm proxy，对外只暴露一个 OpenAI 兼容端口，对内把各家模型的 Key 统一托管。
如果这一层被污染，后果不是“某个 Python 包不好用了”那么简单。恶意代码一旦进入 litellm 进程，第一眼就能看到环境变量里的各种 Key，然后它还可以继续改写请求路由、替攻击者发起模型调用。说得直白一点，这是整串钥匙挂在同一个钥匙环上的场景，投毒者只要打开钥匙环，后续所有门都能试一遍。
这也是为什么每当“某某包被投毒”的消息出来，运维和 AI 工程团队会格外紧张。litellm 的用户量太大，部署位置又太关键，攻击者盯上它完全符合成本收益逻辑。
1.2 这类投毒通常怎么传播
供应链投毒的常见套路其实很固定，常见的有三类。
第一种是仿冒包和抢注包。攻击者在 PyPI 上传名字与 litellm 极其接近的恶意包，比如多了个字母、加个横杠、后缀加上 -dev 或 -client。有人手滑复制错包名，或者某些历史遗留的自动化脚本依赖了错误包名，就会中招。这种情况在开源生态里反复出现。
第二种是依赖混淆攻击。如果你在内网维护了一个私有包，名字叫 my-company-llm-utils，但部署机器上同时配置了官方 PyPI 和私有源，而私有源里又找不到这个包，pip 就会去官方源找同名包。攻击者事先把同名包推到 PyPI，你的构建过程就会把恶意版本当“补位”装进去。
第三种是安装脚本和部署教程被篡改。很多人搜 litellm 使用教程时，会看到博主贴出“一键安装”命令，可能是 curl | sh，也可能是直接执行一段 Python。一旦这些内容来自不可信来源，里面完全可能夹带下载恶意文件的逻辑。
你可以把投毒理解为：常规下载渠道本身没问题，但总有人试图在“你拿到代码之前”和“代码跑起来之后”这两个节点之间做手脚。好消息是，这类攻击并非完全无迹可寻。
1.3 哪些机器最需要提高警惕
我给自己和朋友的排查优先级大致如下：跑着 litellm proxy 的生产服务器排第一，然后是开发机、跳板机、CI 执行机，最后才是个人电脑。
具体来说，这几类情况风险更高：
- 用 root 用户在宿主机上直接执行
pip install，并且之后用 root 启动 litellm； - 通过第三方博客、论坛或微信群里的命令安装过 litellm；
- 服务器上配了多个
--index-url或--extra-index-url，存在依赖混淆可能； - litellm 进程所在目录就是全局 Python site-packages，而且这台机器还被用于跑其他业务；
- 很久没升级 litellm，完全不知道当前版本和官方最新版本的差异。
当然，风险高不代本一定有问题。下面这套自查流程，建议按顺序跑一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三步自查：你的机器上是否有一个“可疑的 litellm”
2.1 第一步：核实“装进来的到底是什么”
很多人口中的“我装了 litellm”，其实并不清楚装的是哪一个发行版、从哪个源装的、文件落在哪里。先做一次最基础的信息收集：
bash复制python -m pip show litellm
python -m pip show -f litellm
第一条命令会显示版本、安装位置和依赖。第二条命令会列出这个包安装时带入的所有文件。看到输出后，重点看两个信息：安装来源里的 URL 是不是 pypi.org 或公司私有源；文件列表里有没有明显不对劲的 .py 或 .pth 文件。
接着找出 litellm 的实际入口文件：
bash复制python - <<'PY'
import importlib.util, os
spec = importlib.util.find_spec("litellm")
if spec:
print("入口:", spec.origin)
mtime = os.path.getmtime(spec.origin)
print("修改时间:", mtime)
PY
然后手工看看 site-packages 目录里最近被写入的文件。site-packages 的路径可以用下面命令拿：
bash复制python -c "import site; print(site.getsitepackages())"
拿到路径后，直接 cd 进去，执行：
bash复制ls -lt | head -20
如果 litellm 是你几周前装的，但它的相关文件修改时间却非常接近当前时间，那就值得怀疑了。这里有个前提：Python 包在安装时可能生成 .pyc 缓存文件，mtime 不一定代表源码被改。但 litellm 主目录里如果出现 __init__.py、version.py 或者某个 utils 模块的时间异常，最好继续往下查。
还可以检查 pip 的源配置有没有被人动过手脚：
bash复制pip config list
pip config debug
env | grep -i PIP
如果发现 pip 指向某个不认识的三方 index，或者环境变量里多了奇怪的 PIP_INDEX_URL，这就是非常典型的投毒入口。
2.2 第二步：看运行中的进程和网络连接
恶意代码装进机器之后，常见的动作是回连 C2 服务器，把偷到的环境变量、配置文件往外传。如果你正在运行 litellm proxy，先观察一下它的“生活状态”：
bash复制ps aux | grep -E 'litellm|uvicorn|gunicorn' | grep -v grep
正常 litellm 进程会有一个明确的父进程，可能是 systemd、docker、或者你手动执行的 shell。如果看到进程数量异常，比如同一个环境下出现多个 python 进程，或者某个进程的命令行里带着你从不认识的参数，先记下来。
网络连接检查在开始之前简要说明下：直接用 ss 查对外连接即可，比如：
bash复制ss -tnp 2>/dev/null | grep python
lsof -i -P -n 2>/dev/null | grep python
重点看两类连接：与 LLM 厂商域名无关的公网地址；以及大量短连接。lsof 可能没安装，没有也不影响，用 ss 就已经能覆盖绝大多数场景。
很多人会忽略一个细节：恶意代码不一定会保持长连接。它可能在安装后几十秒内完成数据外传，然后退出，根本不会一直挂在进程列表里。所以单纯看“当前有没有可疑连接”并不能说明历史没问题。真正可靠的判断还要配合日志和文件痕迹。
如果你把 litellm 跑在 Docker 里，查看容器网络连接的方式略有不同：
bash复制docker ps --no-trunc
docker logs --tail 200 <容器名>
docker top <容器名>
容器内的外连只要在 host 上用 nsenter 或 tcpdump 才能看得更清楚。所以我给多数朋友的建议是：这一步没发现异常，只能说明当前没有明显的“现场操作”，不能直接下发“安全”结论。
2.3 第三步：钻到 Python 启动链路和计划任务里找后门
最常见的隐蔽手法不是改 litellm 源码，而是往 Python 的启动链条里注入逻辑。因为 litellm 是 Python 写的，攻击者只要确保代码在 Python 启动时执行，就能“先于业务代码”拿到控制权。
重点排查这几个位置：sitecustomize.py、usercustomize.py、.pth 文件、site-packages 里的可疑 __pycache__。
先看当前 Python 环境启用了哪些站点目录：
bash复制python - <<'PY'
import site
print("全局:", site.getsitepackages())
print("用户:", site.getusersitepackages())
PY
然后把位置挨个扫一遍：
bash复制find /usr/lib/python*/site-packages /usr/local/lib/python*/site-packages ~/.local/lib/python* -maxdepth 1 -name 'sitecustomize.py' 2>/dev/null
find /usr/lib/python*/site-packages /usr/local/lib/python*/site-packages ~/.local/lib/python* -maxdepth 1 -name '*.pth' -print 2>/dev/null
如果你不熟悉 .pth 文件，这里多解释一句：.pth 文件是 Python 用来扩展模块搜索路径的，正常内容是一行一个路径。但它也支持某些特殊情况下的代码执行，恶意利用时会写一段极短的 import 语句，让 Python 每次启动自动加载某个模块。这个机制非常隐蔽，因为很多人的安全意识还停留在“看 site-packages 里有没有陌生目录”，完全不会去检查 .pth。
发现可疑 .pth 文件后，先不要急着删，把它内容显示出来：
bash复制cat /usr/local/lib/python*/site-packages/*.pth
如果里面除了路径还出现了 import，这基本可以直接判定有问题。同理，如果 sitecustomize.py 不是你自己写的，内容里又有 base64 解码、requests、socket 一类的逻辑，那大概率是后门文件。
接着检查操作系统的自启动项目：
bash复制crontab -l
ls -la /etc/cron.d/ /etc/cron.daily/
systemctl list-unit-files --type=service | grep -iE 'litellm|python|curl|update'
再看 shell 的登录脚本有没有被加东西：
bash复制tail -50 ~/.bashrc ~/.profile /etc/profile 2>/dev/null
很多投毒程序会顺手把下载执行脚本的语句塞进这些地方。即使你在安装 litellm 后重启过机器，只要 shell 里多了一行 curl ... | sh，它依然会重新激活。
3. 确认中招之后，正确操作顺序比“删除文件”重要
3.1 保持现场，先截断外联
如果你已经比较确定机器被投毒，第一反应通常是“删除恶意文件”，但我建议先忍住。
在应急响应的流程里，保留现场永远比尽快清理更重要。恶意文件还在时，你才能通过日志、进程、网络连接判断它到底做了什么、连到哪里、感染范围有多大。一旦直接删文件关机，后面想查证据就难了。
比较好的操作顺序是：先把 litellm 服务和相关容器停下来，让恶意代码不再继续跑；然后断开这台机器的公网出方向，这时候可以保留下方向端口，方便你用 SSH 继续操作。如果你有安全隔离网段或专供取证用的机器，那就更好了。
如果机器是云服务器，可以先把安全组的出站规则临时改成全部拒绝。这样一来，恶意进程就算还在内存里，也没法继续往外传数据。
保留现场还需要做一件事：把关键信息记录或备份出来。进程列表、环境变量、~/.bash_history、litellm 最近日志、site-packages 文件列表，这些都值得存一份。你可以用下面命令快速打包：
bash复制mkdir -p /tmp/incident
date > /tmp/incident/time.txt
ps auxf > /tmp/incident/ps.txt
env > /tmp/incident/env.txt
cat /proc/net/tcp > /tmp/incident/tcp.txt
ss -tnp > /tmp/incident/ss.txt 2>/dev/null
find ~/.cache/pip -type f -name '*.whl' -o -name '*.tar.gz' 2>/dev/null | head -100 > /tmp/incident/pip-cache.txt
注意，env 输出里很可能包含密钥明文，所以这一步打包出来的内容不要直接丢到聊天工具里，保存到安全的离线位置即可。
3.2 立即轮换所有可能被读取过的密钥
如果说隔离是控制“恶意代码继续行动”，那么密钥轮换就是在控制“已经泄露的凭证继续被滥用”。两者同样紧急，但轮换密钥经常被低估。
litellm proxy 进程读取过的环境变量里，通常包含大量的模型服务商 Key。只要恶意代码运行在同一个进程环境中，它就有机会把这些 Key 全部拿走。所以优先级最高的事，不是清洗磁盘，而是去各家模型服务商的控制台，把所有在这个环境里出现过的 Key 全部吊销重建。
常见的还包括数据库密码、Redis 密码、代理认证信息。只要你确认 litellm 进程能拿到它，就默认它已经泄露。所有相关服务商的后台都该走一遍“撤销并重建”流程。
重建之后，顺手查看一下模型服务商的用量账单。如果攻击者拿到了 Key，通常第一件事是“自己跑模型”，这会产生真实费用。账单里如果出现你不认识的模型名称、异常的地区调用或时间段，基本可以确认 Key 已经被盗用了。此时光换 Key 还不够，还应该到服务商后台设置预算上限，防止再次被盗后产生高额账单。
3.3 清理环境并找到感染入口
确认中招且密钥轮换完成之后，再做清理，这时可以果断一些。
我的建议是把 litellm 所在的环境整个推倒重建，而不是只是 pip uninstall litellm。因为恶意代码可能改动了 Python 的启动链路、留下了 .pth 后门，也可能混在某个依赖树深处。单纯卸载主包，往往清理得不干净。
推荐的做法是：
删除当前的虚拟环境或容器：
bash复制# 如果用了 venv
deactivate
rm -rf /path/to/venv
# 如果用了 Docker
docker compose down
docker rm <容器名>
然后从可信源重新创建环境：
bash复制python -m venv /opt/litellm-env
source /opt/litellm-env/bin/activate
pip install --upgrade pip
安装 litellm 之前，先确认你将要安装的版本号，并尽量锁定一个与官方 release 一致的版本，避免直接装最新版而不看变更说明。安装完成后，把之前备份的配置文件逐项人工检查一遍，尤其注意配置里有没有异常的回调 URL、webhook 地址或自定义 API Base。
清理不等于把恶意包丢掉就完事。建议复盘一下感染入口：查 history 找到当时执行安装命令的人和时间；检查 pip 是用了哪个 index；查一下那台机器是不是被人从公网扫描后安装了后门。很多情况下，litellm 只是受害者，真正的入口是 SSH 弱口令、暴露的管理面板或一次骗过员工的钓鱼安装命令。
4. litellm proxy 最佳实践：从安装到运维的安全基线
4.1 安装环节：不能永远依赖“最新版”
很多人安装 Python 包的习惯是 pip install litellm，升级是 pip install -U litellm。对日常开发没问题，但对生产环境里的 litellm proxy，这就太随意了。
建议在 requirements 或 lock 文件里锁定精确版本，并且只在确认变更内容后再升级：
txt复制litellm==1.59.0
如果你对 hash 校验有要求，pip 支持 --require-hashes。写起来类似：
txt复制litellm==1.59.0 --hash=sha256:xxxxx
不过维护 hash 也会带来一点麻烦：每次升级版本都要重新获取 hash。实际项目里，如果只用官方 PyPI，这个校验是可选项；但如果你的环境用到了多个 index，那我强烈建议开启。不过实际写 requirements 时也可以不手写 hash，而是把生成的 lock 文件纳入版本控制。
还有一个经常被忽略的点：使用 Docker 时，最好锁定镜像的 digest，而不是只写 tag。因为 tag 是可变的，main-stable 今天指向的镜像和明天指向的镜像可能完全不同。正确做法是拉取镜像后记录 digest：
bash复制docker images --digests | grep litellm
然后在 compose 或部署清单里使用带 sha256: 的完整镜像名。这样即使上游仓库被劫持或恶意推送，你的下一次部署也不会自动拿到未知内容。
4.2 运行环境：给 litellm 一个干净的家
所有 Python 组件都应该跑在独立的虚拟环境或容器里，这条原则我强调了无数次，但每次出问题还是有人踩。
不要在全局 Python 环境里直接装 litellm。全局环境里通常还跑着其他业务脚本、定时任务和内部 Web 服务。一旦某个依赖被污染，影响会被无限放大。用 venv 是成本最低的隔离方式：
bash复制python -m venv /opt/litellm-venv
source /opt/litellm-venv/bin/activate
pip install litellm==具体版本
如果团队规模比较大，直接走容器化更合适。litellm 官方提供镜像，部署的时候建议做到：
- 不要用 root 用户启动容器；
- 容器文件系统设为只读，或者只挂载必要的配置目录；
- 不要把宿主机的 Docker socket 挂载进容器；
- 给容器设置
mem_limit和cpu_count，防止被恶意进程耗尽资源。
容器在一定程度上能限制恶意代码的破坏半径，但它不等于安全。恶意代码仍然能读取容器内的环境变量和挂载进去的配置文件。所以密钥管理不要只靠环境变量明文，生产环境建议用密钥管理服务，例如 Vault 或云厂商的 Secret 服务，让 litellm 在启动时动态获取凭证，而不是把 Key 永久写死在 .env 里。
4.3 外联控制：不是所有出网请求都合理
litellm proxy 作为网关，出网路径相对可控。正常运行情况下，它只会访问你配置过的模型服务商接口，比如 OpenAI、Anthropic、Gemini 等域名。如果这台服务器还会向一些奇怪域名发起请求，那就该警惕了。
在生产环境，尤其对安全要求高的团队，建议给 litellm 所在机器配置出网白名单。允许访问的只有少数几个模型 API 域名和必要的可观测性采集端点，其他公网地址一律拒绝。不要觉得这样很麻烦，等真正被投毒时你就会发现，出网白名单是阻止数据外传的最后一道防线。
在开发环境里无法完全限制外网时，退而求其次的做法是打开审计。litellm proxy 本身有详细的请求日志和费用追踪能力，可以记录每个请求的目标模型、调用方标识、Token 消耗。把这些日志接入团队已有的日志系统或 Prometheus 监控，设置异常告警。例如某个 API Key 在凌晨突然开始高频调用大模型，或者访问了一个你根本没有配置过的模型，这些都应该有通知。
4.4 自动化体检与审计
只靠人工排查不够，安全必须靠定期自动化。建议把下面这些检查加入 CI 或服务器定时任务：
bash复制pip install pip-audit
pip-audit
pip-audit 会扫描当前 Python 环境中的依赖，并与已知漏洞库比对。虽然它主要面向的是“已知 CVE”，对刚刚出现的投毒样本不一定能第一时间检出，但它能帮你发现带已知漏洞的老版本依赖。对 litellm 这种更新频繁的包来说，保持依赖干净永远没错。
代码仓库本身也可以接入依赖扫描，比如 Dependabot 或 Renovate。这些工具会在依赖有新版本或有漏洞公告时自动创建 PR，把升级过程变成可审查的流程，而不是某天有人在服务器上随手敲了一句 pip install -U。
除此之外，我建议每次部署后做一次“安装来源快照”：
bash复制pip show litellm | grep -E 'Name|Version|Location'
pip config list
pip check
把这些信息输出到部署日志里。如果将来真的出问题，你能快速看出这台机器上的 litellm 是哪个版本、从哪个源装的、依赖是否健康。很多事故之所以排查耗时，就是因为根本没有留下这些基础记录。
5. 常见问题与排查实录
5.1 现象速查表
如果你觉得自己可能中招，但又说不清具体症状，可以直接对照下面的现象判断方向。
| 现象 | 可能原因 | 处理建议 |
|---|---|---|
| 模型服务商账单出现异常调用 | API Key 被投毒程序回传并盗用 | 立即吊销所有存量 Key，查看调用时间和模型名称，配置预算上限 |
| litellm 进程 CPU 或内存异常飙高 | 恶意代码在挖矿或跑批量请求 | 先断外网，抓进程快照，然后按第 3 节应急流程处理 |
site-packages 中出现陌生 .pth 或 sitecustomize.py |
Python 启动链路被注入 | 不要直接删文件，先看内容并保存证据，再重建环境 |
| pip show 显示的安装源不是官方源 | 安装命令来自三方源或历史遗留脚本 | 核对所有 index 来源，更新为官方源或私有可信源 |
| 服务器会主动连接未知公网 IP | 恶意代码正在外传数据或等待指令 | 拒绝出站流量，用抓包工具记录连接目标，然后隔离机器 |
| litellm 版本很老且长期未升级 | 存在已知漏洞且没有修复能力 | 制定升级计划，先备份配置，再锁版本升级 |
这张表不能覆盖所有情况，但它是我在处理类似事件时最常用的快速分类框架。只要现象对得上，就不用再纠结“这件事到底严重不严重”，直接启动应急响应流程即可。
5.2 我踩过的一些“坑”
第一次遇到类似问题时，我犯过一个经典错误：发现用户目录下有个可疑的 .pth 文件，顺手就删了。结果后来排查发现，攻击者在 .bashrc 里还放了一段下载逻辑，只要某位同事重新登录服务器，恶意代码又会重新写回所有文件。那次教训换来一条经验：清理必须从“入口”开始处理，而不是只清“结果”。删文件之前，一定要先找到还在运行的父进程、登录 shell 和定时任务。
还有一个很容易被忽视的点：很多投毒包的恶意行为是在安装阶段完成的，而不是在你运行 litellm 时才触发。换句话说，也许你根本没有启动过 litellm，但只要执行过那条恶意的 pip install，黑客就已经通过 setup.py 拿到了你机器的部分控制权。这就意味着，你检查“litellm 有没有在跑”是不够的，还要检查“历史 pip 安装记录里有没有可疑包”。
此外，容器场景也不是护身符。有些人觉得自己把 litellm 跑在 Docker 里就很安全，实际上如果容器启动命令把整个宿主机的 .env 目录挂载进去，或者容器本身以特权模式运行，攻击者完全可以凭一个恶意的 Python 包拿到宿主机的控制权。不要迷信任何单一隔离技术，纵深防御才有意义。
在事情尘埃落定之后，我还会做一次“找回现场”的复盘：把模型服务商后台近 7 天的日志全部导出来，逐个检查有没有异常调用；把服务器 bash_history 按时间线整理一遍，看安装命令到底是哪条、谁执行的；把当时安装时生成的 pip 缓存清掉，避免以后再从缓存里装到同一份恶意文件。
写在最后：每次消息爆出来，都是一次重启安全习惯的机会
我不知道你手里的机器最终排查结果是什么，但我个人在实际操作中的体会是：这类投毒事件最可怕的不是某一次中招，而是大家总在事件爆发时临时紧张一下，过两周又回到“直接 pip install 最新版、密钥随便存”的旧习惯里。
我现在每次部署 litellm proxy 都会在最终检查单里多写几条：锁版本、锁容器 digest、检查 pip 源、跑一遍 pip-audit、确认出网白名单、把 .pth 和 sitecustomize 的检查做成脚本。这套动作熟练之后，每次只多花十几分钟。
最后还是想提醒一句：你看到的安装包来源、你运行的容器层级、你暴露出去的端口，每一个点都是潜在的攻击面。别等“喔去，又被投毒了”的消息出来了才想起来查，依赖安全这件事，应该把功夫花在日常。