Higress 团队：LiteLLM 两次投毒后，爆炸半径取决于扩展代码的默认权限
Higress 团队在 LiteLLM 第二次供应链投毒事件后提出：攻击无法根除，但损失半径由扩展代码的默认权限决定。Python 代理的依赖与回调拥有进程全部权限，而 Wasm 沙箱通过取消文件系统、任意网络访问和进程派生能力，将恶意代码限制在请求处理范围内。
2026 年 10 月 21 日，LiteLLM 1.107.0 在 PyPI 发布后仅 1.7 小时被隔离，但攻击者已在不到五小时内使用窃取的 AWS 凭证调用了 bedrock:ListFoundationModels。这是 LiteLLM 在半年内的第二次供应链投毒，攻击者的目标几乎相同：云凭证、SSH 私钥、K8s Token，以及代理数据库中集中存储的所有上游模型 API Key。
Higress 团队在事件分析中提出了一个比'如何防止投毒'更根本的问题：投毒终将发生，如何确保恶意代码即使进入系统也拿不到东西？他们的回答是：真正决定爆炸半径的，是扩展代码拥有多少默认权限。
这个判断来自对两类代理架构的对比。LiteLLM 是 Python 进程，其第三方依赖和自定义回调本质上都是进程内 Python 代码，拥有与代理进程完全相同的权限——能读的文件、能看的环境变量、能连的网络、能启动的子进程，对恶意代码同样可用。1.107.0 的 infostealer 正是利用了这一点：通过 .pth 启动钩子在解释器启动时自动执行，读取 /.aws/credentials、/.ssh/id_rsa、K8s ServiceAccount Token，甚至直接连接代理数据库查询 LiteLLM_CredentialsTable。
Higress 的方案是将扩展代码约束在 Wasm 沙箱中。其数据平面基于 Envoy（C++），核心网关能力由 Envoy 原生实现；AI 代理、认证、限流、内容安全等扩展能力作为 Wasm 插件运行在 Envoy 内嵌的 Wasm 虚拟机中。插件与 Python 依赖的根本区别在于：Python 依赖默认拥有进程全部权限，而 Wasm 插件只拥有宿主显式暴露的有限能力。
具体而言，根据 proxy-wasm-cpp-host 源码，Wasm 沙箱取消了以下能力：无文件系统（path_open 始终返回 NOENT，插件无法读取任何文件）；环境变量默认不可见（environ_get 仅返回在 WasmPlugin vmConfig.env 中显式声明的变量）；无任意网络访问（sock_send 和 sock_recv 返回 ENOTSUP，插件必须请求 Envoy 代为发送，而 Envoy 会检查目标集群是否存在）；无进程派生（没有 fork/exec，无法生成守护进程或部署 Pod）；内存隔离（每个插件只能访问自己的线性内存，无法读取 Envoy 进程中的 TLS 私键或其他插件的数据）。
Higress 团队同时承认沙箱不是银弹：插件仍可读写其处理的请求和响应，有机会通过响应外泄数据；ai-proxy 必须持有上游 API Key 才能转发请求。因此他们建议配合最小权限（将能力拆分到不同插件，认证插件只拿消费者凭证，模型代理只拿模型密钥）、版本固定（用版本号加 sha256 引用插件而非 latest）和托管凭证（企业版用 KMS 加密管理密钥）共同使用。
在发布流程上，Higress 从 v2.2.4 起采用不可变发布：构建一次、审查快照、按摘要晋升。正式版本标签不可变——如果同名标签已存在且摘要不同，发布立即失败。这与 LiteLLM 事件中 latest 和 main-stable 标签被重新指向恶意镜像形成对比。
需要指出的是，这一论证来自 Higress 自身，其性能对比数据（如 1 MB 请求延迟降低 68.8%–97.1%）为厂商自测，未经独立复现。架构层面的沙箱属性可从开源代码验证，但整体方案的安全有效性仍取决于实际运营纪律和插件生态的完整性。