跳到主要內容

LiteLLM漏洞評測：sk-1234預設金鑰洩露雲端存取權 | LiteLLM Review: sk-1234 Default Key Exposes Cloud Access

By Kit 小克 | AI Tool Observer | 2026-09-16

🇹🇼 LiteLLM漏洞評測：sk-1234預設金鑰洩露雲端存取權

如果你的 AI Agent 或 RAG 系統背後接的是 LiteLLM 這套開源 LLM 閘道，這篇一定要看：資安公司 Wiz Research 掃描了 3,074 台對外公開的 LiteLLM 伺服器，發現有將近一成、9.6%，還在用官方教學文件裡示範用的預設管理員金鑰 sk-1234，甚至完全沒設認證。這不是理論漏洞，是實際能被陌生人接管的資安缺口。

LiteLLM 是什麼？為什麼一堆 AI 團隊都在用它？

LiteLLM 是一套開源閘道，擋在你的應用程式和 OpenAI、Anthropic、Google 等各家 LLM 供應商中間，統一 API 格式、集中管理金鑰與用量。因為架設快、Docker 一鍵上線，很多團隊圖方便，也因此很容易忽略掉預設設定該改的地方。

sk-1234 漏洞是怎麼被發現的？

Wiz Research 在 2026 年 2 月掃描網路上公開的 LiteLLM 實例，發現 sk-1234（LiteLLM 官方安裝文件裡示範用的管理員金鑰）在近一成伺服器上完全沒被更換。這代表任何知道這組「公開的秘密」的人，都能直接拿到閘道的最高管理權限。

拿到 sk-1234 之後，駭客能做什麼？

  • 讀取閘道裡儲存的所有 LLM 供應商 API 金鑰（OpenAI、Anthropic、Google 等）
  • 看到經過閘道的每一筆 prompt 與回應內容，等於全公司 AI 對話紀錄外流
  • 透過 MCP（Model Context Protocol）連結，進一步碰觸內部工具與系統
  • 若伺服器版本低於 v1.82.0、同時中了 RCE 漏洞 CVE-2026-59821，一個帶著 sk-1234 的請求就能直接拿到容器 root 權限，進而摸到主機的雲端 IAM 憑證

LiteLLM 官方怎麼回應？爭議在哪？

比較尷尬的是，LiteLLM 官方的安全政策明白寫著：沒設定 Master Key 之類的「使用者設定錯誤」不在漏洞通報範圍內，不算安全漏洞。換句話說，官方立場是「你沒改預設值是你的問題」，但範例文件卻白紙黑字寫著 sk-1234，不少資安研究者認為這種切割方式並不公平。

正在用 LiteLLM，該怎麼檢查自己有沒有中鏢？

  • 立刻登入後台確認 Master Key 不是 sk-1234 或其他文件範例值
  • 把 LiteLLM 升級到 v1.82.0 以上，修掉 CVE-2026-59821 這個 RCE 漏洞
  • 不要把管理介面或 API 直接暴露在公網，至少加上 IP 白名單或 VPN
  • 假設金鑰已外流，直接輪替所有串接的 LLM 供應商 API 金鑰

LiteLLM 工具本身沒問題，問題出在「預設值太危險、風險又沒講清楚」。如果你的 Agent 或後端有串 LiteLLM，花五分鐘檢查絕對划算。好不好用，試了才知道。

🇺🇸 LiteLLM Review: sk-1234 Default Key Exposes Cloud Access

If your AI agent or RAG pipeline sits behind LiteLLM, the popular open-source LLM gateway, pay attention: security firm Wiz Research scanned 3,074 internet-facing LiteLLM instances and found that nearly one in ten — 9.6% — still accepted sk-1234, the example admin key printed right in LiteLLM's own setup docs, or required no authentication at all. This isn't a theoretical bug — it's an open door.

What is LiteLLM, and why do so many AI teams run it?

LiteLLM is an open-source gateway that sits between your app and providers like OpenAI, Anthropic, and Google, giving you one unified API, centralized key management, and usage tracking. It's fast to spin up with Docker, which also makes it easy to skip the boring parts, like changing the default admin key.

How was the sk-1234 issue discovered?

In February 2026, Wiz Research scanned public LiteLLM deployments and found that sk-1234, the exact admin key shown in LiteLLM's own installation guide, was still active on nearly 10% of exposed servers. Anyone who knows this "public secret" gets full admin access to the gateway.

What can attackers actually get with sk-1234?

  • Every provider API key stored on the gateway — OpenAI, Anthropic, Google, and more
  • A live feed of every prompt and response passing through the gateway
  • Access to internal tools connected via MCP (Model Context Protocol)
  • On unpatched instances (before v1.82.0) also hit by CVE-2026-59821, a single request with sk-1234 escalates straight to root on the container, and from there, the host's cloud IAM credentials

How did LiteLLM respond, and why is that controversial?

LiteLLM's published security policy explicitly excludes "setup mistakes," including never rotating the master key, from what counts as a vulnerability. That's an awkward stance given the exact value is baked into the official docs; critics argue it isn't fair to call it purely user error when the dangerous default came from the vendor itself.

Running LiteLLM? Here's how to check if you're exposed

  • Log in and confirm your Master Key is not sk-1234 or any other documented example value
  • Upgrade to v1.82.0 or later to patch CVE-2026-59821
  • Never expose the admin API or dashboard directly to the public internet; add an IP allowlist or put it behind a VPN
  • Assume the key is already leaked and rotate every downstream LLM provider API key

LiteLLM itself is a solid tool — the problem is a dangerous default that wasn't flagged clearly enough. If your stack touches LiteLLM, spend five minutes checking. 好不好用，試了才知道 — you only know it's safe once you've actually checked.

Sources / 資料來源

常見問題 FAQ

LiteLLM 的 sk-1234 是什麼？

sk-1234 是 LiteLLM 官方文件範例中示範用的預設管理員金鑰，若安裝後沒手動更改，任何人都能用它取得閘道最高權限。

這個漏洞會不會影響我的 AI Agent？

只要你的 LiteLLM 閘道對外開放且沒改預設金鑰，就有風險，尤其是還串接 MCP 工具或雲端 IAM 身分的環境風險更高。

LiteLLM 官方認定這是漏洞嗎？

LiteLLM 官方安全政策把「忘記設定管理金鑰」列為使用者設定錯誤，不算通報範圍內的漏洞，這點在資安社群引發不小爭議。

該怎麼快速自保？

立刻更換 Master Key、把 LiteLLM 升級到 v1.82.0 以上修掉 CVE-2026-59821、並確認閘道沒有直接暴露在公網。

LiteLLM 還安全嗎，值得繼續用嗎？

工具本身沒問題，問題出在預設值太危險又沒有明確標示；只要照清單做好基本資安設定，仍是好用的 LLM 閘道。

延伸閱讀 / Related Articles

AI 工具觀察站 — 每日精選 AI Agent 與工具趨勢
AI Tool Observer — Daily curated AI Agent & tool trends

留言

張貼留言