LiteLLM 半年两度被投毒，大模型的“钥匙串”该放在哪里？

作者：澄潭

从 1.107.0 事件，看 Higress 的 Wasm 沙箱与不可变发布。

北京时间 10 月 21 日 19:39，LiteLLM 1.107.0 出现在 PyPI 上。7 分钟后，Docker Hub 和 GHCR 上的 latest、main-stable 等标签也被指向了投毒镜像。

LiteLLM 是一个周下载量约 2300 万的开源 LLM 代理，这已经是它在 2026 年第二次遭遇供应链投毒。上一次是 3 月 24 日的 1.82.7 / 1.82.8，两次只隔了 7 个月。

两次事件里，攻击者要的东西几乎一样：云凭证、SSH 私钥、K8s Token，还有 LiteLLM 代理里集中保管的、整个组织所有大模型厂商的 API Key。安全公司 Wiz 观察到，恶意版本发布后不到 5 个小时，攻击者就开始拿偷来的 AWS 凭证调用 bedrock:ListFoundationModels。

3 月份我们写过《OpenClaw 依赖的 LiteLLM 被投毒》，介绍了 Higress 如何防范镜像投毒和 PyPI 包投毒。这一次攻击手法升级了：源码是干净的，有毒的只是构建产物；发布审批也没有被绕过，而是被盗来的账号"正常"通过了。

所以这篇文章想回答一个更根本的问题：投毒终究会发生，怎样让恶意代码进来之后什么也拿不到？

事件复盘：一次"走完正规流程"的投毒

图 1：LiteLLM 1.107.0 攻击时间线（北京时间）

根据 LiteLLM 官方事件报告，以及 Wiz、Chainguard、Endor Labs、Datadog 等安全团队的分析，这次攻击可以拆成四步。

第一步：拿到钥匙。 攻击者拿到了三名开发者的 GitHub CLI OAuth Token。LiteLLM 官方认为，这些 Token 很可能是从一个对公网开放的内部 LiteLLM 部署的日志里泄露出去的。

第二步：改写发布流程。 18:08，攻击者尝试修改发布工作流，被分支保护拦下；5 秒后，他用一个有组织 Owner 权限的 Token 覆盖了保护，强行推入。改过的工作流不再从官方仓库 BerriAI``/``litellm 取源码，而是从一个只差一个连字符的仿冒仓库 Berri-AI/``litellm 构建。接着，第二个账号的凭证"通过"了生产发布审批；发布完成后，第三个账号的凭证被用来删除工作流运行记录。

第三步：只毒制品，不毒源码。 恶意改动藏在构建配置里：pyproject.toml 的 maturin 配置多了一行 data = "cook"。就这一行，让三个文件在安装时被放进 site-packages 根目录：

cook.pth：只有一行 import cook。Python 解释器每次启动都会执行 .``pth 文件里以 import 开头的行，你不需要 import litellm ，pip、IDE 后台、任何一个 Python 脚本启动都会触发它；
cook.py：解压并运行一个约 61 KB 的窃密程序；
sitecustomize.py：fork 出一个脱离终端的守护进程，每小时从 GitHub 上的"死信箱"读取服务器地址，下载并执行未签名的 Python 代码。

官方 Git tag 里的源码是干净的，恶意构建用的那份源码和它相差 309 个文件。Chainguard 指出，只审查 tag 源码的人会完全漏掉这次攻击。而且这些文件不在 litellm 包目录里，单纯卸载 litellm 也删不掉。

第四步：能拿的全拿走。 窃密程序有 16 个模块，覆盖：

SSH、GPG、TLS 私钥，Shell 历史；
AWS / Azure / GCP 凭证文件和实例元数据，并调用 GetCallerIdentity 验证凭证是否可用；
K8s 配置和挂载的 ServiceAccount Token、Docker 配置，以及 GitLab Runner、Jenkins、Vault、Terraform 等 CI/CD 机密；
浏览器保存的密码和 Cookie；
Claude、Codex、Gemini、Cursor、Copilot 等 15 种以上 AI 开发工具的凭证；
Linux 上所有可读进程的环境变量。

