2026 年 4 月 23 日，LMDeploy（一套開源的大型語言模型壓縮、部署、推論工具）的維護者公布 GitHub 安全公告 CVE-2026-33626。漏洞是視覺語言模組 load_image() 函式的 Server-Side Request Forgery（SSRF）：模型伺服器會去抓取任意 URL，而沒有驗證該 URL 是否指向內網或私有 IP。CVSS 7.5。受影響範圍：所有支援視覺語言、直到 0.12.0 為止的版本。
12 小時 31 分鐘後，Sysdig 的蜜罐捕捉到第一次真實的利用嘗試。公告發布 13 小時內，真實攻擊者已經在野外針對真實目標執行漏洞利用。當亞洲與歐洲多數安全團隊還在開晨會時，這個漏洞已經被武器化了。
為什麼這次比一般 SSRF 嚴重得多
普通 Web Server 上的 SSRF 是煩人。視覺語言模型推論節點上的 SSRF 是潛在災難。三個理由。
第一，這些服務跑在哪裡。LMDeploy 節點通常跑在雲端的 GPU 實例上。這些實例通常綁定權限相當寬鬆的 IAM Role，可以存取 S3、KMS、內部 API，以及雲端的 Instance Metadata Service（IMDS）。一次成功的 IMDS 抓取，可能就足以讓攻擊者拿到臨時憑證，進而拿下整個雲端帳戶。
第二，這個 SSRF 怎麼觸發。攻擊者只需要送一個視覺語言推論請求，URL 指向某個內網目標。影像載入器盡責地把它抓下來。沒有花俏的攻擊鏈，沒有記憶體錯誤利用。它就是模型伺服器在做它原本被設計做的事——載入一張圖片——只是這張「圖片」剛好是 http://169.254.169.254/latest/meta-data/iam/security-credentials/。
第三，攻擊者的操作軌跡。Sysdig 從單一場 8 分鐘觀測對話中看到，攻擊者把這個 SSRF 當作通用 HTTP 探針掃描內網：AWS IMDS、Redis、MySQL、內部管理介面 HTTP、以及一個用於外帶資料的 DNS exfiltration 端點。請求在 internlm-xcomposer2、OpenGVLab/InternVL2-8B 等視覺語言模型之間輪換以規避簡單偵測。這不是好奇的研究員。這是成熟的工具。
它揭示了 AI 供應鏈的什麼問題
CVE-2026-33626 是第一個公開、真實世界的資料點，證實 AI 推論層現在已經被當成其他任何對外服務一樣對待：被掃描、被指紋識別、在揭露後幾小時內被利用。
2024-2025 年大多數時候，AI 安全話題被 Prompt Injection、Jailbreak、訓練資料投毒主導。但真實攻擊者目前並不在乎這些。他們在乎的還是老問題：一個跑在高權限主機上、未經驗證的 HTTP 抓取器。LMDeploy 提供了這樣一個。在這次揭露之後被審查的其他多個推論框架（Triton 的 Python 後端、vLLM 的批次端點、0.6 以前的 Ollama）也提供了類似的東西。
冷酷的推論是：2026 年的 AI 推論層，看起來很像 2014 年的 WordPress 外掛生態系——出貨速度快、多由 ML 研究員而非資安工程師寫、影像抓取器與樣板引擎的設計早於任何嚴肅的威脅模型。
我的看法與行動清單
資安團隊應該從這次事件內化的，是「13 小時」這個數字。不是因為它特別快——以 2026 年的標準並不快——而是因為 AI 基礎設施的反應視窗，已經跟 Web 伺服器、邊緣代理同等緊迫，但多數組織還沒這樣對待它。AI 基礎設施目前躺在另一個 Slack 頻道、由另一個 on-call 輪值、用另一套（而且更不成熟）修補節奏。
如果你的組織在生產環境跑推論伺服器，這一週請：
審計每一個模型服務容器的出向（egress）策略。預設拒絕出站。如果推論容器確實需要連外，只放行它要拉取模型的那個 model registry。
把 GPU 推論節點的 IMDS 存取拔掉。最少使用 IMDSv2 並設定 hop-limit 1。更好的做法是：把推論放在僅有「讀取這一個 model bucket」權限的角色上。
把 AI 推論伺服器移到跟 Web 層同一條漏洞管理 SLA 之下。同一批掃描器、同一條 on-call、同一套攻擊視窗目標。
任何「影像載入器」、「文件載入器」或「替模型抓取 URL」的函式，都當成安全邊界對待。驗證 URL。阻擋私有 IP 段。阻擋 link-local 位址。阻擋自己 VPC 的 CIDR。
這一週我們跨過了一道門檻。AI 推論不再是擺在生產網路旁邊的研究級議題，它就是生產系統。請以對待生產系統的方式保護它。