CISA 在 2026 年 6 月 8 日將 CVE-2026-42271 加入其 Known Exploited Vulnerabilities 目錄,確認了野外的活躍利用,並給聯邦民事機構到 6 月 22 日的修復期限。該漏洞是 LiteLLM 中的一個命令注入缺陷,LiteLLM 是 BerryAI 的開源項目,為團隊提供在數十個 model providers 前面的單一 OpenAI 格式接口,部署為 Python SDK 或者,這裡更相關地,作為管理 API keys、成本追蹤和流量路由的 standalone AI gateway 和 proxy。如果你在生產中運行一個 LLM proxy,它是 LiteLLM 的可能性很大,這正是為什麼這個漏洞比其 CVSS 行單獨所暗示的更重要。
該機制是具體的,值得理解。兩個 endpoints,POST /mcp-rest/test/connection 和 POST /mcp-rest/test/tools/list,接受完整的伺服器配置,然後以 proxy 進程本身的權限將提供的命令作為 subprocesses 生成,沒有對 input 進行適當的清理。那是教科書式的命令注入:本應描述要測試的 MCP 伺服器的 input 反而成為 host 執行的命令。初始訪問名義上需要一個 valid proxy API key,這聽起來像一個重要的障礙,直到你讀到後半部分:該要求可以通過 CVE-2026-48710 完全繞過,這是 Starlette(下層的 ASGI 框架)中的一個 BadHost authentication bypass,它將一個 authenticated-only 的 bug 轉變為對任何未同時修復 Starlette 的部署來說是 unauthenticated 的。修復落在 LiteLLM v1.83.7 中,它既清理了 endpoints,又添加了一個授權控制,將 MCP test endpoints 限制為持有 PROXY_ADMIN 角色的 users。
這超出常規 CVE 的原因是 LiteLLM 在 stack 中的位置。proxy 是按設計持有你通過它路由的每個 model provider 的 credentials 的唯一 component:你的 OpenAI key、你的 Anthropic key、你的 cloud-inference keys,以及通常 proxy 連接到的任何其他東西的 secrets。因此在該 host 上的命令執行不是一個被包含的事件,它是對你 AI 基礎設施中最集中的 credentials 堆的立即訪問,加上一個橫向移動到那些 credentials 觸及的一切的立足點。help-net 的報道對影響鏈很直白:任意命令執行、model-provider credentials 和 secrets 的盜竊,以及橫向移動到連接的 AI 系統。背景使其更糟,這是在 2026 年 5 月的一個事件之後單月內第二個被武器化的 LiteLLM 漏洞,BerryAI 還遭受了 2026 年 3 月通過惡意 PyPI 包的供應鏈攻擊。gateway 層正在被積極探測,攻擊者已經注意到那是 keys 所在的地方。
週一早上,如果你自託管 LiteLLM,這些行動並不微妙,也不是可選的。首先,今天升級到 v1.83.7 或更高版本,這是真正關閉漏洞的那個。其次,如果你不能立即升級,在你的 reverse proxy 或 load balancer 處阻止對 /mcp-rest/test/connection 和 /mcp-rest/test/tools/list endpoints 的網絡訪問作為臨時措施。第三,rotate proxy 接觸過的每個 credential,假設如果你被暴露了,你應該將 keys 視為已洩露,provider keys、connector secrets、proxy environment 中的任何東西。第四,將 proxy 的網絡暴露限制到可信網段,而不是讓 admin 和 test surfaces 可從開放互聯網到達,那是將這從糟糕的一天變成 breach 的配置。也要修復 Starlette,因為 CVE-2026-48710 是移除 API-key 前提的東西,一個依賴於攻擊者沒有 bypass 的防御不是防御。如果你追蹤更廣泛的 agent-security 線索,這是 research 中一直在構建的警告的具體版本,gateway 和 runtime 層越成為關鍵基礎設施,它們就越成為目標,LLM proxy 現在明顯處於前線。