还有一个专门为 LiteLLM 写的模块：只要环境里有 DATABASE_URL，它就直接连上代理数据库，查询 LiteLLM_CredentialsTable 和 LiteLLM_ProxyModelTable 两张表。那里存着代理为所有下游团队转发请求时用的上游模型厂商 API Key。

偷到的数据用 AES-256-CBC 加密、RSA-4096 封装密钥，打包后伪装成健康检查，POST 到仿冒域名 www.litellm[.]dev/healthcheck。

浮动标签放大了影响。 Docker Hub 上的 latest、main-latest、main-stable 都被指向了投毒镜像。这意味着，即使没有主动升级到 1.107.0，只要在那 2.5 小时里拉取过这些标签，比如一个用 latest 的 Pod 恰好重启了，也会中招。Endor Labs 的总结是：浮动标签和不锁版本的安装，让一个坏版本波及了那些从没选择过它的部署。

PyPI 在大约 1.7 小时后隔离了 1.107.0，Docker Hub 的标签在大约 2.5 小时后全部撤下。但包可以下架，已经外传的凭证收不回来。LiteLLM 官方的建议很直接：只要 1.107.0 在能访问外网的主机上运行过，就按"已外传"处理，轮换所有凭证。

半年两次：入口不同，结局相同

图 2：两次投毒：入口不同，结局相同

3 月那次，入口是 CI 里用到的安全扫描器 Trivy。TeamPCP 先投毒了 Trivy，再借它从 LiteLLM 的 CI 里拿走 PyPI 发布 Token，直接向 PyPI 推送恶意版本。10 月这次，入口换成了开发者的 OAuth Token 和被篡改的发布工作流。

门不一样，进门之后做的事却几乎一样：

装上就执行。 两次都用了 .``pth 启动钩子，不需要 import。
与代理进程同权限。 恶意代码就是 LiteLLM 进程的一部分。进程能读的文件、能看的环境变量、能连的网络、能起的子进程，它都能用。
直奔"钥匙串"。 3 月的载荷会在 K8s 里给每个节点部署特权 Pod；10 月的载荷专门写了查 LiteLLM 数据库的模块。

我们没法保证任何开源项目永远不被投毒，包括 Higress 自己。维护者的账号会被盗，CI 依赖会被污染，审批也可能被偷来的账号"通过"。所以比"会不会被投毒"更该问的是：投毒发生之后，爆炸半径有多大？

攻击者为什么盯上 LLM 代理

Chainguard 在分析里说得很直白：一台被攻破的代理主机，可以一次性暴露许多上游 AI 厂商的 Key。

像 LiteLLM 这样自建的 LLM 代理，同时具备三个特点：

钥匙集中。 为了统一接入、统一计量，组织里所有模型厂商的 Key 都汇总在代理里。
位置敏感。 代理跑在生产集群里，通常带着云实例角色和 K8s ServiceAccount，还必须能访问公网上的模型 API。
扩展即进程。 在 Python 写的代理里，无论是第三方依赖还是自定义回调，本质上都是进程内的 Python 代码，和代理进程同权限。

Wiz 观察到的攻击者后续行为也印证了这一点：拿到 AWS 凭证后，第一批调用里就有 bedrock:ListFoundationModels。攻击者想要的，就是你的模型调用权限。

Key 集中管理本身是好事：统一接入、统一审计、统一轮换，都要以此为前提。问题出在第三条：所有扩展代码都拿着进程的全部权限，一个依赖被投毒，整串钥匙就跟着暴露。真正决定爆炸半径的，是扩展代码到底有多大权限。

Higress 的答案：把扩展代码关进 Wasm 沙箱

图 3：同样的恶意代码，放在哪里决定了它能拿走什么

Higress 的数据面基于 Envoy（C++）。路由、负载均衡、TLS 这些网关核心能力由 Envoy 原生实现；AI 代理、鉴权、限流、内容安全、MCP 等扩展能力，以 Wasm 插件的形式运行在 Envoy 内嵌的 Wasm 虚拟机里。Higress 官方提供的数十个插件，包括 ai-proxy、ai-token-ratelimit、ai-security-guard，都是这样运行的。

