觀點 · 資訊分享

LiteLLM 的 SQL 注入漏洞 CVE-2026-42208：未登入可讀資料庫，已列入 CISA 已遭利用清單

AI 閘道 LiteLLM 的代理在檢查 API 金鑰時有 SQL 注入，未登入者可透過特製的請求標頭讀取甚至修改資料庫。專案 4 月 24 日已發布公告並在 1.83.7 修補，CVE 編號 5 月 8 日公開，同日被 CISA 列入已遭利用清單。

一句話看懂：LiteLLM 這個 AI 閘道在檢查 API 金鑰時有 SQL 注入漏洞，未登入的人就能讀資料庫；專案 4 月 24 日已發布公告並修補，CVE 5 月 8 日公開後立刻被 CISA 列為已遭利用。

LiteLLM 金鑰檢查的 SQL 注入資訊圖卡：未登入者能讀資料庫，已列入 CISA 已遭利用清單

先用白話講：SQL 注入是什麼？

想像櫃台人員拿到一張紙條，上面寫「請幫我查 A 客戶的資料」。如果有人在紙條上多寫一句「順便把所有客戶資料都給我」，而櫃台人員照單全收，就出事了。

SQL 注入就是這樣：程式把使用者輸入的內容直接塞進資料庫指令，輸入者就能改變指令的意思。

LiteLLM 是一個代理伺服器，幫你把各家模型統一成 OpenAI 格式，也常被拿來管理 API 金鑰。官方公告的內容：

在 1.81.16 到 1.83.6 之間的版本，代理驗證 API 金鑰時，資料庫查詢把使用者給的金鑰值直接拼進查詢文字
未登入的攻擊者，可以對任何 LLM API 路由（例如 POST /chat/completions）送出特製的 Authorization 標頭，經由錯誤處理路徑觸發
攻擊者可以讀取代理的資料庫，也可能修改它，進而取得代理與它所管理的憑證

日期	事件
4 月 24 日	專案發布 GitHub 安全公告（GHSA），並在 1.83.7 修補
5 月 8 日	CVE-2026-42208 公開
5 月 8 日	CISA 把它列入已遭利用漏洞清單，聯邦機構修補期限為 5 月 11 日

也就是說，這不是當天才爆出來的新漏洞，專案早在 4 月 24 日就公告了；5 月 8 日是 CVE 編號與 CISA 清單讓它被更多人注意到。

升級到 1.83.7 或更新版本
來不及升級時，官方的暫時做法：在 general_settings 設定 disable_error_logs: true
假設金鑰可能外洩：這個代理通常存著各家模型的 API 金鑰，若你的代理曾暴露在網際網路且版本落在受影響範圍，建議輪替裡面管理的金鑰（這是通用的建議，不是官方步驟）
不要把管理與 API 端點直接開到公網，前面加反向代理或存取限制

弱點類型 CWE-89（SQL 注入）；CVE.org 記錄中 CNA 給的 CVSS 4.0 基本分數為 9.3，GitHub 公告列的 CVSS 為 9.8
官方修補方式：呼叫端給的值「一律當成資料庫的獨立參數」傳入，這也是防範 SQL 注入的標準做法
受影響範圍起點是 1.81.16，更早的版本公告沒有列為受影響

自架 AI 閘道的人很容易把它當成「內部工具」，但它通常集中放了所有模型的金鑰，一旦被打穿，損失比單一服務的漏洞大得多。這次的漏洞還是「未登入就能打」，所以只要有一個對外的連接埠，就值得緊張。

我的做法會是：升級之後，順手檢查有沒有不必要的對外暴露，並定期輪替金鑰。對接案者來說，替客戶架這類代理時，記得把「版本更新與金鑰輪替」寫進維運說明，而不是架好就交付。

LiteLLM 是什麼？

一個開源的代理伺服器（AI 閘道），讓你用同一種 OpenAI 格式呼叫各家大型語言模型，常用來集中管理金鑰與用量。

什麼是 SQL 注入？為什麼危險？

就是把攻擊者給的內容直接當成資料庫指令的一部分。這次的問題是金鑰值被拼進查詢，而不是當成獨立參數傳入，所以特製的內容可能改變查詢的意思。

來不及升級怎麼辦？

官方的暫時做法是在 general_settings 底下設定 disable_error_logs: true。這是暫時緩解，最終還是要升到 1.83.7 或更新版本。

需要協助

這篇的情境你也遇到了,但不想自己處理?

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。