最近AI圈有个瓜传得挺快litellm 竟然被投毒了。很多朋友第一反应是“赶紧查查自己机器中招没有”但真到了命令行面前大部分人其实是懵的——不知道看哪个目录、不知道跑哪条命令、更不知道哪些现象是实锤哪些只是自己吓自己。litellm 是很多AI应用都在用的开源组件说白了就是个“大模型网关”本地统一对接 OpenAI、Claude、Gemini 甚至自建模型不少公司和个人的批量调用脚本、Agent 框架底层都有它。这种基础组件一旦出问题影响面是链式的所以这个瓜确实值得认真对待。这篇博文我就把这个瓜掰开揉碎讲清楚先解释投毒到底是怎么回事再给你一套可以直接照做的自查流程然后是确认中招后的应急响应方案最后聊聊以后怎么避免再踩坑。不管你是自己 pip install 过 litellm还是公司生产环境里间接依赖了它这篇文章都能帮到你。1. 先别急着吃瓜先搞清这次litellm投毒是怎么回事1.1 litellm是什么为什么攻击者会盯上它litellm 是一个开源的大模型调用中间层核心价值是“统一接口”。正常情况下你写代码调用三家大模型可能要维护三套 SDK、三种鉴权方式、三种超时重试逻辑。接入 litellm 之后它帮你把不同的模型供应商全部抽象成一套 API 格式你只需要传一个model参数它自动路由到对应后端。很多人还会用它的 proxy 模式起一个本地网关服务让团队所有成员都走同一个入口。正因为这个定位litellm 一旦被植入恶意代码波及范围会非常大。它可以轻松看到所有经过网关的请求、读入环境变量里的 API Key、访问模型返回的内容甚至在某些配置下改写请求。对攻击者来说这就是一个天然的数据收集器和凭据入口。而且这类开源组件安装量高、依赖关系复杂很多开发者出于“大家都这么装我也这么装”的惯性根本不会逐行审代码这就给了投毒可乘之机。1.2 投毒不等于“中了病毒”供应链投毒有几种常见套路很多人一听“投毒”第一反应是传统病毒、木马。但在开源生态里投毒更多时候是一种供应链攻击手段常见套路大致有这么几类依赖混淆攻击者把恶意包发布到公共仓库起名和某个私有包一样。你本地如果配了公共源pip 安装时优先从公共源下载到了恶意包就会中招。毒化新版本在用户量很大的包上通过社工或漏洞拿到维护者权限然后发布一个包含恶意代码的“新版”。用户一升级就中招而且因为包本身的信任度高很少人会怀疑。抢注相似包名litellm_utils、python-litellm、litellm-core 这种变体看起来像是官方扩展实际上可能是恶意代码。构建链污染不直接改主包而是污染它依赖的某个更底层的小包间接影响所有上层用户。这次 litellm 的瓜具体属于哪一种以官方公告和包平台的检测结果为准。但作为使用者你不能等“石锤公告”出来才行动因为恶意代码可能在公告之前就已经被执行了。1.3 为什么pip安装的包能轻易“执行恶意代码”这里补一个基础知识点Python 的包安装过程是可以执行任意代码的。你执行pip install一个包时pip 不仅会下载包文件还可能运行setup.py、setup.cfg里的逻辑甚至新版本 pip 会处理包里的钩子脚本。也就是说你还没import那个包恶意代码就已经在安装阶段跑起来了。所以“投毒”不一定发生在你运行程序的时候很可能发生在安装的那一瞬间。这也是为什么很多安全建议都强调“不要盲装包装之前要看清楚包名和发布者”。另外conda、poetry、uv 等工具也有类似机制只是细节不同。2. 快速自查你的机器到底中招了没有既然瓜已经传出来了与其焦虑不如动手查。下面这套自查流程是我从多名安全工程师的处理思路里整理出来的按顺序执行基本能把常见问题覆盖到。2.1 第一件事确认你装的litellm版本和来源先在你本机和服务器上分别执行pip show litellm输出里会看到Version、Location、Home-page这些字段。你需要立刻做两件事第一把这个版本号和官方 GitHub Releases 页面里的最新版本核对一下第二确认安装路径是否在你自己创建的虚拟环境里而不是跑到了系统 Python 目录下。如果版本异常新、或者版本号和你记忆中的完全对不上先别急着卸载。把输出完整复制保存到本地文件里当作证据。然后看看安装时间用pip list --formatfreeze把当前 Python 环境里的所有包导出来存个快照。这些动作都是为了后面分析用。2.2 检查可疑依赖、进程、网络连接和定时任务如果 litellm 确实可疑它很可能还会拉进来一些你没见过的依赖包或者释放一些可执行文件。依次执行下面几条命令# 列出最近安装/修改过的包 pip list --formatcolumns # 查看当前用户和系统级定时任务 crontab -l # 或者查看所有用户的定时任务需要root ls -la /var/spool/cron/ # 检查监听端口和外部网络连接 ss -antp lsof -i -n -P重点看几类异常有没有不认识的包名尤其是 litellm 相关但又不是官方仓库里的名字。有没有正在连接可疑 IP 或域名的进程连接的端口不常见不是 80、443、22。有没有莫名其妙新增的定时任务比如每几分钟执行一次 curl、wget、python 脚本。如果你看到某个 Python 进程的启动参数里带着 litellm 的路径同时又在频繁连接外部地址那就要高度警惕。注意不要在这种状态下继续跑业务可以先记录进程 PID 和连接信息再决定下一步。2.3 检查关键文件与环境变量是否被动了手脚投毒代码经常做的一类事情是“持久化”也就是把自己藏在启动项、Shell 配置或者环境变量里。检查这些地方# 检查用户级shell配置是否被追加了奇怪内容 cat ~/.bashrc cat ~/.profile cat ~/.zshrc # 检查环境变量里是否有可疑的PYTHONSTARTUP、LD_PRELOAD等 env | grep -E LD_PRELOAD|PYTHONSTARTUP|PYTHONPATH # 检查pip配置 pip config list cat ~/.pip/pip.conf cat ~/.config/pip/pip.conf恶意代码为了在终端重启后仍然能运行经常会在.bashrc里追加一段“看起来像是优化”的代码比如设置某个莫名其妙的alias或者在后台启动一个 Python 进程。如果你发现有类似alias pip/usr/bin/python3 /tmp/xxx.py这样的内容基本可以实锤环境被污染了。同时看看你常用的 API Key、云厂商凭据文件是否还在原来的位置最容易被偷的~/.env、~/.aws/credentials、~/.ssh/这些路径有没有被读取或复制过的痕迹。这一步不需要太深入取证重点是先确定有没有明显的“外联偷数据”迹象。2.4 用一张表汇总“中招迹象”为了让你查的时候不遗漏我把常见迹象、检查命令和危险等级整理成一张表迹象检查方法危险等级litellm 版本与官方版本对不上pip show litellm比对 GitHub Releases高安装时间异常突然多出依赖包pip list --formatcolumns查看包数量变化中高存在未知定时任务crontab -l检查 /var/spool/cron高Python 进程发起可疑外连ss -antplsof -i -n -P高Shell 配置被追加代码查看~/.bashrc、~/.zshrc高pip 源被篡改pip config list查看 index-url中凭据文件最近被访问结合文件时间戳和日志中高不要因为只有一两条匹配就判定一定中招也不要有三条匹配还觉得没关系。宁可错杀不可放过。3. 如果确认中招怎么做应急响应自查之后如果真的发现了异常接下来这个阶段很容易犯错有人直接拔网线有人立刻重启有人顺手删文件。这些行为都可能破坏证据甚至让恶意代码有更充分的反应时间。别急按下面的顺序来。3.1 先断网还是先取证千万不要慌正确做法是“先保留现场再断网”。在断网之前先把进程列表、网络连接、监听端口这些“易变数据”保存下来。可以执行ps aux /tmp/process_snapshot.txt ss -antp /tmp/network_snapshot.txt lsof -i -n -P /tmp/network_snapshot.txt history /tmp/history_snapshot.txt把这些快照文件放到一个移动硬盘或者安全的地方。然后才断开网络可以是物理拔网线也可以用防火墙规则临时阻断。这里不建议直接关机因为内存里可能还有关键线索直接断电等于放弃取证。接下来判断影响范围如果是个人开发机隔离这台机器就行如果是公司服务器需要立刻跟安全团队或运维同事同步信息让负责人在产线侧做进一步隔离比如限制这台服务器的外网访问权限、暂停它的 API 网关服务。3.2 轮换密钥是必须的别嫌麻烦投毒代码最常见的目的就是偷凭据所以不管你有没有直接证据证明 API Key 泄露都要轮换。这一步没法省。所有能被 litellm 访问到的第三方大模型 API Key 全部重新生成。云服务商的 AccessKey 如果配置在环境变量或 Spring、Flask 配置里一并轮换。数据库密码、Redis 密码、内部系统账号密码只要那台机器接触过都建议一起改。如果生产环境用的是临时密钥比如 AWS STS 这种确认临时令牌的过期时间并让所有相关服务重新部署。轮换密钥的时候注意一个顺序问题先切断可疑进程和外部连接再轮换否则攻击者可能在你改完第一时间又拿到新密钥。断网之后轮换等确认机器干净了再恢复网络。3.3 清理与恢复重装不一定丢数据但别直接信任“删掉就好”很多人的第一反应是“把 litellm 卸载掉就完事了”。这个思路有问题。投毒代码可能不只藏在 litellm 包里它可能修改了系统库、写了启动脚本、留了后门二进制。你删了一个包其他后手还在。如果你有干净的备份镜像或容器镜像最省心的方案是直接恢复整个环境然后再升级到最新的安全版本。如果没有备份那就把系统上所有可疑文件、临时目录里的可执行文件、新增的定时任务清理干净然后把 litellm 和它的依赖全部卸载最后用官方安装方式重装。重装之后不要立刻跑业务先做一轮安全扫描用杀毒软件和专门的恶意软件扫描工具过一遍。生产服务器如果数据很重要建议找专业的安全团队做一次完整的证据保留和溯源分析这个钱不能省。3.4 应急响应清单可打印版我在处理类似事件的时候习惯列一个清单照着打勾不容易遗漏保存进程、网络、命令历史快照。断开机器网络保留现场。通知相关同事和安全负责人。记录机器型号、IP、最近安装操作的时间线。排查可疑进程、定时任务、配置文件。更换所有可能泄露的 API Key 和密码。使用干净镜像或完整重装系统。重装后的第一时间升级所有依赖包到安全版本。运行安全扫描工具确认无残留后接入网络。复盘事件原因更新依赖安装规范和应急预案。这套流程不会100%还原攻击路径但能帮你把损失控制住并且避免二次扩散。4. 从litellm投毒事件看AI工具链的供应链安全4.1 为什么现在越来越容易遇到“装个包就中招”这不是错觉。AI 应用的开发节奏非常快很多项目从零到上线可能只用一两周。快速迭代的代价就是依赖管理粗糙谁也不会把 requirements.txt 里的每个包都认真审查一遍。你随手pip install一个第三方库它可能又依赖了十几个更小的包这些包又依赖了更多。依赖树越深被投毒的概率越高。更麻烦的是Python 生态里的自动化执行机制让“投毒”的门槛很低。攻击者只要能把代码塞进一个包的安装流程里让它在目标机器上自动运行不需要精心构造二进制木马就能实现大部分恶意意图。这就像你家大门钥匙备份在一本大家都知道的杂志里你以为门锁很安全其实入口早就敞开了。4.2 API密钥与模型权重AI场景下被偷的东西更值钱传统供应链攻击偷的是账号密码、数据库数据、用户敏感信息。AI 工具链里还有几类更值钱的东西API Key直接决定攻击者能不能免费蹭你的大模型额度甚至通过你的账号调用模型做黑灰产。提示词和用户输入如果 litellm 被用来做统一网关所有用户的对话内容都会流经这个组件一旦被恶意代码截取等于整个业务对话数据裸奔。模型权重和微调数据很多公司把微调过的模型权重放在服务器本地攻击者拿到后可以倒卖也可以做进一步对抗攻击。函数调用和工具链信息Agent 类应用会调用外部工具恶意代码能记录这些调用逻辑从而了解你的内部系统架构。所以在 AI 场景里投毒不只是“电脑中病毒”这么简单它可能直接导致商业数据和模型资产流失。这也是为什么 litellm 这类组件一出问题大家反应这么大。4.3 开源项目维护者面临的现实压力另一个容易被忽略的点是开源项目的维护者往往是“一个人或几个人在战斗”。litellm 的维护者要面对海量 issue、PR、安全报告还要保持快速迭代。这种压力下账号被盗、误合并恶意 PR、发布错包的概率都会上升。我们作为用户不能一边享受开源红利一边完全甩锅给维护者。更合理的姿态是对开源项目保持信任但也要有基础的验证意识。你至少应该在安装一个包之后花五秒钟看一下它最近一个版本是什么时候发布的、作者是谁、下载量是否正常。4.4 后续扩展SBOM和软件签名这次事件之后如果你在团队里有一定话语权可以推动引入两个东西SBOM软件物料清单简单说就是把你项目依赖的所有组件、版本、来源列成一张清单。出问题时能快速定位“我们到底用了哪些版本”。软件包签名验证PyPI 和一些包管理器正在逐步支持签名或摘要校验。安装时用哈希比对能发现包内容是否被篡改。这些措施不能说100%防投毒但绝对能把排查范围从“全公司所有服务器”缩小到“某一个具体版本”。5. 以后怎么不踩坑给开发者和团队的依赖管理建议瓜吃完了该收心整理环境了。以下是经过多次折腾之后我自己保存下来的依赖管理习惯分享给你。5.1 装任何包之前先做“三查”查官网和文档确认这个包是官方维护还是个人野鸡项目。查 PyPI 页面看项目主页链接、作者信息、最近更新时间、下载量、有没有仓库地址。查 GitHub Issues/Commits看看维护者活跃度最近有没有可疑的 release。不光是 litellm任何包都适用。我见过有人在 requirements.txt 里拼错一个大模型 SDK 的名字拼错的那个包恰好就是恶意包结果一部署到测试环境就开始对外发包。三查这个动作花不了两分钟但能挡住大部分坑。5.2 用虚拟环境加锁文件锁定版本和哈希pip freeze requirements.txt这种方式只锁了版本号没锁哈希。投毒事件里最常见的一种场景是同一个版本号但包内容被恶意替换了。所以更稳妥的做法是使用带哈希锁定的工具。用pip-tools编译出requirements.txt里面会带上--hash。用uv或poetry管理项目锁定文件的粒度更细致。部署时优先从公司内部私有镜像拉包不要在公网环境每台机器单独安装。锁定哈希之后即使下游仓库同一版本被替换安装时也会因为哈希不一致而失败这就从机制上挡住了投毒包。5.3 用安全扫描工具做常规体检建议把安全扫描加入你的发布流程而不是等出事再查。几个常用工具先熟悉一下# 检查Python依赖中的已知漏洞 pip-audit # 检查当前项目中的敏感信息比如硬编码密钥 trufflehog git --resultsverified # 扫描容器镜像 trivy image your-image:tag这些工具不能保证发现所有恶意代码但能覆盖已知漏洞库和大部分敏感信息泄漏场景。每周跑一次比每次出事之后做应急响应划算得多。5.4 最小权限和密钥管理很多投毒代码之所以“一偷一个准”是因为服务器上的服务都用 root 跑API Key 全写在.env文件里环境变量一眼可见。以后建议不要用 root 运行 litellm 之类的网关服务单独建一个低权限用户。API Key 交给专门的密钥管理服务比如云厂商的 Secret Manager而不是直接塞在环境变量里。容器化部署时镜像里不要带任何真实凭据全部通过运行时挂载或 secret 注入。服务之间调用尽量用短期凭证不用长期有效的静态密钥。密钥生命周期短就算泄露攻击者拿到的也是一把很快过期的钥匙影响面会小很多。5.5 引入外部组件前先做一次内部评估团队里有人提议新引入一个开源组件时可以过一遍这个评估表评估项通过标准是否有明确的维护者和公司/社区背书是最近版本更新时间一年内有更新Issue响应速度1-2周内有维护者回复依赖树深度依赖数量少且均为知名包License合规允许商用无传染性风险是否经过安全扫描关键路径上无高危漏洞这个评估不用做成特别重的流程但至少要有人看一眼。很多投毒事件里恶意包往往都是“突然出现”的“完美替代品”下载量低得可疑维护者信息也含糊不清这种包直接进生产环境是典型的风险行为。6. 常见问题与避坑技巧最后整理几个大家自查时容易被卡住的问题都是我见过的真实场景。6.1 为什么pip show查不到litellm如果你执行pip show litellm输出WARNING: Package(s) not found不要直接认为“没中招”。先确认你的 Python 环境是不是当前激活的那个。很多人在系统 Python 和虚拟环境之间切换查错了环境。which pip which python pip -V如果当前激活的是 conda 环境包可能装在 base 环境或其他 env 里得切过去查。还有一种情况是项目用 poetry 管理它会把包装在虚拟的.venv下面这时要用poetry show litellm查看。6.2 我的镜像源检查没问题是不是就安全了不一定。很多人只检查了 pip 的 index-url认为官方源就安全。但镜像源本身也可能存在同步延迟或者被中间人篡改如果企业内网镜像没有做 TLS 校验的话。更稳妥的方式是既检查 index-url也检查安装包时 pip 输出的哈希是否与官方一致。另外如果公司内网镜像由第三方维护你需要确认维护方有安全审计和同步机制。大型机构出过不少“内网镜像被污染”的案例镜像源可信度并不是天然100%。6.3 发现异常网络连接但不一定是投毒litellm 作为一个网关本身就会和很多模型服务端通信。你在ss -antp里看到大量到api.openai.com、api.anthropic.com的连接那是正常现象不是恶意外联。真正的异常是那些到可疑 IP、动态域名、非标准端口的连接。判断方法很简单手动查一下目标地址的归属地和域名类型。如果一个 IP 看起来像云主机但又不在国内外主流大厂厂商的 IP 段里而且你的业务根本不会访问那个地址那就要重点排查对应进程。6.4 误删依赖导致服务挂了怎么办自查过程中发现可疑包手一抖就pip uninstall结果依赖它的服务全挂了。这种情况我见过太多次。正确做法是先确认这个包被哪些包依赖pip show 可疑包名 pipdeptree -p 可疑包名pipdeptree能看到依赖关系。如果它被其他核心包依赖你不能简单卸载而应该先把它替换成安全版本或者回滚整个环境到之前的干净快照。这也是为什么我前面强调“先备份再动手”。6.5 要不要向官方报告如果你确认在自己的环境里发现了恶意代码建议第一时间向官方渠道报告。PyPI 有专门的安全报告入口GitHub 仓库也可以提 Security Advisory。报告时附上包名、版本、安装时间、异常行为描述、进程快照等信息。把这次事件当成一次演练更新自己的依赖管理规范。不要只停留在“这次没中招虚惊一场”的层面下一次投毒可能比这一次更隐蔽。我个人在实际操作中的体会是投毒这种事查出来是运气查不出来才是常态。越早把依赖管理做规范后面吃瓜的时候就越踏实。最后再分享一个小习惯每次pip install之前我都会先pip index versions 包名看一眼列出来的版本号装完之后立刻跑一次pip-audit。这个习惯救过我很多次希望你也能用上。