Wasm 插件和 Python 依赖的根本区别在于：Python 依赖默认拥有进程的全部权限， Wasm 插件默认只有宿主明确开放的那几项能力。 插件能做的每一件事，都要经过宿主（Envoy）提供的 Proxy-Wasm 接口：读写请求和响应、读取自己的配置、读写插件间共享的键值数据、向已注册的服务发请求、记日志和指标。除此之外，什么都做不了。

这一点可以直接到 Envoy 使用的 proxy-wasm-cpp-host $** **1$ 源码里核对：

1. 没有"装上就执行"。 Wasm 没有 .pth、sitecustomize 这类启动钩子。插件只有在 WasmPlugin 资源里被显式引用才会加载，代码只在请求处理和配置下发的回调里运行。

2. 没有文件系统。 宿主实现里，path_open 永远返回"不存在"（NOENT），fd_read 的注释写着"不支持读取任何文件"，fd_readdir 的注释写着"proxy-wasm 里没有真正的文件系统"。~/.aws/credentials、~/.ssh/id_rsa、/var/run/secrets/kubernetes.io/serviceaccount/token，插件一个字节都读不到。

3. 环境变量默认不可见。 environ_get 只返回这个 VM 被显式配置的变量。在 Higress 里，就是 WasmPlugin vmConfig.env 中逐个声明的那几个。宿主进程和其他进程的环境变量，对插件来说根本不存在。

4. 没有任意网络。 宿主不支持 socket，sock_send、sock_recv 都返回"不支持"（ENOTSUP）。插件要发外部请求，只能让 Envoy 代为发起，而 Envoy 会先检查目标 cluster 是否存在，不存在就直接拒绝。想把数据 POST 到 www.litellm[.]dev，或者访问 169.254.169.254 拿云实例凭证，只要这些地址没有在网关里注册为服务，就无路可走。

5. 没有进程。 Wasm 没有 fork/exec，起不了守护进程，写不了 systemd 服务，更没法在集群里部署特权 Pod。

6. 内存隔离。 每个插件只能访问自己的线性内存，读不到 Envoy 进程里的 TLS 私钥，也读不到其他插件的内存和配置。插件崩溃不会拖垮 Envoy 进程，可以按 FAIL_CLOSE 或 FAIL_OPEN 策略决定请求是拒绝还是放行。

把 1.107.0 的恶意动作逐条放进 Wasm 沙箱推演一遍：

图 4：把 1.107.0 的恶意动作逐条放进 Wasm 沙箱

▍沙箱不是银弹

需要说清楚的是：沙箱限制的是插件"越界"，限制不了插件在自己的职责范围里作恶。插件仍然能读写它经手的请求和响应，也就有机会借响应把数据带出去；它能读取自己的配置，也能访问 Proxy-Wasm 提供给插件之间共享的键值数据。比如 ai-proxy 要转发请求，就必须拿到上游 API Key。

所以沙箱之外，还要靠这几件事配合：

只装可信的插件。 插件来源要可追溯、源码可审计，这是第五节发布链路要解决的问题。
最小授权。 能力拆进不同插件，每个插件只拿到完成自己工作所需的凭证：鉴权插件拿消费者凭证，模型代理拿模型 Key。
版本锁定。 WasmPlugin 支持 sha256 字段，拉下来的插件校验和对不上就拒绝加载。生产环境建议用"版本号 + sha256"引用插件，不要用 latest。
凭证托管。 企业版用 KMS 加密托管 Key，网关配置里只保留加密引用（见第七节）。

发布链路：LiteLLM 失守的每一环，Higress 都上了锁

沙箱决定"毒进来之后能做什么"，发布链路决定"毒能不能进来"。

从 v2.2.4（2026 年 8 月发布）开始，Higress 官方 Go/Rust Wasm 插件采用一套"构建一次、评审快照、按 digest 晋升"的不可变发布流程。流程设计和工作流都在仓库里公开：docs/developers/immutable-plugin-releases.md $** **2$ 。

图 5：LiteLLM 失守的每一环，Higress 的对应设计

拿这次 LiteLLM 事件的每个环节来对照：

