Wiz：近十分之一暴露在外的 LiteLLM 网关接受示例管理员密钥 sk-1234

2026年9月9日，Wiz Research 发表了一项关于 LiteLLM 的研究；LiteLLM 是位于应用程序与其付费的模型提供商之间的开源 AI 网关。报告称，在其于公共互联网上可访问的 3,074 个 LiteLLM 部署中，有 294 个——占 9.6%，接近十分之一——接受sk-1234，即项目自身设置文档中印出的示例主密钥，或根本不需要任何凭据。该字符串并非普通 API 密钥：在 LiteLLM 中，它既是管理员凭据，也是开启身份验证的开关，因此任何出示它的人都能读取网关上存储的每一个模型提供商密钥，监视经过网关的每一条提示和补全，并访问通过模型上下文协议（Model Context Protocol）连接的每一个工具服务器。Wiz 的合著者 Amitai Cohen 和 Yaara Shriki 将这种访问权限串联用于根级代码执行，并用于窃取主机的云 IAM 凭据。本文的叙述依据 Wiz 的报告、LiteLLM 自身的安全公告以及随后发布的 CISA 已知被利用漏洞目录，而 AI 事件档案 将这条记录与其相邻记录并列保存，每条记录都有自己的来源、严重程度和置信等级。

记录中唯一带有的日期就是发布日期，而它本身就是一个发布日期。标题背后的扫描是在 2026 年 2 月进行的；Wiz 所描述的两个代码缺陷最迟在 5 月中旬就已随版本发布修复，而项目自己的记录将这些版本分别标注为 3 月和 5 月；CVE 标识符于 7 月分配；目录条目则出现在 9 月。报告付印时，其中几乎所有内容都已过时，而这正是报告着力论证的一大要点。

9.6% 来自一次扫描，而 Wiz 表示其自己在 8 月的后续扫描结果无法与之比较

测量很简单，Wiz 也直截了当地说明了其方法：2026 年 2 月通过 Shodan 发现了 3,074 个面向互联网的 LiteLLM 代理，并逐一测试它们是否会使用文档中记录的示例密钥进行认证。其中，294 个会。在这组中，191 个根本没有配置主密钥，会接受向它们提供的任何字符串；其余则保留了设置指南中的占位符。这两种失效模式都不需要软件漏洞。两者都只需要网关地址和项目自身 README 中印出的值。

这也只是单一厂商的扫描结果。Wiz 的数字于 9 月 10 日被云安全联盟（Cloud Security Alliance）的 AI 安全倡议引用，并于同日被 The Hacker News 引用，但两者均以注明出处的方式转引，本文未能找到对 3,074 这一数字的独立复现。Wiz 于 2026 年 8 月进行了第二次扫描，发现超过 85,000 个实例，约为 2 月数量的 27 倍。该公司表示，其中大多数似乎是蜜罐或测试部署，并且这两个计数无法进行比较。目前没有当前的暴露数字，任何引用该数字的文章引用的都是 2 月的数据。

报告中还有一个数字并非来自扫描，而是 Wiz 自家的遥测数据：该公司称，在其观测到的云环境中，约三分之一都存在 LiteLLM。这只是一家厂商对自身客户群的视角，值得保持一定距离看待，但它也解释了为什么研究人员将网关配置错误视为云层面的问题，而非应用层面的问题。

主密钥既是管理员凭据，也是开启身份验证的开关。

LiteLLM 的设计让同一个密钥承担两项职责。主密钥用于对管理请求进行身份验证，而且正是它的存在才使身份验证得以启用：如果没有主密钥，也没有 JWT 或 OAuth2 配置，代理就会以开放模式运行并接受所有请求。Wiz 使用 Anthropic 的 Claude Code 来检查该代码库，寻找那些接收用户可控输入并将其传入执行上下文的功能，而身份验证处理器就是它标记出的三个暴露面之一。

