近一成暴露在網際網路的 LiteLLM 閘道，接受設定指南裡的範例金鑰 sk-1234
近一成對網際網路暴露的 LiteLLM 閘道，會直接接受設定指南裡的範例金鑰 sk-1234。這把金鑰一旦到手，就能牽出儲存在後方的每一把模型提供者 API 金鑰，以及閘道背後那組雲端憑證。以下是 Wiz 查出的結果、四個 CVE，以及你今天該在自己的閘道上檢查的事。
如果你用 LiteLLM proxy 來串 AI——把這個開源閘道架在模型提供者和你的應用程式之間的那一層——現在有一件安全事該今天就看。而且它不是那種沒人利用得了的零日漏洞，而是預設金鑰就藏在專案自己的設定指南裡。
Wiz 的安全研究人員掃了網際網路上的 LiteLLM 閘道，拿 LiteLLM 官方設定文件裡的那把範例管理員金鑰 sk-1234 去試。The Hacker News 報導了結果，Wiz 的原始研究 也確認了數字：在 3,074 台暴露在網際網路上的閘道裡，有 294 台——近一成——接受這把金鑰。其中 191 台根本沒設任何金鑰，所以放什麼進去都收。
查出了什麼
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+ 的八月數字是另一次、不可直接比較的掃描（多為蜜罐／測試）。
為什麼一把金鑰這麼要命
主金鑰同時擔兩個角色，這正是預設值危險的地方。它既是管理員金鑰，也是讓鑑權生效的那個開關。在 1.82.0-stable 之前，一台沒設主金鑰就啟動的閘道，會把每一個進來的請求都當成擁有完整管理員權限。
這些機器上的管理員，能碰到的東西比多數人想像的多。一台閘道通常握著：
- 它串接的每個提供者的 API 金鑰——OpenAI、Anthropic、Google，還有別的。
- 經過它的所有 prompt 與回覆，明文。
- 透過 MCP（Model Context Protocol） 連到操作者接上去的內部工具。
- 它所部署的那組雲端權限——因為它就是帶著那組權限上線的。
光是偷到提供者的金鑰，攻擊者就能記在受害者的帳單上跑模型——這種濫用早就有個名字：LLMjacking。
一把金鑰怎麼摸到你的雲端帳號
這一段，是把一個糟糕預設值變成一起真正事故的關鍵。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 管理員金鑰。而主金鑰正是那把金鑰。
現在該做什麼
如果你跑 LiteLLM 閘道，照這個清單往下走。前兩項根本不需要換版本。
- 把主金鑰 從
sk-1234換成一串長隨機值。這一步最有價值，而且不用升級。換之前，先確認有沒有另外設過 salt 金鑰——兩者的輪換程序不一樣，用錯那一把可能讓已儲存的憑證讀不出來。 - 升到 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 清單裡有沒有不是你建出來的項，重啟程序清掉記憶體裡留著的程式碼，再輪換提供者金鑰、主金鑰、資料庫憑證。升級既不會移除攻擊者登記過的 guardrail，也不會移除他加上的 SSH 金鑰。
一個誠實的空白：對直通路由摸到執行個體中繼資料這條路，沒有補丁，因為 LiteLLM 不把它當漏洞。外連限制和最小 IAM 角色，是這條路唯一能用的控制。而且目前沒有任何來源，教你怎麼檢查一台你接手過來的閘道上 MCP 或直通路由有沒有開——流傳在外的偵測查詢（包括微軟那套）找的是被利用的跡象，不是設定。
更大的教訓：閘道已經是你的邊界
這件事，說到底不是關於 sk-1234。它是關於你的 AI 信任邊界搬到哪裡去了。
過去幾年，模型提供者那邊才是邊界——你把 prompt 和金鑰交給它。現在，在你的應用程式和那些提供者之間，多了一台你自己的閘道：一個攬下所有提供者金鑰、看盡所有流量、帶著所跑 workload 那組雲端權限、還能經 MCP 路由到內部工具的元件。它是一個憑證匯聚點，多數團隊的網路根本沒為它設計過。
對任何跑 AI stack 的團隊，實際的啟示是：
- 盤點每一台 架在模型提供者前面的閘道——包括前一任團隊或廠商建好、再沒動過的。
- 確認它實際跑的是哪把管理員金鑰。 一台對
sk-1234應聲的機器，在安全意義上就等於沒鑑權。 - 假設它攬的那座金鑰庫，敏感度等同任何一台密鑰管理器，照那個標準去防：強而獨特的金鑰、最小 IAM、限制外連、加上補丁節奏。
結論
預設範例金鑰，是真實事故最便宜、也最常見的起點。LiteLLM 不是個壞專案——它又大又普及，也對發現的漏洞有回應。但這裡的規律值得刻進心裡：你的 AI 閘道越居中，它攬下的每把憑證、每組雲端權限，就越成為單點失陷。
如果你不想自己扛這個匯聚點，那正是我們幫人做的事。
外部參考
- Wiz — Breaking LiteLLM: From Auth Bypass to Cloud Compromise — 原始研究：
sk-1234掃描、直通摸到 IMDS 的路徑、以及四個 CVE（2026）。 - The Hacker News — 近一成暴露的 LiteLLM 閘道接受範例金鑰 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 直通行為。