构建来源。 LiteLLM 的工作流被改成从仿冒仓库构建。Higress 的发布准备流程会校验目标必须恰好是 main 分支当前的 commit；每个候选制品都记录源码 commit 和输入哈希，汇总成快照文件，必须通过 PR 评审才能合入。
源码与制品。 LiteLLM 的 tag 干净、wheel 有毒。Higress 的插件镜像通过 OCI 注解（org.opencontainers.image.revision、io.higress.plugin.input-hash）绑定源码 commit 和输入哈希；正式发布时只按 digest 复制已经评审过的候选制品，从不重新构建。
发布审批。 LiteLLM 的审批被盗来的账号通过了。Higress 写入公共版本标签的凭证只放在受保护的 plugin-release-production 环境里；正式版本 tag 需要 release manager 人工审批，而且只有专用的发布 App 能创建。
版本标签。 LiteLLM 的 latest、main-stable 被改指向毒镜像。Higress 的公共版本标签不可变，发布时一旦发现同名标签的 digest 不一致就直接失败；latest 只在整批插件校验通过、且版本号只增不减时才前移；已发布的控制台、网关和 Standalone 默认配置都锁定具体版本，不依赖 latest。
审计痕迹。 LiteLLM 的工作流记录被删了。Higress 的发布快照和证据文件（含 SHA-256）直接提交在代码仓库里。以 v2.2.4 为例，plugins/release/snapshots/2.2.4.json $** **3$ 锁定了 43 个官方插件，每一个都记录了版本、镜像 digest、输入哈希和源码 commit，任何人都能核对：

json 复制代码

{
  "logicalId": "ai-proxy",
  "version": "2.0.1",
  "ociRef": "higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/ai-proxy:2.0.1",
  "digest": "sha256:754c4d6c9e8aed2cabc4aa37c21f1e6dbf3b4973f01c18765ab83c17ad4d40db",  
  "inputHash": "sha256:fc42f8a92ee198eacb59689be844cbeb00dab79b359b583cb404f4106fef5cee",
  "sourceCommit": "7774663e4353652f5c3cecd7e98a1a43b05ee15c"
}

此外，Higress 的镜像托管在阿里云容器镜像服务（ACR），推送后会做安全扫描，3 月那篇文章里有详细介绍。

说句实话：没有哪个流程能挡住所有盗号。不可变标签和 digest 锁定的意义在于，就算出了事，你已经在跑的版本不会被悄悄换掉，换没换一查便知。

给正在评估或迁移的团队

如果你在用 LiteLLM，先按官方指引处置：

不要先在受影响的环境里启动 Python 或 pip。每启动一次解释器，窃密程序就会再跑一次；
用 find、sha256sum 这类非 Python 工具，检查 site-packages 下的 cook.pth、cook.py、sitecustomize.py，以及 /tmp/.pc_once_*、/tmp/remote_code_loader.lock，并结束持有该锁文件的守护进程；
从一台干净的机器上轮换所有凭证：代理数据库里的模型厂商 Key、master key 和 virtual key、数据库密码、云凭证和实例角色、K8s Token、Git / npm / PyPI Token、SSH 密钥、AI 工具会话；
固定到 litellm==1.106.2，镜像按 digest 引用。

如果你在评估 AI 网关 ，Higress 能覆盖 LiteLLM 代理的核心场景：用统一的 OpenAI 兼容协议接入国内外主流模型厂商和 vLLM / Ollama 等自建模型（ai-proxy），消费者鉴权（key-auth、jwt-auth 等），Token 级限流（ai-token-ratelimit），多模型负载均衡与 fallback，调用观测与 Token 统计（ai-statistics），内容安全（ai-security-guard），以及 MCP Server 托管。不想自己部署的话，也可以直接开通 0 元起步的阿里云 AI 网关 Serverless 标准版（见第七节）。

如果你已经在用 Higress，几条配置建议：

插件引用固定版本号，并配上 sha256，不要用 latest；
vmConfig.env 只注入插件真正需要的变量，谨慎使用 HOST 方式透传宿主环境变量；
鉴权类插件保持 FAIL_CLOSE，WasmPlugin CRD 的注释里也明确不建议对鉴权插件使用 fail open；
网关里只注册业务需要的上游服务，这份服务列表本身就是插件的出网白名单；
自研插件和官方插件一样对待：源码可审计，构建流程独立，制品按 digest 发布。

