LiteLLM 被投毒了。Axios 也没逃过。就在今天（4月10日），国家网络安全通报中心正式发文，点名三起供应链投毒事件——开源 AI API 网关 LiteLLM、JavaScript HTTP 库 Axios、以及 API 协作平台 Apifox，集体中招。
这不是某个小众库的小打小闹。LiteLLM 是目前最主流的多模型代理网关之一，大量企业用它统一调用 GPT、Claude、Gemini 等模型的 API；Axios 更不用说，npm 周下载量过亿，几乎是前端和 Node.js 生态的"水和电"。这两个库被投毒，意味着整个 AI 开发生态的地基被人动了手脚。
发生了什么
先说 LiteLLM。3月24日，微步情报局最先监测到异常：PyPI 仓库上的 LiteLLM 1.82.7 和 1.82.8 两个版本被植入了后门代码。攻击者的手法很克制也很老练——恶意代码在 pip install 的常规安装流程中静默触发，不需要用户做任何额外操作。一旦安装，后门会窃取环境中的 API 密钥、云服务凭据等敏感信息，并尝试横向移动到同一网络内的其他机器。
好消息是，PyPI 官方在 46 分钟内就下架了恶意版本。坏消息是，46 分钟对于一个热门包来说已经足够造成大面积感染。LiteLLM 的用户画像很集中——AI 工程师、后端开发者、MLOps 团队——这些人的机器上往往存着各种模型 API Key、云平台 Access Key，甚至数据库凭据。攻击者精准地选择了"高价值目标"。
再说 Axios。攻击路径更狠——黑客直接劫持了 Axios 核心维护者的 npm 账户，发布了 1.14.1 和 0.30.4 两个恶意版本。注意这两个版本号的选择：1.14.1 紧跟在当时的最新稳定版后面，0.30.4 则瞄准了还在用旧版的项目。无论你是激进升级派还是保守钉死版本派，都可能踩坑。
恶意版本植入了跨平台木马，Windows、macOS、Linux 通吃。更值得警惕的是，根据国家网络安全通报中心的分析，OpenClaw 等大量 AI 应用及插件生态直接依赖 Axios，风险通过依赖链层层传递，最终蔓延到终端用户。
一个细节让人后背发凉：有安全研究者拆解后发现，这次 Axios 投毒事件中，攻击者疑似使用了 AI 辅助的社会工程学手段来获取维护者账户权限。用 AI 来攻击 AI 生态，这个套娃属实讽刺。
为什么供应链投毒越来越危险
供应链投毒不是新鲜事。但这一轮集中爆发有几个特征，值得所有开发者认真对待。
第一，攻击目标在"上移"。以前的投毒多瞄准终端用户，现在直接打开发者和运维人员。道理很简单：一个普通用户的电脑上可能有几个密码；一个 AI 工程师的 .env 文件里，可能躺着价值几十万的 API 额度、能访问生产数据库的凭据、以及各种云服务的 Root Key。投毒一个开发者，等于打开了一扇通往整个企业内网的门。
第二，攻击面在"放大"。现代软件开发的依赖关系是一棵巨大的树。你的项目可能只直接依赖了 20 个包，但这 20 个包各自又依赖了几十个包，最终你的 node_modules 里躺着上千个包。任何一个节点被污染，整棵树都不干净。Axios 就是典型——它本身是一个 HTTP 客户端库，但因为太基础、太通用，几乎所有 AI 应用的前后端都会用到它。打掉 Axios，等于在整个生态的供水系统里下了毒。
第三，检测难度在"升级"。这次三起事件中的恶意代码都采用了混淆、自清除和反调试技术。LiteLLM 的后门在执行完窃取操作后会自动清理痕迹；Axios 的木马使用了隐蔽通信机制，流量特征很难被常规安全工具捕获。传统的杀毒软件和防火墙，对这类攻击基本是睁眼瞎。
对 AI 开发者的实际影响
说点实在的。如果你是 AI 开发者，以下几个场景需要立刻自查：
场景一：你用 LiteLLM 做模型网关
LiteLLM 在 AI 开发圈的渗透率很高。它的核心价值是让你用统一的接口调用不同厂商的模型——OpenAI、Anthropic、Google、DeepSeek，一套代码搞定。很多团队用它搭建内部的模型代理服务，甚至直接部署在生产环境。
如果你在 3 月 24 日前后通过 pip install litellm 或 pip install --upgrade litellm 安装过，请立刻检查版本号：
pip show litellm | grep Version
如果版本是 1.82.7 或 1.82.8，你需要：
- 立刻回退到 1.82.6 或更早的稳定版本
- 轮换（rotate）所有存储在该环境中的 API Key 和凭据
- 检查该机器的网络日志，排查是否有异常外连
# 回退到安全版本
pip install litellm==1.82.6
# 检查是否有残留的恶意文件
find $(python -c "import litellm; print(litellm.__path__[0])") -name "*.pyc" -newer /tmp/marker -exec ls -la {} \;
说到模型网关，这里多说一句：自建 LiteLLM 网关本身就有不小的运维成本和安全风险，这次投毒事件更是放大了这个问题。如果你的需求是统一调用多家模型 API，像 OpenAI Hub 这类托管的 API 聚合服务可以省掉自己维护网关的麻烦——一个 Key 调所有主流模型，兼容 OpenAI 格式，国内直连，至少不用担心自己的网关组件被投毒。当然，选择哪种方案取决于你对安全边界和控制粒度的要求。
场景二：你的项目依赖 Axios
检查你的 package.json 和 package-lock.json：
npm ls axios
如果锁定的版本是 1.14.1 或 0.30.4，立刻降级：
npm install axios@1.14.0
更麻烦的是间接依赖。你可能没有直接安装 Axios，但你用的某个 AI SDK 或工具库依赖了它。用以下命令检查完整的依赖树：
npm ls axios --all
场景三：你用 Apifox 做 API 调试
Apifox 的公网 SaaS 版桌面客户端也在本次通报范围内。如果你用 Apifox 调试过带有 API Key 的请求（老实说，谁没有呢），建议同样轮换相关凭据。
更深层的问题
这次事件暴露的不只是三个库的安全问题，而是整个开源供应链信任模型的脆弱性。
我们来想一个问题：你 pip install 一个包的时候，你信任的是什么？是包的名字？是版本号？是 PyPI 这个平台？还是背后那个维护者的账户安全？
答案是，你信任的是一条很长的链条，而这条链条的每一个环节都可能断裂。LiteLLM 的投毒走的是"上游依赖污染"路径，Axios 走的是"账号劫持"路径，Apifox 走的是"发布渠道篡改"路径——三种不同的攻击面，三种不同的断裂方式，但结果殊途同归。
对于 AI 领域来说，这个问题尤其严峻。原因有三：
一是 AI 项目的依赖链特别长。一个典型的 LLM 应用，从模型调用到向量数据库到 Web 框架到前端 UI，依赖的包动辄上百个。攻击面大得吓人。
二是 AI 开发者手里的"钥匙"特别值钱。模型 API Key 按 token 计费，被盗用就是真金白银的损失。更不用说训练数据、用户对话记录这些敏感资产。
三是 AI 生态迭代太快，安全意识跟不上。很多团队为了追新模型、新框架，频繁升级依赖，甚至直接 pip install --upgrade 一把梭。在供应链投毒面前，这种习惯无异于裸奔。
你现在该做什么
国家网络安全通报中心给出了一套防护建议，我把它翻译成开发者能直接执行的操作：
锁死依赖版本，别用范围匹配。 package.json 里把 ^1.14.0 改成 1.14.0，requirements.txt 里把 litellm>=1.82 改成 litellm==1.82.6。是的，这会让升级变麻烦，但至少不会在你不知情的情况下拉到恶意版本。
启用包校验。 npm 支持 --integrity 校验，pip 支持 --require-hashes。用起来：
# pip 使用 hash 校验
pip install litellm==1.82.6 --require-hashes --hash=sha256:<official_hash>
# npm 的 package-lock.json 默认包含 integrity 字段，确保提交到版本控制
隔离开发环境。 每个项目用独立的虚拟环境或容器，别在宿主机上裸装。如果恶意代码只能在一个隔离的容器里执行，损失可控。
凭据不要硬编码，不要放 .env 文件。 用 Vault、AWS Secrets Manager 或者至少用环境变量注入。.env 文件太容易被恶意代码读取了。
关注安全通报。 订阅你所用关键依赖的安全公告。PyPI 和 npm 都有安全通知机制，GitHub 的 Dependabot 也能自动检测已知漏洞。
定期审计依赖。 用 npm audit、pip-audit 或 Snyk 等工具扫描项目依赖：
# npm 审计
npm audit
# pip 审计（需要安装 pip-audit）
pip install pip-audit
pip-audit
写在最后
供应链投毒正在从"偶发事件"变成"常态威胁"。深信服千里目安全技术中心在近两周内就连续监测到三起大规模事件，频率之高前所未有。
对于 AI 开发者来说，这是一个必须正视的现实：你写的代码可能没有 bug，但你依赖的代码可能有后门。在"快速迭代、拥抱开源"的行业氛围下，安全往往是最先被牺牲的那个优先级。
这次通报是一个信号。供应链安全不再是安全团队的事，它是每一个执行 install 命令的开发者的事。
参考来源：
- 国家网络安全通报中心：近期集中爆发多起供应链投毒攻击事件 — IT之家报道，包含完整通报内容及防护建议
- 安全工具被入侵，引发大规模AI供应链投毒 — 知乎专栏，微步情报局对 LiteLLM 投毒事件的技术分析