ChipHub
Agent 与接口 2026年3月25日

LiteLLM 被投毒，不只是一个包出事，而是整条 AI 开发链条一起暴露

LiteLLM 在 PyPI 上出现被投毒版本，恶意 `.pth` 文件会在 Python 启动时自动执行，目标不是单纯搞破坏，而是直接打开发者机器、云凭证和 Kubernetes 集群。这件事真正危险的地方，是 AI 开发工具链里“一个常用依赖”已经足够成为基础设施级入口。

#AI #Python #Supply Chain Security #LiteLLM #PyPI

来源参考： FutureSearch

AI 开发圈这两年最危险的幻觉之一，就是大家默认“依赖包更新”还是一件偏工程、偏琐碎的小事。这次 LiteLLM 在 PyPI 上的投毒，把这个幻觉狠狠干碎了。

LiteLLM 项目页面预览图

它不是那种只会弹个计算器、证明自己能执行代码的低级恶作剧，而是一个非常现实的入侵入口：一旦装进环境，恶意代码会在每次 Python 启动时自动执行，先搜刮密钥和配置，再往外传，最后如果机器碰巧连着 Kubernetes 集群，还会继续横向移动。对今天这批靠 Python、MCP、云服务和容器堆起来的 AI 工具链来说，这已经不是“某个包有问题”，而是整条开发链条都可能被顺着摸进去。

先说核心事实。FutureSearch 报告称，litellm 在 2026 年 3 月 24 日发布到 PyPI 的 1.82.8 版本带有恶意 .pth 文件 litellm_init.pth。这种文件的麻烦之处在于，它会在 Python 解释器启动时自动触发，不需要你显式 import 某段恶意模块。按照披露内容，受影响的版本后来还扩大到了 1.82.7。更糟的是，这个发布没有对应的 GitHub tag 或正式 release 轨迹，看起来像是绕开了正常发布流程，直接把包推到了 PyPI。

这次事件之所以被注意到，也很有当代 AI 开发的味道：FutureSearch 不是手工排查依赖树时发现的，而是在一个运行于 Cursor 内的 MCP 插件里，被 LiteLLM 作为传递依赖拉进来后触发。披露者提到，这个恶意 .pth 在启动子进程时还会重复触发自己，意外造成类似 fork bomb 的效果，最后先把机器打崩。某种意义上，这甚至不是“防守赢了”，而是攻击代码自己先写炸了。

如果只把它理解成“Python 包投毒”，反而低估了严重性。按照披露，恶意载荷分三步走。第一步是收集：SSH 私钥、.env、AWS/GCP/Azure 凭证、Kubernetes 配置、数据库密码、shell history、钱包文件，能扫的都扫，连云环境的 metadata endpoint 也会探。第二步是外传：数据会被打包加密后 POST 到 models.litellm.cloud。第三步才是真正让人后背发凉的地方：如果机器上存在 Kubernetes service account token，它会尝试读取全命名空间 secret，并在每个节点上起一个高权限 pod，把宿主机文件系统挂进去，再落持久化后门。

这说明攻击者理解的不是某个单点漏洞，而是今天 AI 工程团队的真实工作流。开发者本机里有 SSH key，有 .env，有云账号；CI/CD 环境里有缓存和临时凭证；插件和 agent 系统喜欢动态装依赖；而一旦连上 Kubernetes，攻击面就从一台开发机瞬间扩成整个集群。AI 开发越强调“快速接模型、快速接工具、快速接插件”，供应链污染的杠杆就越大。

我觉得这件事最值得警惕的，不是 LiteLLM 这个名字本身，而是它恰好卡在一个非常关键的位置。LiteLLM 已经被很多 AI 应用、代理框架和开发工具当成统一模型接口层。也就是说，它不像某些冷门依赖那样装机量有限，它更像一层“开发者默认信任的胶水”。而胶水层一旦被拿下，攻击者摸到的就不只是单个应用，而是上游模型调用、下游插件执行、本地凭证管理、容器环境和团队基础设施之间的连接点。这个位置，天然就适合做高收益供应链攻击。

这里还有一个很现实的问题：很多团队对依赖安全的理解，仍然停留在“锁版本”“扫 CVE”“看 GitHub 有没有红字告警”。但这类事件提醒你，真正危险的部分常常发生在更靠近发布链路的地方，比如包仓库账号被接管、CI 发布令牌泄露、发布流程和源码仓库脱钩，或者团队根本没有对“PyPI 上的产物是否对应 Git tag”做任何验证。如果你运行的是 agent、插件、MCP、代码助手这类会主动拉依赖、主动执行工具的系统，传统软件团队那套松散的依赖信任模型已经不够了。

LiteLLM 安全事件后续处置讨论页预览图

当然，现在也还存在不确定性。披露信息来自安全研究方和后续社区跟进，相关 GitHub issue 一度出现关闭和刷屏干扰，说明事件早期的信息环境本身就很混乱。后续更新提到受污染版本已经被 PyPI 下架，维护者也开始处理善后。但对于已经安装或缓存过 1.82.7 / 1.82.8 的环境，这不意味着风险自动消失。缓存轮子、CI 镜像、虚拟环境快照、开发者本地机器，任何一个角落都可能还留着痕迹。

所以这件事最后落回到一个很朴素的判断：别再把 AI 工具链当成“普通应用多接了几个模型 API”了。 当你的系统能接包管理器、代码助手、MCP 插件、云凭证和集群权限时，它本身就是一套高价值基础设施。高价值基础设施，就会遭遇高价值攻击。

以后再看到“只是更新了一个常用依赖”，最好先别急着回车。很多时候，真正被更新的不是一个包，而是攻击者进入你系统的入口。

参考链接