在 v1.82.0-stable 之前，第二个作业造成的后果比开放代理更严重。Wiz 发现，当未设置主密钥时，认证处理程序会将 PROXY_ADMIN 角色分配给每个传入请求，因此未经认证的调用者不仅会被放行，还会被作为管理员放行。报告中引用的拉取请求 #22095 将默认角色改为 INTERNAL_USER，并在护栏端点中加入了管理员检查。

对网关的管理访问权限并不是一种狭窄的权限。该实例持有它路由到的每个提供商的 API 密钥，这正是它成为 LLMjacking 目标的原因——在受害者的账单上运行模型工作负载。它能看见提示词和补全内容。它会向外连接 MCP 工具服务器，而在内部部署中，这些服务器很可能包括问题跟踪器、聊天、数据库和部署流水线。

Wiz 还演示了从该管理席位通向主机云身份的路径。LiteLLM 允许管理员注册一条指向任意目标 URL 的透传路由，而目标不会针对私有地址范围、localhost 或云元数据地址进行检查。将路由指向实例元数据服务，会返回该工作负载运行时所用的 IAM 凭据。将元数据服务切换为 IMDSv2 也无济于事——IMDSv2 通常通过要求单独获取会话令牌来抵御这类请求伪造：LiteLLM 会将任何以 x-pass- 为前缀的标头去掉前缀后转发到目标，因此令牌标头可以被夹带过去。Wiz 表示，在信任管理员的威胁模型下，该功能可以说是在按预期工作，因此它没有 CVE，也没有修复方案。

最后一段是演示，而不是实际观察到的攻击。The Hacker News 在 9 月 10 日报道该研究时称，没有任何来源报告有人针对真实部署实施过这种做法，并且这需要先获得管理员访问权限。Wiz 的表述也是如此：透传是一种设计属性，只有当管理员凭据是文档中的某个字符串时，它才会变成漏洞。

8.8 和 2.1 是从不同起点给同一条链打分

两个 CVE 包含了这些技术发现，而它们公布的评分之差几乎不可能更大。

CVE-2026-59822 是 MCP 身份验证绕过漏洞，LiteLLM 的公告将其评为高危，在 CVSS 4.0 下为 8.8，且无需权限、无需用户交互，也没有攻击要求。MCP 端点有自己的身份验证处理器，旨在接受 LiteLLM 密钥或发往上游工具服务器的 OAuth2 令牌。当令牌未通过 LiteLLM 的验证时，该处理器捕获了 401，并用空身份验证对象替代，而不是拒绝请求。因此，任何 Bearer 令牌都能生成有效的 MCP 会话，包括单个字符：Wiz 的概念验证发送一个单字母的 bearer 令牌，并收到返回的会话标识符。该漏洞已在 1.84.0 中修复。

CVE-2026-59821 是护栏功能中的缺陷，同一项目的安全公告将其评为“低危”，评分为 2.1，且要求高权限并存在攻击要求。自定义代码护栏功能允许管理员提交由服务器编译并执行的 Python 代码。Web UI 的测试端点会依据禁止模式列表校验代码，并在运行前剥离内置函数（builtins）；而生产环境的创建和更新端点则两者都没做。当内置函数缺失时，Python 会重新填充它们，因此提交的代码能够触及标准库。Wiz 的概念验证注册了一个护栏，该护栏在注册时——即任何模型请求之前——就执行 shell 命令，并将命令输出作为拦截原因返回；在其测试中，该输出以 root 身份返回。该漏洞已在 v1.82.0-stable 中修复。

这两种描述是兼容的，而调和它们的那句话就在公告本身之中：LiteLLM 指出，在未配置主密钥的部署中，调用方可能被视为代理管理员，这正是让护栏端点变得可触及的原因。2.1 假定的是特权用户。Wiz 的链路描述的则是当默认密钥使每个调用方都成为特权用户时会发生什么。两个评分对于各自的起始前提都没有错；它们的分歧在于这一前提有多常是无需额外条件即可成立的。

