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 表示其自家八月的後續掃描無法與之相比。

這項量測很簡單，Wiz 也直截了當地說明其方法：2026 年 2 月透過 Shodan 找到 3,074 個對外開放的 LiteLLM 代理，並逐一測試它們是否會以文件中記載的範例金鑰進行驗證。其中 294 個會。在這群之中，有 191 個完全沒有設定主金鑰，會接受任何提供給它們的字串；其餘的則保留了設定指南中的預留位置。這兩種失效模式都不需要軟體漏洞。兩者都只需要閘道的位址，以及專案自身 README 中印出的那個值。

這同樣是單一廠商的掃描。{{1}}Wiz 的數字{{/1}}已被{{2}}Cloud Security Alliance 的 AI Safety Initiative{{/2}}於 9 月 10 日、以及 The Hacker News 於同日重複引用，但兩者都是註明出處地轉述，且本文未找到對 3,074 這個數字的獨立複現。Wiz 於 2026 年 8 月進行了第二次掃描，發現超過 85,000 個執行個體，約為 2 月計數的二十七倍。該公司表示，其中大多數似乎是蜜罐或測試部署，且這兩個計數無法相比。目前沒有最新的曝險數字；任何引用此類數字的文章，引用的都是 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，通常可藉由要求另行取得的工作階段權杖來防範這類請求偽造，但這麼做並沒有幫助：LiteLLM 會將任何標頭——其前綴為x-pass-——轉送到目標，並移除前綴，因此權杖標頭可以被偷渡過去。Wiz 表示，在信任管理員的威脅模型下，這項功能可說是在按預期運作，因此不帶有 CVE，也沒有修正程式。

最後一段是示範，並非實際觀察到的攻擊。Hacker News 於9月10日報導該研究時指出，沒有任何消息來源報導有人對真實部署執行此攻擊，而且它必須先取得管理員權限。Wiz 的表述也是如此：該直通機制是一項設計特性，唯有當管理員憑證是文件中的字串時，才會成為漏洞。

8.8 與 2.1 是從不同起點為同一條鏈評分

有兩個 CVE 承載了這些技術發現，而它們公布的評分幾乎天差地遠。

CVE-2026-59822 是 MCP 驗證繞過漏洞，LiteLLM 的公告將其評為 High，在 CVSS 4.0 下為 8.8，且無需任何權限、無需使用者互動，也沒有任何攻擊要求。MCP 端點有其專屬的驗證處理常式，設計上可接受 LiteLLM 金鑰或指定給上游工具伺服器的 OAuth2 權杖。當權杖未通過 LiteLLM 的驗證時，該處理常式會攔截 401，並以空的驗證物件取而代之，而非拒絕請求。因此，任何 Bearer 權杖都能產生有效的 MCP 工作階段，包括單一字元：Wiz 的概念驗證傳送單一字母的 Bearer 權杖，並收到工作階段識別碼。此瑕疵已在 1.84.0 中修復。

CVE-2026-59821 是該護欄功能的缺陷，同一專案的公告將其評為 Low、2.1，且需要高權限並存在攻擊需求。自訂程式碼護欄功能可讓管理員提交 Python，伺服器會編譯並執行。Web UI 的測試端點在執行前會依據禁用模式清單驗證程式碼，並移除 builtins；正式環境的建立與更新端點則兩者皆未執行。Python 會在 builtins 不存在時重新填入，因此提交的程式碼得以觸及標準函式庫。Wiz 的概念驗證註冊了一個護欄，會在註冊時——任何模型請求之前——執行 shell 命令，並將命令輸出作為封鎖原因回傳；在其測試中，該輸出以 root 身分傳回。此缺陷已在 v1.82.0-stable 中修正。

這兩份描述彼此相容，而調和兩者的那句話就寫在公告本身：LiteLLM 指出，在未設定主金鑰的部署環境中，呼叫方可能被當成 proxy 管理員，這正是讓護欄端點得以觸及的原因。A 2.1 假設的是具備權限的使用者。Wiz 的攻擊鏈描述的則是預設金鑰讓每個呼叫方都取得權限時所發生的情況。兩項評分就其各自的起始前提而言都沒有錯；它們的分歧在於這個前提有多常是無需任何條件就能成立的。

