此篇文章聚焦大型語言模型推論工具 LMDeploy 的資安風險，指出其在伺服器端請求偽造漏洞 CVE-2026-33626 公開後，短短不到 13 小時就被觀測到實際利用嘗試。LMDeploy 是 InternLM 開發、用於壓縮、部署與提供大型語言模型推論服務的工具，支援文字模型與視覺語言模型。這次漏洞影響 0.12.3 之前版本，官方已在 0.12.3 修補。文章特別提醒，問題出在視覺語言模組處理圖片網址的流程，攻擊者可透過模型請求中的 image_url 欄位，誘使後端伺服器代為連向雲端中繼資料服務、內部網路或本機資源，讓原本不應對外開放的系統暴露在攻擊鏈之中。
此篇文章進一步說明漏洞的技術成因與攻擊速度。LMDeploy 在載入遠端圖片時，load_image() 函式未先檢查目標網址是否指向內部 IP、私有網段或 link-local 位址，導致對外開放的推論服務可能被濫用為 HTTP 請求代理。Sysdig 威脅研究團隊以 GitHub 主要安全公告頁面公開時間計算，公告於臺灣時間 4 月 21 日 23 時 04 分發布，而研究團隊在 4 月 22 日 11 時 35 分就在蜜罐中觀測到首次利用嘗試，中間僅相隔 12 小時 31 分鐘。值得注意的是，研究人員當時並未在 GitHub 或主要漏洞利用程式庫看到公開概念驗證程式，這意味著攻擊者可能已能根據公告揭露的受影響檔案、參數與檢查缺口，自行拼湊出可用的攻擊流程。
此篇文章最後將風險拉回實際部署環境，說明 SSRF 的危害取決於推論節點所處位置與權限設定。若 LMDeploy 部署在雲端 GPU 執行個體，且綁定較高權限角色，攻擊者就可能透過中繼資料服務取得臨時憑證；若同一主機或叢集內還有 Redis、MySQL 或管理介面，也可能藉由連線回應偵察內網服務是否存在。因此，使用 LMDeploy 的團隊應優先升級至 0.12.3 或後續版本；若短期無法更新，則應透過反向代理或 API 閘道過濾不可信的 image_url，或暫時停用視覺模型端點。對於已公開暴露且仍使用 0.12.2 或更早版本的部署，則應檢查是否出現連向 169.254.169.254、127.0.0.1 或私有網段的異常請求，必要時輪換 IAM 角色憑證，並搭配 IMDSv2、VPC 出口限制與執行期偵測，降低漏洞被進一步利用的風險。