Wiz 的说法——在 1.82.0 之后，持有默认密钥的攻击者只能在沙箱内执行代码——有一个需要注意的地方。Hacker News 指出了一份单独的 2026 年 5 月公告，CVE-2026-40217，其中描述了在 1.81.8 起至 1.83.10（不含 1.83.10）的版本中，通过字节码技术逃逸该沙箱的情况，且发生在一个代理进程内；该公告称该进程在默认容器镜像中以 root 身份运行。要触达该端点需要代理管理员凭据，而主密钥正是这种凭据。

8.8 也并非通用。云安全联盟的研究说明指出，GitLab 的安全公告为同一漏洞列出了 8.2 的基础评分，并拒绝对这两种评分方法作出裁定，只指出两者都处于高评分区间。该记录中“高”的严重等级并不取决于使用哪个数字。

一个 CVE 已在野遭利用；默认密钥暴露事件尚无具名受害者

CISA 于 2026 年 9 月 2 日将 CVE-2026-59822 加入已知被利用漏洞目录，并为联邦文职机构设定了 2026 年 9 月 16 日的整改截止日期；该目录条目包含 CWE-287 和 CWE-306，即身份验证不当和缺少身份验证。云安全联盟的说明指出，行业追踪机构将其描述为该清单上首个 MCP 特有漏洞。Wiz 已公布其观察到的利用情况：自 2026 年 7 月 7 日起，其蜜罐记录到携带单字符 Bearer 令牌的请求探测模型列表端点，Wiz 未描述该漏洞的其他利用方式。

默认密钥不存在可与之相比的情况。没有点名任何受害者，没有认定任何网关是通过 sk-1234 被接管的，也没有遥测数据显示这 294 台主机正在被使用。该归档条目没有记录任何实际危害，这一说法关乎证据而非机制：暴露情况是被测量出来的，而不是被目睹正在被使用。

另外两项常与这些一并归档，但它们并不是同一回事。CVE-2026-42271——通过两个 MCP 测试端点执行命令——是攻击者实际用来运行代码的 LiteLLM 漏洞；Wiz 的蜜罐记录到它安装了加密货币挖矿程序。微软公布的 2026 年 8 月案例中，入侵者读取了网关容器的环境变量，恢复了主密钥、提供商密钥和数据库连接字符串，然后从 LiteLLM 的模型表和虚拟密钥表中复制记录；该案例说明的是被攻陷网关的价值，而不是一条新的入侵途径；据 The Hacker News 报道，微软评估该入口点为 CVE-2026-42271 攻击链。

维护者的立场是，缺少主密钥属于设置错误，而不是漏洞。

LiteLLM 的安全策略对此有明确说明。它将“需要错误配置环境才能实施的攻击（例如未在代理配置中设置 master_key）”列为范围之外的问题，并声明这些问题明确不在范围内，不被视为存在漏洞。Wiz 则从另一个角度得出了与之相符的结论，称这种透传行为可以说是按预期工作的。

这一说法已在公开场合得到检验。2026年8月15日，一名研究人员提交了GitHub issue #37054，报告称在未设置LITELLM_MASTER_KEY的情况下，代理会接受任意密钥值进行认证，而随附的docker-compose文件并未设置该变量。该issue在30分钟后被关闭，其下唯一的评论来自同一账号：评论引用了安全政策中关于报告应通过非公开漏洞报告渠道而非公开issue提交的说明，为公开提交报告致歉，并表示完整报告正改为通过安全公告渠道提交。该讨论串中没有出现维护者的回复，因此记录显示的是报告者撤回了公开报告，而非项目方对此作出回应。没有任何公开记录说明那次非公开提交后来如何处理。

本文未找到 BerriAI 就九月份报告中的那一立场进行辩护或修订的公开声明。该公司可见的回应体现在其发布说明和配置文件中，而非以文字论述的形式呈现。

执法行动于10月3日到来，距报告发布已过去二十四天。