Higress 企业版：把安全变成默认

开源 Higress 给了你一个安全的架构，但自建网关的安全，最后还是要落到运维纪律上：镜像从哪里拉、版本锁没锁、凭证多久轮换一次、漏洞多快跟进。

LiteLLM 的官方公告里有一句容易被忽略的话：使用其私有企业镜像仓库的客户，没有受到这次事件影响。 托管和企业分发渠道的价值，就在于把这些纪律交给专业团队来执行。

阿里云 AI 网关是 Higress 的企业版，与开源 Higress 同源，为大模型、Agent 和 MCP 服务提供统一入口，并提供与 Higress 兼容的迁移路径。

上手门槛很低：Serverless 标准版 0 元起步，没有实例费，按实际用量计费，适合先拿来试用、做开发测试，或者承载流量不大的业务；验证通过、要上正式生产时，再切到 Serverless 企业版。

图 6：Higress 企业版：在沙箱之外再补三层

▍在沙箱之外，再补三层

凭证不落地。 API Key 等凭证由 KMS 加密托管，网关配置里只保留加密引用，不以明文出现在配置文件、环境变量或日志中；背后是完整的 RAM 权限体系，每个消费者有独立的 Key，泄露的影响范围有限。
供应链托管。 网关引擎由平台构建、发布和升级，你不需要从公共仓库拉镜像，也不用盯着每一次版本更新。自定义插件可以在 WebIDE 里开发，构建在云效的 VPC 构建集群内完成，代码拉取、依赖下载、制品产出全程不经过公网。
流量与内容防护。 一键对接阿里云 WAF，拦截 SQL 注入、XSS、命令注入、CC 攻击和恶意 Bot；AI 安全围栏识别提示词注入和敏感内容。

自定义插件依然运行在 Wasm 沙箱里，平台在此基础上提供轻量隔离、权限严控、代码校验。

▍性能：外来代码进沙箱，平台代码追性能

隔离是有代价的。开源 Higress 的 Wasm 插件要读取、解析完整请求体时，数据需要复制进插件的线性内存；多个插件分别处理同一份大报文，复制和分配的开销会随请求体积和并发一起放大。Wasm 线性内存还有个特点：可以增长，但不能直接收缩，持续高并发下内存可能一直维持在高位。

企业版在安全和性能之间做了明确分工：用户自定义和第三方扩展继续跑在 Wasm 沙箱里；模型协议转换、大报文解析这类由平台自研、自维护的核心 AI 处理链路，则采用 Envoy 原生插件机制，并针对 AI 请求处理和内存使用做了专项优化，减少重复的数据复制和不必要的内存占用。这部分代码由平台在受控的研发与发布体系里维护和交付。

阿里云 AI 网关团队用同一套压测源码和合成 JSON 请求，访问同一个无等待的 Mock 后端，对比了 Serverless 企业版和开源 Higress 自建部署（两侧部署资源与访问入口不同，结果反映各自部署下的表现）：

1 MB 请求：10～100 并发下，企业版平均网关处理时延保持在 13～18 ms，比开源 Higress 低 68.8%～97.1%。降幅最大的是 90 并发，从 446.2 ms 降到 12.7 ms。
10 MB 请求：降低 82.7%～90.2%。降幅最大的是 30 并发，从 1,688.1 ms 降到 166.1 ms；到了 100 并发，企业版是 384.3 ms，开源 Higress 是 2,527.4 ms，每次请求少等约 2.14 秒。

图 7：1 MB 请求网关处理时延（图源：阿里云 AI 网关团队）

图 8：10 MB 请求网关处理时延（图源：阿里云 AI 网关团队）

消费者规模是另一个拉开差距的场景。Higress 7 月发布的 Serverless 企业版测试 $** **4$ 里，消费者数量增长到 1 万时，企业版认证 p50 时延为 1.47 ms，开源实现为 50.32 ms，相差约 34 倍；增长到 2 万时，企业版成功率保持 100%，开源实现降到 77.14%。原因在于企业版把消费者数据和认证配置分离，单次认证开销不会随消费者总量等比例增长。