Wiz 主張在 1.82.0 之後，持有預設金鑰的攻擊者只能執行沙箱內的程式碼，但這項說法有一項但書。The Hacker News 指出另一份 2026 年 5 月的公告 CVE-2026-40217，該公告描述在 1.81.8 起至 1.83.10（不含）之前的版本中，可透過位元組碼技術逃離該沙箱，且是在代理程序中進行；該公告稱此代理程序在預設容器映像中以 root 身分執行。要觸達該端點需要代理管理員憑證，而主金鑰正是此類憑證。

8.8 也並非通用。Cloud Security Alliance 的研究備忘錄指出，GitLab 的安全公告針對同一漏洞列出 8.2 的基礎分數，並拒絕對這兩種方法論作出裁斷，僅註明兩者都落在高風險範圍。該紀錄的「高」嚴重性並不取決於採用哪個數字。

有一個 CVE 已遭實際利用；預設金鑰暴露事件則沒有具名受害者

CISA 於 2026 年 9 月 2 日將 CVE-2026-59822 加入「已知遭利用漏洞」目錄，並為聯邦文職機構設定 2026 年 9 月 16 日的修補期限；該目錄條目帶有 CWE-287 與 CWE-306，即認證不當與缺少認證。雲端安全聯盟（Cloud Security Alliance）的說明指出，業界追蹤者將其描述為該清單上第一個 MCP 專屬漏洞。Wiz 已公布其觀察到的利用活動：自 2026 年 7 月 7 日起，其蜜罐記錄到攜帶單字元 Bearer 權杖、探測模型列表端點的請求，而 Wiz 未描述該漏洞的其他利用方式。

對於預設金鑰，並不存在任何可相比擬的情況。沒有指名任何受害者，沒有指認任何閘道是透過 sk-1234 被接管，也沒有任何遙測資料顯示這 294 台主機正被使用。該存檔條目並未記錄任何實際損害，這是在陳述證據，而非陳述機制：曝險是被量測到的，而不是被目擊到遭人使用。

另外有兩項經常與這些一起歸檔，但並非同一回事。CVE-2026-42271 是透過兩個 MCP 測試端點執行命令，這是攻擊者實際用來執行程式碼的 LiteLLM 漏洞；Wiz 的蜜罐記錄到它安裝加密貨幣挖礦程式。Microsoft 公布的 2026 年 8 月案例中，入侵者讀取閘道容器的環境變數，取得主金鑰、供應商金鑰與資料庫連線字串，接著從 LiteLLM 的模型表與虛擬金鑰表複製紀錄；這說明的是遭入侵閘道的價值，而非新的入侵途徑；The Hacker News 報導，Microsoft 將該進入點判定為 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 日觀察到利用行為；7 月 8 日公布 CVE 識別碼；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 日。已發布的內容沒有任何解釋能說明這個落差，而這對論點並不重要，因為上述每個日期都早於九月報告數個月。兩份 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 的測量結果，而其他所有對它的記述都只是註明出處地重複引用該數字。

• 目前沒有現行的暴露數量數據。八月的後續調查發現超過 85,000 個執行個體，Wiz 表示這些大多是蜜罐或測試部署，無法與二月的計數相比。

• 無受害者。紀錄中沒有任何內容指出有閘道、操作者或雲端帳戶是透過預設金鑰遭到入侵，而 Wiz 所記錄的漏洞利用是針對 MCP 繞過，而非 sk-1234。

• 沒有證據顯示這 294 台主機曾被使用。該掃描測試的是它們是否會通過驗證，這項主張比證明確實有人使用過它們來得薄弱。

• 對於這項護欄缺陷，尚未有定論的嚴重性。Wiz 與維護者描述相同的行為，卻給予截然不同的評級，而差異在於雙方各自假設攻擊者已握有哪些權限。

Wiz 同時也是一家雲端安全廠商，販售針對這類曝險的偵測服務，而報告最後以一節說明其自家產品如何識別 LiteLLM 部署、易受攻擊版本與影子執行個體。這是閱讀修補章節的背景脈絡，而非輕視某項量測結果的理由——該量測的技術細節已由維護者自身的公告佐證。

紀錄中會流傳到 LiteLLM 之外的部分，就是兩個日期之間的那段空白。這個漏洞在春天已被修補。那個讓漏洞對陌生人而言變得要緊的預設值，到了九月仍被印在安裝說明中，而軟體直到十月才開始拒絕它。改掉那個字串的操作人員，從來不必等待上述任何一件事。