2026 年 6 月 8 日，CISA 将 LiteLLM 的命令注入漏洞 CVE-2026-42271 列入已知被利用漏洞目录。安全研究者还验证了它与 Starlette 另一个漏洞的组合：在受影响的部署中，能够访问代理服务的攻击者无需 API 密钥，就可能执行服务器命令。
LiteLLM 为应用提供统一的模型调用接口，也是 CrewAI、DSPy、Microsoft GraphRAG 等项目曾使用的依赖。企业常用其代理服务集中管理模型访问、费用和密钥。一旦代理进程被控制，攻击者可能获得它可读取的模型凭据，并查看或篡改经由网关传递的内容。
这起事件值得关注的地方，是网关承担的权限：一个组件同时连接多个模型和内部系统，漏洞的影响可能沿着这些连接扩散。
两个漏洞结合，可绕过认证并执行服务器命令
LiteLLM 是 BerriAI 维护的开源 Python 库，也可作为代理服务器部署。它提供统一的 OpenAI 兼容接口，连接 OpenAI、Anthropic、Google Vertex AI、Azure、Cohere 等服务。企业可以在这一层路由请求、控制访问与预算，并记录使用情况。
问题出在 LiteLLM 为支持 Model Context Protocol（MCP）而引入的两个测试端点：POST /mcp-rest/test/connection 和 POST /mcp-rest/test/tools/list。
这两个端点用于在保存 MCP 服务器配置前测试连接。对于 stdio 配置，服务需要启动本地子进程。根据维护方安全公告，受影响版本只检查调用者是否持有有效的代理 API 密钥，没有进一步核验管理员角色，因此低权限用户也能让代理执行所提交的命令。
CVE-2026-42271 单独利用需要有效密钥，维护方给出的 CVSS 评分为 8.7，影响 LiteLLM 1.74.2 至 1.83.6。Horizon3.ai 随后验证，将它与 Starlette 的 CVE-2026-48710（BadHost）结合，可以绕过这一认证前提。
Starlette 是 LiteLLM 所用 Web 框架的一部分。BadHost 涉及 HTTP Host 头处理：受影响版本重建 URL 时，可能产生一个与实际路由不同的路径。如果应用用重建后的路径决定是否检查身份，就可能把受保护的请求误认为公开请求。是否能被利用，还取决于应用的认证实现和前置代理是否拦截异常请求。
在研究者验证的受影响配置中，身份检查被绕过后，请求仍能到达 MCP 测试端点，最终以 LiteLLM 代理进程的权限执行命令。Horizon3.ai 将组合攻击链评为 CVSS 10.0。这里的执行权限由进程和部署配置决定，不能一概视为宿主机 root 权限。
Obsidian Security 在 6 月 11 日披露了另一组问题：CVE-2026-47101 允许低权限用户扩大密钥可访问的路由；CVE-2026-47102 缺少对用户角色字段的授权检查；CVE-2026-40217 则涉及自定义代码护栏的沙箱缺陷。研究者将组合链评为 CVSS 9.9，演示了从普通内部用户到代理管理员、再到代码执行的过程。“默认内部用户”指一种普通用户角色，并不意味着每个部署都有一个攻击者可直接登录的默认账户。
网关集中保存密钥，失守后可能影响多个 AI 服务
评估影响范围时，需要从代理能访问的数据和服务入手。
在集中式部署中，LiteLLM 可能保存多个模型提供商的 API 密钥、数据库连接信息，以及团队和用户权限配置。它还可能连接 Agent、检索增强生成管道或其他内部服务。具体暴露范围由这些凭据的权限、存放方式与网络可达范围决定。
代理被控制后，需要重点检查以下几类影响：
- 模型服务密钥与对话内容：被读取的密钥可能被滥用，产生额外费用；流经代理的提示和回复也可能遭到读取或修改。
- 环境变量和凭据文件：检查代理进程能接触到的容器环境变量、挂载文件，以及其中的 SSH 或云服务凭据。
- 数据库：攻击者可能使用代理持有的数据库账户读取记录，范围取决于账户权限；数据库中加密保存的密钥，也需连同解密材料一起评估。
- 内部系统与集群权限：如果 Kubernetes Service Account 授权过宽，失守容器可能进一步访问其他集群资源。网络隔离和最小权限可以限制这类扩散。
Horizon3.ai 建议检查异常的子进程、MCP 测试端点请求及 Host 头活动。Obsidian 的研究还提醒，排查范围应包括自定义护栏、配置中的回调和部署代码完整性：这些位置的修改可能持续影响后续请求，且不一定全部显示在管理界面中。
Cloud Security Alliance 的分析强调了密钥集中的风险。统一网关便于管理，也使其成为值得重点保护的组件；减少长期凭据、限制账户权限，并分开管理接口与业务接口，有助于降低单点失守的影响。
CISA 确认漏洞被利用，企业还需排查早前恶意软件包
维护方已在 LiteLLM 1.83.7 中将这两个 MCP 测试端点限制为 PROXY_ADMIN 角色。Starlette 的 BadHost 修复版本为 1.0.1，部署者需要同时核对代理和实际安装的依赖版本。
6 月 8 日，CISA 将 CVE-2026-42271 纳入已知被利用漏洞（KEV）目录，条目所列修复截止日期为 6 月 22 日。这一记录确认漏洞已在现实攻击中被利用，应成为受影响组织安排修复优先级的依据。
KEV 修复期限对相关美国联邦机构具有约束力，其他组织也可据此调整漏洞处理顺序。列入目录不代表每个部署都已失守，但仅凭服务仍在正常运行，也无法排除凭据或数据已经暴露。
此前在 2026 年 3 月，LiteLLM 还发生过一次独立的供应链事件。维护方称，攻击者利用疑似来自 Trivy 安全扫描工作流的凭据泄露，在 PyPI 发布了恶意版本 1.82.7 和 1.82.8。这两个版本于 3 月 24 日上线约 40 分钟后被隔离。安装了相关软件包的环境，需要另行检查凭据窃取、持久化和 Kubernetes 横向访问痕迹；使用 LiteLLM 的上层框架是否受影响，要核对当时实际解析和安装的版本。
Datadog Security Labs 将软件包投毒与 TeamPCP 的更大规模供应链活动联系起来，其中还涉及 Trivy、Checkmarx KICS、npm 包和 OpenVSX 扩展。投毒与这次代理漏洞是不同入口，处理其中一个问题，不能代替对另一个问题的排查。
同类网关需检查权限控制和底层 Web 依赖
这些事件提示，AI 应用的安全审查应覆盖模型之外的组件：网关、Web 框架、发布流程和管理接口都可能接触敏感信息。模型本身表现正常，并不能说明传递请求和执行工具的系统可靠。
从已披露问题来看，需要检查的都是具体工程环节：普通用户能否触发管理功能，修改自身资料时能否一并改动权限字段，执行自定义代码时是否真正隔离了运行环境。项目的下载量和社区热度有助于衡量使用范围，却不能代替这些检查。
Cloud Security Alliance 在分析中建议，为 AI 中间件明确安全负责人、补丁管理义务和审查要求。对于集中处理请求和凭据的网关，权限管理应覆盖路由和接口内部的具体动作，而不只是在入口确认“持有一把有效密钥”。
Starlette BadHost 的影响也需要在 LiteLLM 之外排查。OSTIF 和比利时网络安全中心提醒，FastAPI 服务、推理服务器、MCP 框架和 Agent 运行环境可能包含相关依赖。检查重点是版本，以及是否通过 request.url.path 等重建值作安全判断；不能只因项目使用 Starlette，就认定所有认证都会被绕过。
这与早年 Heartbleed 事件有一个可比较的地方：广泛使用的底层依赖出问题时，多个上层产品都需要盘点和更新。两起事件的机制与规模不同，对部署团队来说，共同的实际要求是知道自己用了哪些组件、谁负责维护，以及修复如何到达生产环境。
升级之外，还要检查入侵痕迹和凭据暴露
对于文中涉及的漏洞，Obsidian 推荐 LiteLLM v1.83.14-stable 或更高版本，Horizon3.ai 同时要求 Starlette 至少为 1.0.1。这些是相应公告给出的修复版本，并非对所有后续漏洞的保证。升级时应核对当前安全公告及部署制品中的依赖；若怀疑曾被入侵，还需轮换代理可访问的模型密钥、数据库凭据与其他受影响凭据。
暂时无法升级时，可在反向代理或网关处阻断受影响测试接口，并将 LiteLLM 的网络访问限制到确实需要它的服务。还应审计 API 密钥分发情况，撤销闲置密钥。临时限制访问能减少暴露，但仍需安排正式修复和验证。
长期运维还需要明确责任：谁跟进上游公告，谁测试和发布升级，谁在事故后核对密钥、日志和账户权限。采购与部署评估也应关注供应商的安全开发、漏洞披露和响应流程，避免上线后没有团队持续接手。
LiteLLM 公布了安全改进安排，包括外部审计与漏洞赏金。其安全政策列出符合条件的高危、严重问题可获 500–3,000 美元奖励，并承诺在 5 个工作日内跟进报告。对于使用方，后续仍需检查修复内容和升级结果，不能只把计划公布视为风险已经消除。
密钥集中管理的便利，需要与相应的隔离和审计配套。限制代理进程权限、减少其可访问的内部系统，并对配置和代码变更保留记录，能够让一次入侵更容易被发现，也更难向其他业务扩散。
这类工作不会随着一次升级结束。把组件清单、修复责任和事故处置纳入日常运维，才能让安全公告真正转化为已部署的改进。