两个代码缺陷在报告发布很久之前就已被修复。Wiz 的披露时间线记录如下：护栏代码执行问题于 2026 年 2 月 18 日报告，并于 2 月 25 日在 v1.82.0 中修复；MCP 绕过于 4 月 25 日在 v1.84.0 中修复；7 月 7 日观察到利用；CVE 标识于 7 月 8 日发布；9 月 2 日列入目录。发布制品所带日期晚于修复日期：包索引显示 v1.82.0 为 2026 年 3 月 1 日，v1.84.0 为 5 月 14 日，这些日期标记的是每项修复何时变得可安装，而不是何时落地。两份第一方发布记录将同样的修复标注得比该时间线更晚。GitHub 上的 v1.82.0-stable 发布标注为 2026 年 3 月 11 日，PyPI 上的 1.82.0 包标注为 3 月 1 日；v1.84.0 在两处均标注为 2026 年 5 月 14 日。没有任何已发布内容解释这一差异，而这对论证并不重要，因为这些日期中的每一个都早于 9 月报告数月。两份 GitHub 安全公告还给出了第三个日期：它们发布于 2026 年 6 月 30 日，比 Wiz 所称于 7 月 8 日发出的 CVE 标识早三周。

那些发布版本都没有修复的是默认值问题。Wiz 报告称，截至 9 月 9 日，通过 Docker Compose 或 pip install 安装 LiteLLM 时，主密钥仍被设置为 sk-1234，而 The Hacker News 当天也确认安装指南仍在使用该值。这一变更随 v1.104.0 到来，该版本于 2026 年 10 月 3 日上传至 Python Package Index，其发布说明将其列为破坏性变更：代理现在会在主密钥未设置、为空或为公开已知值时拒绝启动，并在启动错误中指明错误值的来源，同时打印一条可生成安全密钥的命令。配套条目记录了一项变更，即停止在随附配置和示例中宣传一个公开已知的弱主密钥值，并且项目主分支上的 docker-compose 文件已完全不再设置密钥。

值得保留的就是这个顺序。代码在春季打了补丁。那个使这些补丁不够充分的值一直留在安装说明中，直到十月，软件才开始拒绝它。两项修复中没有任何一项需要另一项等待。

一直未改变的是通往实例元数据服务的直通路径。它仍然既没有 CVE，也没有修复方案，因为该项目将管理员视为可信。因此，Wiz 的修复清单主要是运维人员的工作：使用强且唯一的主密钥；审查已注册的防护栏，随后重启进程以清除内存中保留的代码；审计直通端点并限制容器出站流量；以及采用最小权限的 IAM 角色。这四项中没有一项能仅靠升级实现。

记录未能确立的内容

• 未找到对该 3,074 台主机扫描的独立复现。9.6% 是 Wiz 的测量结果，其他所有相关记述都只是以转述方式重复这一数字。

• 目前尚无最新的暴露数量数据。8 月的后续调查发现了超过 85,000 个实例，Wiz 表示其中大多是蜜罐或测试部署，无法与 2 月的统计数字相提并论。

• 没有受害者。记录中没有任何内容指出有网关、运营者或云账户是通过默认密钥被入侵的，而 Wiz 记录的利用行为针对的是 MCP 绕过，而非 sk-1234。

• 没有证据表明这 {{1}}294 台主机{{/1}}曾被使用。该扫描测试的是它们是否会通过身份验证，这比证明确实有人使用过它们的说法更弱。

• 该护栏缺陷的严重性尚无定论。Wiz 与维护者对同一行为的描述一致，但评级差异很大，而这一差异取决于各自假设攻击者已持有的权限。

Wiz 也是一家云安全厂商，销售针对此类暴露的检测能力；报告最后一部分介绍了其自家产品如何识别 LiteLLM 部署、易受攻击版本和影子实例。这是阅读修复章节的背景信息，而不是贬低某项测量结果的理由——该测量结果的技术细节已得到维护者自身公告的佐证。

记录中流传到 LiteLLM 之外的部分，是两个日期之间的间隔。该漏洞在春季已被修复。那个让漏洞对陌生人变得重要的默认值，直到九月仍被印在安装说明中，而软件直到十月才开始拒绝它。那些更改了字符串的运维人员从来不必等待这一切。