AI 圈炸锅！模型调用总闸门被投毒：SSH 密钥、云凭证、钱包私钥全被盯上了。。。

LiteLLM 是一个开源的 LLM 统一调用层，本质上相当于“模型适配器 + 网关”，开发者可以用一套统一接口调用不同厂商的大模型服务，去调用 OpenAI、Anthropic、Vertex AI、Bedrock、Azure 等多家模型服务，而不用分别适配每家的 SDK 和 API 格式；它既可以作为 Python SDK 直接嵌进项目里，也可以作为代理网关统一做鉴权、路由、负载均衡、fallback、缓存、预算和用量追踪，因此在很多 AI 应用、Agent 框架和企业内部平台里都处在比较关键的位置。

2026 年 3 月 25 日，LiteLLM 发生了一起典型的供应链攻击事件。

攻击者将带有恶意代码的 1.82.7 和 1.82.8 版本上传到 PyPI，其中 1.82.8 风险最高。

安装后即便不手动 import litellm，恶意代码也会随着 Python 解释器启动自动执行。

LiteLLM 官方后续确认，问题来自维护者 PyPI 账号被劫持，这两个版本并非通过官方 GitHub CI/CD 流程发布，而是被直接投毒上传。

这次事件之所以引发 AI 开发圈高度紧张，不只是因为 LiteLLM 本身下载量大，更因为它处在模型调用链条的关键位置。很多 AI 应用、代理框架和中间层都会把它作为统一接口来调用 OpenAI、Anthropic、Google 等模型服务，这意味着它天然能够接触大量 API Key、环境变量、云凭证和部署配置。

一旦这个位置被攻破，受影响的就不只是单个开发者，而可能是本地开发机、CI/CD 流水线、Docker 容器，甚至生产环境。

从公开技术分析看，恶意版本主要通过一个名为litellm_init.pth的文件实现自动执行。

用于从受感染设备中窃取凭证的信息窃取恶意代码：

GitHub 上的安全分析显示，这段代码经过 base64 混淆后，会在系统中搜集环境变量、SSH 密钥、Git 凭证、AWS/GCP/Azure 凭证、Kubernetes 配置、Docker 配置、数据库密码、Shell 历史记录等敏感信息，再加密打包，发送到攻击者控制的域名 models.litellm.cloud。

更麻烦的是，安全研究者还发现它具备继续落地后续载荷和维持驻留的能力，不只是“偷一把钥匙”那么简单。

目前官方给出的结论是，受影响的明确版本为 1.82.7 和 1.82.8，其中 1.82.8 的触发条件最宽，危害也最大。

LiteLLM 团队表示，恶意版本已经被删除，维护者账号也已完成轮换，并已请 Google Mandiant 介入协助调查。

官方还称，使用其 Proxy Docker 镜像的用户暂时不在本次直接影响范围内，因为镜像依赖是固定版本。

更值得注意的是，影响已经外溢到下游项目。

Google ADK 的公开 issue 提到，google-adk[extensions] 这类未设上限约束的依赖，在特定时间窗口内有可能拉到被投毒的 LiteLLM 版本；Browser Use 也在 X 上发出安全提示，承认有一个开源版本被这次事件波及，不过同时强调影响范围有限。也就是说，这次事故不是 LiteLLM 单点问题，而是一次顺着依赖链向外扩散的安全事件。

AI 基础设施里那些“看起来只是适配层、代理层、网关层”的组件，往往正是权限最集中、秘密最多的地方。一旦供应链失守，攻击者拿到的不是某个单独服务的访问权，而可能是一整套研发、云资源和生产环境的入口。

对已经安装过相关版本的团队来说，删除包本身远远不够，真正的补救动作是排查litellm_init.pth是否落地、审计异常访问记录，并轮换所有可能暴露过的密钥和凭证。

官方目前也明确建议，凡是安装过 1.82.7 及以上可疑版本的系统，都应按凭证泄露来处置。

软件圈噩梦：LiteLLM 遭遇 PyPI 供应链攻击。

只要执行一条简单的 pip install litellm，就足以让攻击者窃取 SSH 密钥、AWS/GCP/Azure 凭证、Kubernetes 配置、Git 凭证、环境变量里的所有 API Key、Shell 历史记录、加密钱包、SSL 私钥、CI/CD 密钥以及数据库密码。

LiteLLM 自身每月下载量高达 9700 万次，这已经非常糟糕；但更可怕的是，这次攻击还会沿着依赖链继续扩散到所有依赖 LiteLLM 的项目。比如，只要执行过 pip install dspy，由于它依赖 litellm>=1.64.0，同样会中招。其他任何依赖 LiteLLM 的大型项目也一样。

据目前判断，这个被投毒的版本在网上存在的时间不到约 1 小时。但攻击之所以这么快被发现，是因为攻击代码本身有 Bug。Callum McMahon 当时在 Cursor 里使用一个 MCP 插件，这个插件通过传递依赖拉入了 LiteLLM。结果在安装 litellm 1.82.8 时，机器内存被迅速耗尽并直接崩溃。也就是说，如果这名攻击者写这次攻击代码时没出错，这件事很可能几天甚至几周都不会被发现。

像这种供应链攻击，几乎就是现代软件世界里最可怕的事情之一。每次安装依赖，都有可能在庞大而复杂的依赖树深处，悄悄拉进一个被投毒的包。对于依赖数量庞大的大型项目来说，这种风险尤其高。而每一次攻击成功窃取到的凭证，又可能被继续拿去控制更多账户、污染更多软件包，形成连锁扩散。

传统软件工程长期告诉开发者，依赖是好东西，软件系统就像用砖块一层层搭起来的金字塔。但在今天，这个前提恐怕需要重新审视。这也是越来越不愿意依赖外部包的原因之一：只要功能足够简单、条件允许，宁愿直接借助 LLM “顺手拿来”实现，而不是再多引入一个潜在风险点。

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。