▍成本：按量付费，从 0 元起步

Serverless 标准版：试用、开发测试、低流量业务。0 元起步，无实例费，按实际用量计费。
Serverless 企业版：正式生产业务；独立入口、自定义域名、传输加密，99.95% SLA。实例费参考价 0.245 元/小时（一天不到 6 元），请求调用、数据处理和公网流量按用量另计。
实例型独享版：对资源隔离、性能规格和高级治理要求更高的业务。按实例规格计费。（以上为参考价，以阿里云官网为准。）

"0 元起步"的意思是，标准版不收实例费，网关本身不按时长计费，只按实际用量收费（请求费用和公网流量）。流量小的时候，费用也跟着小，不需要先为一台闲置的网关付钱。等业务量上来、需要独立入口和 SLA 时，再升级到企业版。

自建开源网关的费用，除了计算、网络和冗余副本，还要为流量高峰预留容量；镜像维护、插件兼容性检查、升级回归和异常排查，也都是长期的人力投入。按 Higress 7 月发布的测算，中小规模场景下，Serverless 形态相比自建可以把费用降低 70%～90%。

图 9：自建与托管对比（图源：阿里云 AI 网关团队）

▍免费试用

两种方式上手：

AI 网关新客：领取价值 400 元的 AI 网关免费试用；
直接开通：Serverless 标准版 0 元起步、无实例费，按实际用量付费。

领取入口：阿里云免费试用中心

free.aliyun.com/?searchKey=...

了解产品：阿里云 AI 网关

www.aliyun.com/product/api...

结语

供应链攻击不会停。PyPI、npm、Docker Hub、GitHub Actions，每个环节都可能是下一次的入口。

在"装上就执行"的生态里，安全靠运气：你得祈祷依赖的每个包、每个维护者账号、每条 CI 流水线都不出问题。在"默认无权限"的沙箱里，安全靠架构：就算毒进来了，它也只能待在笼子里。

开源 Higress 把扩展代码关进 Wasm 沙箱，把发布链路锁成不可变；Higress 企业版再把凭证、供应链和防护交给平台托管。选哪一种，取决于你的团队想把精力花在哪里。想先试试托管形态的话，Serverless 标准版 0 元起步，不用先付实例费。

文章推荐：

《模型这么多，请求该交给谁？阿里云 AI 网关智能路由，正式上线！》

《AI 网关上线 FinOps 会话观测，助力企业优化 Agent 成本》

《网关处理时延降低 97.1%：开源 Higress 与阿里云 AI 网关 Serverless 企业版性能对比》

相关链接：

$1$ proxy-wasm-cpp-host

github.com/proxy-wasm/...

$2$ docs/developers/immutable-plugin-releases.md

github.com/higress-gro...

$3$ plugins/release/snapshots/2.2.4.json

github.com/higress-gro...

$4$ Serverless 企业版测试

higress.ai/blog/higres...

参考资料：

LiteLLM 官方：Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised

docs.litellm.ai/blog/securi...
Chainguard：LiteLLM attacked again: Malicious 1.107.0 wheels on PyPI and Docker Hub

www.endorlabs.com/learn/litel...
Endor Labs：LiteLLM 1.107.0 Compromised: Python Startup Hooks Steal Cloud, AI, and Proxy Credentials

www.endorlabs.com/learn/litel...
Wiz：LiteLLM Compromised, Steals Credentials

www.wiz.io/blog/litell...
Datadog Security Labs：LiteLLM supply chain compromise: What you need to know

securitylabs.datadoghq.com/articles/li...
The Register：LiteLLM supply chain attack hoovers up passwords and secrets

www.theregister.com/security/20...
Phoenix Security：TeamPCP Backdoors LiteLLM

phoenix.security/teampcp-lit...
Higress：不可变插件发布流程、WasmPlugin CRD

github.com/higress-gro...

github.com/higress-gro...
阿里云：AI 网关与 Higress 开源版多维度对比

help.aliyun.com/zh/api-gate...