近一成暴露在公网的 LiteLLM 网关，接受了配置指南里的示例 key sk-1234
近一成对公网暴露的 LiteLLM 网关，会直接接受配置指南里的示例 key sk-1234。这把 key 一旦到手，就能牵出存在后面的每一把模型提供者 API key，以及网关背后那组云端凭据。以下是 Wiz 查出的结果、四个 CVE，以及你今天该在自己的网关上检查的事。
如果你用 LiteLLM proxy 来串 AI——把这个开源网关架在模型提供者和你的应用之间的那一层——现在有一件安全事该今天就看。而且它不是那种没人利用得了的零日漏洞，而是预置 key 就藏在项目自己的配置指南里。
Wiz 的安全研究人员扫了公网上的 LiteLLM 网关，拿 LiteLLM 官方配置文档里的那把示例管理员 key sk-1234 去试。The Hacker News 报道了结果，Wiz 的原始研究 也确认了数字：在 3,074 台暴露到公网的网关里，有 294 台——近一成——接受这把 key。其中 191 台压根没设任何 key，所以放什么进去都收。
查到了什么
Wiz 没用多花哨的攻击手法去撬这些机器。它就是把配置指南里的示例值原样拿出来，请网关验明正身。一台会接受 sk-1234 的网关，实际上等于向任何「知道它是台 LiteLLM、又知道预置值写什么」的人敞开着。
而且这暴露是真实、且正在发生的。截至 2026 年 9 月 9 日，LiteLLM 自己的配置指南 还挂着 sk-1234，紧上面就一行注释，提醒操作者上线前换成一串长随机值。预置值，正在做预置值该做的事。
Wiz 八月的第二次扫描，还看到超过 85,000 台 LiteLLM。但 Wiz 特意说明，那批多半是蜜罐或测试系统，所以这个数字不能跟 3,074 直接比——不同扫描、不同样本。把它理解成「这套软件到处都是」，而不是「有 85,000 台网关被攻破了」。
Source: Wiz 研究，2026 年 2 月。85,000+ 的 8 月数字是另一次、不可直接比较的扫描（多为蜜罐/测试）。
为什么一把 key 这么要命
主 key 同时担两个角色，这正是预置值危险的地方。它既是管理员 key，也是让鉴权生效的那个开关。在 1.82.0-stable 之前，一台没设主 key 就启动的网关，会把每一个进来的请求都当成拥有完整管理员权限。
这些机器上的管理员，能碰到的东西比多数人想象的多。一台网关通常握着：
- 它串接的每个提供者的 API key——OpenAI、Anthropic、Google，还有别的。
- 经过它的所有 prompt 与回复，明文。
- 通过 MCP（Model Context Protocol） 连到操作者接上去的内部工具。
- 它跑的那组云权限——因为它就是带着那组权限上线的。
光是偷到提供者的 key，攻击者就能记在受害者的账单上跑模型——这种滥用早就有个名字：LLMjacking。
一把 key 怎么摸到你的云账号
这一段，是把一个糟糕预置值变成一起真正事故的关键。LiteLLM 允许管理员建立直通端点（pass-through endpoint）——一条把请求转发到管理员指定任何 URL 的路由。目标 URL 不会被比对私有地址段、localhost 或云元数据地址。
于是管理员可以把一条路由指向云端的实例元数据服务（IMDS），再读回它返回的 IAM 凭据。改成 IMDSv2 也挡不住：LiteLLM 文档写明，任何带 x-pass- 前缀的 header 都会把前缀剥掉后转发给目标，Wiz 就靠这个送出了 IMDSv2 要求的那几个 header。
要讲清楚这是什么、不是什么：没有任何来源报道对真实部署这么做过。 这是一次演示，而且得先有管理员权限——而那正是 sk-1234 预置值白给的东西。Wiz 说这功能算得上「符合设计」，因为 LiteLLM 的威胁模型把管理员当可信。它没有 CVE，也没有修复。
四个 CVE——有一个严重度还有争议
一共追了四个漏洞。三个明明白白、评为高；第四个，是研究者和维护者意见分歧的地方。
| CVE | 危害 | 受影响版本 | 修复于 |
|---|---|---|---|
| CVE-2026-59822 | MCP 鉴权绕过——任何 Bearer token 的已鉴权 MCP session，都能碰到已配置的 MCP 工具 | 1.84.0 之前 | 1.84.0 |
| CVE-2026-42271 | 经 MCP stdio 测试端点执行命令——任何已鉴权用户都能在主机上跑命令 |
1.74.2 起、未含 1.83.7 | 1.83.7 |
| CVE-2026-59821 | 自订代码 guardrail 检查绕过——在网关容器内执行代码 | 1.82.0-stable 之前 | 1.82.0-stable |
| CVE-2026-40217 | guardrail 沙箱逃逸——在默认容器映像中以 root 执行代码 | 1.81.8 起、未含 1.83.10 | 1.83.10（advisory 文字写 1.83.11） |
四个都在 NVD 有登记，也都列在 LiteLLM 自己的安全 advisory 里。要特别细看的是 CVE-2026-59821。Wiz 把它描述成鉴权后、以 root 执行代码，还放了一段测试返回容器内的 uid=0(root)。LiteLLM 的 advisory 把同样的行为评为低（CVSS 2.1），理由是它需要一个高权限账号。两个其实描述的是同一段代码：1.82.0-stable 之前，建立与更新自订代码 guardrail 的那些端点跳过了测试端点会做的沙箱与 pattern 检查，所以任何能碰到这些端点的人，都能提交一段在容器内跑的 Python。
连 LiteLLM 自己的记录，都没完全盖到一个坑。五月另有一份 advisory，CVE-2026-40217，说沙箱可以用 bytecode 手法逃逸、跑到 proxy 进程里执行代码——而那个进程在默认 Docker 映像里是以 root 跑的。它涵盖 1.81.8 起、未含 1.83.10，要碰到端点得有 proxy 管理员 key。而主 key 正是那把 key。
现在该做什么
如果你跑 LiteLLM 网关，照这个清单往下走。前两项根本不需要换版本。
- 把主 key 从
sk-1234换成一串长随机值。这一步最有价值，而且不用升级。换之前，先确认有没有另外设过 salt key——两者的轮换程序不一样，用错那把可能让已存储的凭据读不出来。 - 升到 1.84.0 或更新。 1.84.0 比表内每个漏洞的修复版本都新，一次升上去就全涵盖。
- 如果暂时升不了，就在你的反向代理或 API 网关挡掉攻击面：
/mcp/和两个 MCP 测试端点（POST /mcp-rest/test/connection、POST /mcp-rest/test/tools/list）；另外挡POST /guardrails/test_custom_code，把POST /guardrails和PUT /guardrails/{guardrail_id}限成只有管理员能用。这些都是 LiteLLM 自己 advisory 里的规避法。 - 审一遍你的直通端点，限制容器外连网络，并给这组 workload 能跑的最小 IAM 角色。
- 如果怀疑攻击者进来过：查一下 guardrail 列表里有没有不是你建出来的项，重启进程清掉内存里留着的代码，再轮换提供者 key、主 key、数据库凭据。升级既不会移除攻击者登记过的 guardrail，也不会移除他加上的 SSH key。
一个诚实的空白：对直通路由摸到实例元数据这条路，没有补丁，因为 LiteLLM 不把它当漏洞。外连限制和最小 IAM 角色，是这条路唯一能用的控制。而且目前没有任何来源，教你怎么检查一台你接手过的网关上 MCP 或直通路由有没有开——流传在外的检测查询（包括微软那套）找的是被利用的迹象，不是配置。
更大的教训：网关已经是你的边界
这件事，说到底不是关于 sk-1234。它是关于你的 AI 信任边界搬到哪里去了。
过去几年，模型提供者那边才是边界——你把 prompt 和 key 交给它。现在，在你的应用和那些提供者之间，多了一台你自己的网关：一个揽下所有提供者 key、看尽所有流量、带着所跑 workload 那组云权限、还能经 MCP 路由到内部工具的组件。它是一个凭据汇聚点，多数团队的网络根本没为它设计过。
对任何跑 AI stack 的团队，实际的启示是：
- 盘点每一台 架在模型提供者前面的网关——包括前一任团队或厂商建好、再没动过的。
- 确认它实际跑的是哪把管理员 key。 一台对
sk-1234应声的机器，在安全意义上就等于没鉴权。 - 假设它揽的那座 key 库，敏感度等同任何一台密钥管理器，照那个标准去防：强而独特的 key、最小 IAM、限制外连、加上补丁节奏。
结论
预置示例 key，是真实事故最便宜、也最常见的起点。LiteLLM 不是个坏项目——它又大又普及，也对发现的漏洞有回应。但这里的规律值得刻进心里：你的 AI 网关越居中，它揽下的每把凭据、每组云权限，就越成为单点失陷。
如果你不想自己扛这个汇聚点，那正是我们帮人做的事。
外部参考
- Wiz — Breaking LiteLLM: From Auth Bypass to Cloud Compromise — 原始研究：
sk-1234扫描、直通摸到 IMDS 的路径、以及四个 CVE（2026）。 - The Hacker News — 近一成暴露的 LiteLLM 网关接受示例 key sk-1234 — 对 Wiz 发现的独立报道与规避表（2026 年 9 月 9 日）。
- LiteLLM 安全 Advisories（GitHub） — 项目自己的 advisory 清单，以及四个 CVE 的严重度评定。
- NVD — 四个 CVE — CVE-2026-59822、-42271、-59821、-40217 及其 CVSS 分数。
- LiteLLM 文档 — 仍挂着
sk-1234示例的配置指南，以及x-pass-header 直通行为。
