李_涛1. LiteLLM失守意味着什么：AI网关是攻击者最想要的落点
1.1 AI网关在基础设施里的特殊位置
很多团队对AI基础设施的安全认知，还停留在“防Prompt注入”或者“给模型加护栏”这个层面。但真正搞过生产环境的人都知道，一个AI应用的调用链往往长得多：业务服务 → API网关 → 模型网关 → 各家模型服务商 / 私有化模型推理服务，中间还穿插着缓存、向量数据库、鉴权服务、成本统计组件。
LiteLLM这类产物刚好卡在整条链路最关键的十字路口上。它的核心功能是提供一个统一的代理层，把OpenAI、Anthropic、Cohere、本地vLLM这些来源不同的模型接口收敛成一个标准入口，顺带帮你做API Key管理、请求转发、成本统计、限流、缓存。简单说，业务代码不需要关心背后接的是哪家模型，只要打给LiteLLM就行。
这个位置的杀伤力是双面的。对工程师来说，它是再方便不过的抽象层；可对攻击者来说，它等于一个“全站流量的合法旁路”。只要控制住这个网关，就不需要费劲去打业务系统，因为所有请求、所有密钥、所有上下文本就都在它手里。
我见过不少团队把LiteLLM当作一个普通开源组件随手部署，觉得“反正它就是一个转发用的工具”，完全不设防。这类组件一旦出事，往往比直接打业务服务还致命。
1.2 “AI软件被投毒”要拆成两层看
这次事件标题里有个词很容易被带过去——“AI基础设施被投毒”。它其实包含两层含义，我建议每个做AI工程的人把这两层分开理解。
第一层是软件供应链投毒。攻击者往开源生态里投放恶意依赖包，或者劫持上游维护者账号后发布带后门的版本，最终让受害者的生产环境在升级/安装依赖时把恶意代码拉进来。LiteLLM本身是开源项目，又通过pip这样的包管理器分发，天然处于这类攻击的射程范围内。这一层和传统软件供应链攻击在原理上没有本质区别，只是受害者变成了AI基础设施。
第二层是模型/数据层面的投毒。这属于AI特有的攻击面，比如污染训练数据、篡改权重、给缓存响应注入恶意内容。模型网关恰好能把这两层连起来——如果攻击者控制了网关，他不光能拿到代码层面的权限，还可以直接篡改发往模型服务的请求，或者替换缓存里的响应，让业务在“模型输出一切正常”的错觉下持续收到恶意结果。
这两层叠加在一起，才是这次事件真正值得警惕的地方。传统安全团队通常只盯系统漏洞，AI团队往往只关心模型效果，而LiteLLM恰好落在两拨人的责任空档里。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从供应链投毒到网关失守：完整攻击链拆解
2.1 投毒入口最常发生在哪几个环节
先说一个值得所有团队反思的事实：大多数供应链攻击不是通过什么高级零日漏洞打进来的，而是利用了“信任”。
从公开信息里可以看到，这类攻击最常见的入口是包名混淆和依赖投毒。攻击者会在PyPI、npm这些公共源上注册一个与热门项目同名或近似的恶意包，或者想办法让某个间接依赖被替换成恶意版本。由于LiteLLM需要对接大量的模型服务商SDK，它的依赖树非常庞杂，任何一个中间层依赖被污染，最终编译进容器镜像里的代码都可能是带后门的。
第二个常见入口是维护者账号被劫持。攻击者拿到上游维护者的账号后，会发布一个“看似正常”的新版本，这个版本包含正常更新和隐蔽后门，等到受害者跑pip install时自动拉取。
第三个不太容易被注意到的入口是镜像层投毒。很多团队直接从Docker Hub拉现成的LiteLLM镜像部署，而镜像里的每一层都是云上构建的，你根本无法确定某一层在执行时究竟做了什么。如果上游仓库的Dockerfile或GitHub Action流水线被篡改，你拉下来的镜像就已经是“被加工过的产品”了。
2.2 攻击者的操作路径：关键节点逐步还原
结合过去几年真实发生的供应链攻击案例，我试着把这条攻击链还原一下，帮大家理解“网关失守”是怎么一步步实现的。
第一步，投放恶意依赖。攻击者选定几个LiteLLM的间接依赖项，在公共包仓库发布恶意版本。为了不被立刻发现，恶意代码会隐藏得很深——比如不在安装时立即触发，而是延迟到容器启动后某个随机时间才开始运行。
第二步，等待受害者更新。受害者的CI/CD流水线在构建镜像时执行pip install，不加锁版本的情况下拉到了恶意版本。恶意代码随容器镜像一