4/19 才修，4/21 就被打 — LiteLLM 的 CVE-2026-42208，是 2026 年最乾淨的一堂應用安全課

LiteLLM 是現在最熱的開源「LLM 閘道」，22,000 多個團隊把它擺在 OpenAI、Anthropic、Google、AWS Bedrock 等 provider 前面，由它做認證、路由、限流、費用追蹤。也因為這樣，它握著你整個 AI 堆疊裡最值錢的祕密：虛擬 API key、上游 provider 的憑證、以及 proxy 的環境變數設定。2026 年 4 月 19 日，1.83.7-stable 修了 CVE-2026-42208；4 月 21 日 16:17 UTC — GitHub Advisory 被索引後約 36 小時 — Sysdig 的研究員捕捉到第一次野外利用。攻擊者不是丟個通用 sqlmap，而是一支「已經把 schema 背好」的客製化 enumeration，精準鎖定三張持有上述祕密的資料表。

一、Bug 的一句話描述

LiteLLM 用來驗證來電者 API key 的那條 SQL，把使用者送來的 Authorization 標頭值直接串接進 query 字串，而沒有用參數綁定。任何 LLM API 路由都能 pre-auth 觸發，因為錯誤處理路徑會在權限決策之前先做這次查詢。CVSS 9.3。

二、一個 bug，四根支柱同時倒下

這個 CVE 是個完美的教室範例：四個應用安全經典領域並不是獨立科目，而是只要有一個沒守住，就會在同一場事故裡一起倒下。

輸入驗證與注入防禦。修法就是教科書答案：參數化查詢。世界上沒有任何「淨化標頭」的招數能贏過 bind。Mago 的 SQL 字串 lint（見今天 PHP 那篇）能在 CI 抓到，Semgrep 或 CodeQL 跑五分鐘也能抓到。

身分驗證與授權。這次查詢跑在權限決策之前。結構上跟 router 的 path traversal 是同一個錯：你在「決定來電者能不能觸發這個副作用」之前，就已經把副作用觸發完了。Auth 檢查必須走最便宜的路徑，路徑上不能有任何吃使用者原始輸入的 DB 呼叫。

開源與第三方套件安全。LiteLLM 就是你的供應鏈。22,000 顆星不等於「安全」，等於「萬一出事爆炸半徑極大」。SBOM、自動化的 Advisory 掃描（GitHub Dependabot、Snyk、Renovate 加 vuln gate）、以及一張會即時告訴你「我們有哪些服務還跑在 1.83.7 之前的 LiteLLM」的曝險儀表板，都已經不再是選配。

CIA 核心概念。機密性失守：proxy 持有的每一支虛擬 key 與上游憑證都可以被讀；完整性失守：攻擊者可以寫同一個資料庫；可用性失守：只要旋轉或撤銷 key，就能把 proxy 對合法使用者鎖死。一個 bug，C/I/A 三個字母全中。

三、今晚就該跑的偵測

如果你跑任何 LiteLLM proxy：去 log 裡撈 Authorization 值包含單引號、註解符號（--、#、/*）、或布林永真式的請求；翻 DB 稽核日誌，找出過去六週內「從 API key 檢查程式路徑發出、針對 keys/credentials/env 三張表的 SELECT」。把 proxy 存過的所有虛擬 key、所有上游 provider 憑證全部旋轉一輪，就算稽核看起來乾淨也要 — 旋轉的成本是有限的，一支 OpenAI 計費 key 默默外洩的成本不是。

四、不只 LiteLLM 的模式

這個 bug 類別 — 「使用者輸入經由憑證檢查路徑進到 SQL」— 大概存在於 2023 年那波「快點寫個原型」生出來的所有 PHP/Node/Python 專案裡。請審你自己家的程式：任何在 authn 之前就會跑的 middleware 裡的 DB 查詢；任何字串內插進到 query builder 的地方；任何「只是為了 log」、卻吃了 raw header 的除錯查詢。「修補到被打」之間 36 小時，現在是中位數，不是最壞情況。

我的觀點

讓 CVE-2026-42208 成為 2026 年教科書的，不是這個 bug 本身，而是時間軸。以前公告會給防守方好幾週，現在我們在用「幾十個小時」當單位 — 對手是五位數星數的 repo，攻擊者進場時 schema 已經背完。這意味著的防守姿態並不舒服：對任何高價值開源依賴，請假設「公告 CVE」與「你正式環境正在被掃描這個 CVE」之間，只有一個工作天。這會改變你的變更管理方式。砍掉人工 CVE 分類；對已稽核過的依賴開啟自動合併安全 patch；上線時擋住 SBOM 太舊的構建；secret 按時間表旋轉，而不是被偵測到才旋。這禮拜原本就這樣做事的團隊聳肩不在意；其他人花了整個週末旋 key。