指路明灯君这周技术圈里讨论度蹿升最快的关键词，不是某个新模型，而是LiteLLM和供应链攻击放在一起的消息。作为AI应用层的开源网关，LiteLLM被大量团队用来统一转发不同模型服务的请求，可恰恰是这种“统一”属性，让它手里握着大量凭证信息：OpenAI的API Key、云厂商的AK/SK、内部环境的Master Key。一旦这类程序被恶意代码污染，攻击者拿到的不是一台机器的控制权，而是整套模型账密的访问权。这篇文章就给正在跑LiteLLM proxy的团队，梳理一次供应链攻击从投毒到窃取凭证的完整链路，以及中招后该怎么查、平时该怎么防。内容同时适合AI基础设施负责人、后端开发和安全运维人员参考。
1. LiteLLM代理在调用链里的位置，决定了它必然是攻击目标
1.1 一个网关替你的团队守住了多少密钥
用过LiteLLM的人都知道它的方便：团队里不需要每个人都去申请各家模型厂商的Key，只需要在LiteLLM proxy上配好上游模型，大家一起访问一个统一的OpenAI兼容端点就行。这个代理进程通常还会负责负载均衡、成本统计、并发控制，甚至带一个管理界面。
但你有没有算过，这个进程权限范围有多大？
它启动时会读取配置文件和环境变量，里面大概率躺着至少这些内容：
- OpenAI / Azure OpenAI 的API Key
- Anthropic、Google Gemini等多家模型厂商的Key
- LiteLLM自身的master_key，也就是管理界面和API的访问令牌
- 连数据库的字符串，比如用于记录用量和费用的PostgreSQL连接串
- 如果部署在云上，还可能有云厂商角色专用的临时凭证，或者通过环境变量暴露的AK/SK
这些值只要有一个被恶意代码读到，攻击者就能绕过LiteLLM的控制面直接调用你所有的模型额度。更麻烦的是，LiteLLM proxy常被部署成常驻服务，很多人图省事直接用root或用特权容器跑。攻击者一旦能在进程里执行代码，读取宿主机文件、嗅探内存、访问云元数据服务，基本没有任何阻力。
这个集合效应让LiteLLM成了一个“天然的密码保险柜”——而这个保险柜的钥匙，就挂在那些依赖包和启动脚本上。安全团队如果只盯住模型API本身，却忽略了网关这一层，等于把保险柜放在门口又没上报警器。
1.2 为什么供应链攻击者盯上了这类工具
供应链攻击的逻辑和“打单个目标”不太一样。攻击者最关心三件事：覆盖面够不够广、拿到的东西值不值钱、做了手脚之后能不能在短时间内大量复制扩散。
LiteLLM刚好三条全占。
从覆盖面看，它依赖PyPI上的Python包分发，安装路径千奇百怪：有人用pip install直接装，有人写进requirements.txt，有人把它打进Docker镜像，还有人通过运维脚本批量部署到多台机器。只要包源被污染，一次发布可能影响上千家公司的环境。攻击者不需要逐个攻系统，篡改一个上游包就够了。
从价值看，绝大多数AI应用团队用LiteLLM都是把密钥集中在代理层管理。它不像普通工具那样只泄露某一个环境变量，而是能一次性把“和模型服务相关的所有账密”都端走。这种高密度凭证集中点，在攻击者眼里比普通业务服务器有价值得多。
从隐蔽性看，LiteLLM代理对外发起HTTPS请求是正常行为。它每天都和各家模型API保持长连接，攻击者把窃取的凭证混在出网流量里带走，如果团队没有做出口流量审计，基本不会被怀疑。这就解释了为什么针对性供应链投毒会选这种工具而不是某个小众脚本库：收益高、暴露面大、又不容易被发现。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一次典型的投毒过程：从恶意发布到成功运行
2.1 软件包分发链路中的薄弱点
LiteLLM的官方包托管在PyPI，但供应链攻击未必只发生在官方仓库。常见的有这么几条渗透