作者：正己
2026 年 3 月 24 日，一场精心策划的供应链投毒攻击降临在全球最受欢迎的 AI 代理框架之一——LiteLLM 身上。这款月下载量超过 9500 万次的开源项目，在短短数小时内成为黑客窃取企业核心机密的利器。API 密钥、SSH 私钥、云服务凭据、数据库配置……数以万计的敏感信息在用户毫不知情的情况下被加密外传。
事件令人深思的不仅是攻击手法本身，更是一个根本性问题：为什么这么多企业把大模型 API 密钥的安全命运，交给了一个开源的第三方代理？
事件回顾：一次连锁式供应链攻击
时间线
- 3 月 24 日：安全监测系统首次捕获异常信号，PyPI 平台上出现了两个可疑的 LiteLLM 新版本。
- 3 月 25 日：多家安全厂商发布预警，确认 LiteLLM v1.82.7 和 v1.82.8 含有恶意代码。
- 攻击被发现后：PyPI 平台紧急下架受影响版本，LiteLLM 团队暂停所有新版本发布并启动全面排查。
攻击手法详解
此次攻击并非一次孤立的投毒行为。安全社区追踪发现，代号为 TeamPCP 的威胁组织发起了一系列连锁式供应链攻击——他们首先攻陷了开源安全扫描工具 Trivy 的 CI/CD 流水线，进而从中获取了 LiteLLM 维护者的 PyPI 发布凭据，最终绕过正常的代码审查流程，直接在 LiteLLM 的发布包中植入了经过高度混淆的恶意代码。
1. 利用 .pth 文件实现静默执行
攻击者在发布包中植入了名为 litellm_init.pth 的恶意文件。Python 的 .pth 文件在解释器启动时会被自动加载执行，无需任何显式导入。只要开发者通过 pip install 安装了受影响版本，恶意代码就会在后台悄然运行——用户甚至不需要在代码中 import litellm。在 v1.82.7 版本中，攻击者还将恶意载荷嵌入了 proxy/proxy_server.py，进一步增加了检测难度。
2. 全方位窃取敏感数据
恶意代码一旦激活，会立即扫描并窃取以下关键信息：
- 环境变量与 .env 文件：包含各类 API 密钥（OpenAI、Anthropic、Azure 等）、数据库连接字符串。
- SSH 密钥：用于服务器登录的私钥文件。
- 云服务凭据：AWS、Azure、GCP 等云平台的访问密钥及云元数据。
- 容器与编排配置：Kubernetes secrets、Docker 配置。
- Git 配置：包含仓库访问凭据的
.gitconfig和 credential 信息。 - Shell 历史记录：bash/zsh 历史记录中可能包含的明文密码和命令。
- 加密钱包密钥：加密货币相关的私钥和助记词。
3. 混合加密外传，规避检测
被窃取的数据先使用 AES-256-CBC 对称加密（配合 PBKDF2 密钥派生），再用 RSA-4096 公钥加密会话密钥，随后通过 HTTPS 发送至攻击者控制的 models.litellm.cloud。这个域名与 LiteLLM 官方域名极为相似，极具迷惑性；而混合加密方案使得即便拦截到流量，也无法解析出被窃取的内容。
问题的根源：为什么 LiteLLM 用户首当其冲？
要理解这次攻击为何如此致命，必须先理解 LiteLLM 在 AI 技术栈中扮演的角色。
LiteLLM 本质上是一个大模型 API 的统一代理层。 它帮助开发者用一套接口调用 OpenAI、Anthropic、Azure、Google 等多家大模型服务，免去逐一对接的繁琐工作。这正是它月下载量超 9500 万次的原因——几乎每一个需要调用多个大模型 API 的企业都会考虑使用它。
但问题也正出在这里。作为代理层，LiteLLM 天然需要接触所有的大模型 API 密钥。 开发者通常将各服务商的 API Key 配置在环境变量或 .env 文件中，由 LiteLLM 读取并代为转发请求。一旦 LiteLLM 本身被植入恶意代码，这些密钥就像是放在没有锁的保险柜里——攻击者不费吹灰之力就能全部拿走。
这暴露了一个架构层面的致命缺陷：将密钥管理和 API 代理的职责，交给了一个本地部署的开源组件，而这个组件的安全性完全取决于上游供应链是否可信。
阿里云 AI 网关：从架构层面根治安全隐患
阿里云 AI 网关同样提供多模型统一代理、协议适配、负载均衡、故障容灾（Fallback） 等 LiteLLM 的核心能力——但它以云服务的形态交付，从根本上改变了安全模型。更重要的是，AI 网关深度集成了 阿里云 AI 安全护栏，为流经网关的每一次 AI 交互加装了实时安全防护。
为什么接入 AI 网关就能防范 LiteLLM 类攻击？
1. 密钥零暴露：API Key 从不落地到客户端
这是 AI 网关与 LiteLLM 最本质的差异。
使用 LiteLLM 时，开发者必须将各大模型服务商的 API Key 配置在本地环境变量或服务器上，LiteLLM 读取后代为转发。一旦 LiteLLM 被投毒，这些密钥唾手可得。
AI 网关的做法截然不同：后端模型服务的 API Key 被安全地存储在 AI 网关中，并可对接 KMS（密钥管理服务）进行加密保护，对客户端完全透明。客户端通过 AI 网关提供的鉴权机制（如 JWT Token）访问服务，全程无需持有任何大模型服务商的静态密钥。即使客户端环境被攻破，攻击者也拿不到任何有价值的模型服务密钥。
LiteLLM 模式下，密钥散落在每台开发机和服务器的环境变量中；AI 网关模式下，密钥集中托管在云端，客户端零接触。这从根本上消灭了 LiteLLM 事件中 API 密钥被窃取的攻击面。
2. 无需安装第三方代理包：消除供应链攻击入口
LiteLLM 事件的攻击路径是：开发者 pip install litellm → 恶意 litellm_init.pth 文件静默执行 → 数据外传。这条攻击链的前提是开发者必须在本地安装一个第三方包。
使用 AI 网关后，开发者直接调用 AI 网关的 API 端点即可，与调用任何一个标准的 HTTPS API 无异。不需要安装额外的代理包，不需要在本地运行第三方代码。供应链投毒攻击从根本上失去了载体——你无法投毒一个不存在的本地依赖。
3. AI 安全护栏：AI 应用的纵深安全防线
上述两项架构优势已经从根本上消除了 LiteLLM 类供应链攻击的可能。但 AI 应用面临的安全威胁远不止供应链投毒。阿里云 AI 网关深度集成了 AI 安全护栏——阿里云内容安全团队打造的专业 AI 安全防护产品——为 AI 应用提供全方位的纵深安全防护。
用户接入 AI 网关后，只需在控制台一键开启 AI 安全护栏策略，即可为所有经过网关的 AI 流量自动加装以下安全检测能力，无需额外集成或部署：
敏感数据保护
AI 安全护栏对流经网关的每一次请求和响应进行实时扫描，自动识别并拦截 API 密钥、数据库凭据、个人身份信息（PII）等敏感数据的异常传输。即使有内部人员或恶意代码试图通过 AI 请求通道外传敏感信息，安全护栏也会在出口处将其拦截。
提示词攻击防护（Prompt Injection Defense）
基于 AI 语义理解技术，精准识别并阻断直接注入、间接注入、越狱提示词（Jailbreak）等各类攻击手段，防止攻击者通过恶意提示词诱导模型执行非预期操作，保护业务逻辑不被突破。
恶意 URL 与内容检测
对模型输入输出中的 URL 和内容进行实时安全检测，识别钓鱼链接、恶意软件分发地址等威胁，阻止 AI 应用成为恶意内容传播的通道。
内容合规检测
基于 AI 语义理解的深度检测，精准识别涉黄、暴恐、敏感信息等各类违规内容，包括隐喻表达和高对抗性风险，确保 AI 应用输出始终合规。
模型幻觉检测与数字水印
识别和标记模型生成的不准确信息，帮助企业控制 AI 输出质量；数字水印功能确保 AI 生成内容的可追溯性，满足监管与审计需求。
AI 安全护栏是一个独立的专业安全产品，同时已与 AI 网关深度集成。通过 AI 网关接入，用户无需单独部署安全护栏服务，开箱即用；对于有更灵活需求的场景，也可通过独立 SDK/API 方式直接接入 AI 安全护栏。
4. 全链路流量可观测：异常行为无所遁形
AI 网关提供完整的流量监控和日志审计能力。每一次 API 调用的来源、目的、内容、耗时都有完整记录。出现异常的调用模式——例如短时间内大量非常规请求、请求内容中携带异常数据——运维团队可以第一时间收到告警并采取措施。
相比之下，LiteLLM 作为本地部署的开源组件，其网络行为的可观测性完全依赖于运维团队自行建设的监控体系。这次事件中，恶意代码将数据外传至伪装域名 models.litellm.cloud，很多团队在事件曝光前根本没有发现这一异常连接。
5. 企业级的高可用与弹性
除安全优势外，AI 网关还提供 LiteLLM 难以企及的企业级能力：
- 负载感知路由：基于实时监控数据智能分配流量，避免单一模型服务过载。
- 自动 Fallback：当某个模型服务异常时，自动切换到备用服务，保障业务连续性。
- 弹性扩缩容：Serverless 架构自动应对流量峰谷，无需运维。
- 多模型统一接入：支持 Model API、Agent API、MCP API 等多种协议的统一代理。
对比总结：LiteLLM 本地部署 vs 阿里云 AI 网关
紧急应对：如果你正在使用 LiteLLM
如果你的系统中部署了 LiteLLM，请立即采取以下措施：
1. 版本检查与回滚：确认当前使用的版本号，如果是 v1.82.7 或 v1.82.8，立即回滚至安全版本 v1.82.6。
2. 排查恶意文件：在 Python 的 site-packages 目录中搜索 litellm_init.pth 文件并删除；检查 proxy/proxy_server.py 是否被篡改。
3. 全面轮换凭据：将受影响系统上的所有 API 密钥、SSH 密钥、云服务凭据和数据库密码视为已泄露，立即全部更换。
4. 审查网络日志：检查是否存在与 models.litellm.cloud 相关的外部连接记录。
5. 后门排查：对系统进行全面的安全扫描，清除可能被植入的持久化后门。
6. 评估迁移至 AI 网关：从架构层面消除对本地开源代理的依赖，将大模型 API 管理迁移至阿里云 AI 网关。
从 LiteLLM 事件看 AI 安全的未来
LiteLLM 投毒事件不会是最后一次针对 AI 供应链的攻击。TeamPCP 组织通过连锁式供应链攻击（Trivy → LiteLLM）展示了一种令人警惕的新趋势——攻击者不再满足于投毒单一项目，而是通过攻陷上游依赖实现“一鱼多吃”。随着大模型应用的快速落地，这类攻击只会愈发复杂和隐蔽。
这次事件给我们最大的启示是：AI 应用的安全不能仅靠“小心安装包”来保障，而需要从架构设计上就将安全作为核心考量。 将密钥管理交给专业的云服务，将安全检测交给 AI 安全护栏，将流量治理交给 AI 网关——让专业的基础设施做专业的事。
阿里云 AI 网关：help.aliyun.com/zh/api-gate…
AI 安全护栏：www.aliyun.com/product/con…
AI 安全不是终点，而是一段持续的旅程。 选择正确的基础设施，就是为这段旅程选择了最坚固的起点。
本文基于 2026 年 3 月 LiteLLM 供应链投毒事件公开报道整理分析。如需了解更多 AI 安全解决方案，欢迎访问阿里云 AI 网关产品页面。
