實證研究發布於 AIA: 2026年8月5日

SGLang Pickle 不安全反序列化漏洞：內部 AI 訊息通道亦需落實身分驗證與邊界控管

CERT/CC 回報了三條與 Python pickle 反序列化相關的 SGLang 遠端程式碼執行 (RCE) 的資安攻擊路徑：其中兩條成立的前提，是系統啟用了選配的分散式架構功能、且未驗證身分的 ZeroMQ 連接埠可從外部連線；第三條則需維運人員重新載入未經審核的歷史請求傾印檔 (request dump)。由於公開修補紀錄與目前 CNA（CVE Numbering Authority，負責審核與核發 CVE 漏洞編號的授權機構）資料庫版本彼此矛盾，資安團隊切勿僅依賴套件版本字串，必須實地校驗執行期設定與網路可達性 (reachability)。

Remote Code ExecutionAI Deployment SecurityRuntime IsolationAI InfrastructureOpen Source Security

4 項對應的 AIDEFEND 防禦手法

來源: CERT/CC Vulnerability Note VU#665416: SGLang contains multiple deserialization vulnerabilities

作者: CERT/CC

原文發布: 2026年3月31日

威脅分析

Python 的 pickle 模組在進行反序列化（deserialization，將備份或傳輸的位元組資料還原回記憶體物件）時，設計上會自動執行資料中夾帶的任意程式碼指令。只要惡意位元組資料傳入 pickle.loads() 或 pickle.load() 處理流程就會立即觸發攻擊程式碼執行，後續的任何資料驗證皆已無法阻止危害。
兩條網路攻擊路徑均需特定啟用條件與網路可達性。 CVE-2026-3059 影響處理圖片、視訊等多模態 AI 生成任務的訊息轉發元件（multimodal broker，非預設開啟，需另外啟用）；CVE-2026-3060 則影響將圖像/文字編碼器與生成器拆開獨立擴充的平行運算架構（Encoder Parallel Disaggregation，用來提升大規模多模態模型推論效率的分散式機制）。兩者皆需管理者主動啟用該選配功能，且其未經身分驗證的 ZeroMQ 接收端連接埠需處於暴露狀態。
第三條路徑需結合惡意檔案與維運人員的操作。 CVE-2026-3989 存在於 replay_request_dump.py 工具。攻擊者需先控制傾印檔，或誘騙維運人員在環境中重新載入並執行未經審核的檔案，此非未經身分驗證即可直接遠端觸發的網路 RCE。
公開修補紀錄存在版本資訊衝突。 CERT/CC 與 0.5.10 官方釋出說明指出該版本已修復上述三項 CVE，然而目前 CNA 紀錄仍將 0.5.10 標示為受影響版本。建議防守方除升級至最新支援版本外，亦應仔細校驗 ZeroMQ 綁定位址 (bind address)、跨節點設定與網路存取邊界。目前尚無公開證據顯示這些漏洞已被用於實際攻擊。

適用的 4 項 AIDEFEND 防禦手法

AID-H-003.010

Deployed AI Software Vulnerability Remediation Lifecycle

極高

盤點實際運行的 SGLang 套件版本與容器映像檔雜湊值 (image digest)；若確認目前使用的是受影響版本，應立即升級至已修復版本。若因系統相容性等原因無法立即升級，則應先停用受影響的選配功能，再以最新支援版本重建環境並分階段部署，同時確認舊版工作負載已全數下線。鑑於公開資料對 0.5.10 版的修復狀態尚存分歧，防守方必須將執行期設定校驗與網路連線測試列為修復驗證的必要依據。

AID-I-002.001

Internal AI Network Segmentation

高

透過主機防火牆與預設拒絕的 NetworkPolicy 進行網路微隔離 (Micro-segmentation)，僅允許具備業務需求的 SGLang 對等節點連線至指定 ZeroMQ 連接埠。此舉可在未經信任的訊息抵達 pickle 反序列化接收端前即時阻擋；即使跨節點設定覆寫了預設的本機回送位址 (loopback)，獨立的網路邊界依然能發揮防護效果。

AID-H-004.002

Service & API Authentication

高

當訊息 broker 需跨主機傳輸時，應導入 mTLS (雙向 TLS) 或工作負載身分驗證 (Workload Identity) 進行呼叫端驗證與細粒度授權。這能消除「只要知道內部連接埠即代表可信」的盲點；然而仍需注意，傳輸層驗證無法改變 pickle 處理受入侵節點資料時的根本風險。

AID-I-001.001

Container-Based Isolation

中

以非 root 權限、唯讀檔案系統、最小化目錄掛載、無正式環境憑證且設有資源限制的容器來執行 SGLang。若不安全反序列化仍不幸引發程式碼執行，這些隔離邊界能有效限縮攻擊者可存取的檔案、身分與相鄰系統範圍，重點在於圍堵與控制影響，而非修補解析器本身。

身為資安防禦者，我們應該這麼做

升級至最新支援的 SGLang 版本，記錄實際套件版本與容器映像檔雜湊值 (image digest)，並於部署後實地驗證 ZeroMQ 的實際綁定位址 (bind address) 與節點可達性。
若未使用多模態生成或編碼器平行分離功能，應直接將其停用。若需跨節點運作，僅開放特定工作負載連線至指定連接埠，並要求部署工作負載身分驗證 (Workload Identity)。
全面清查請求傾印檔目錄與 replay_request_dump.py 的操作流程，限制低權限使用者與自動化排程寫入該目錄，且切勿在生產環境中重新載入並執行來源未知的 .pkl 檔案。
嚴禁以 root 身分執行服務程序，禁止掛載主機敏感目錄或注入正式環境 secrets。持續監控異常的 broker 連線、傾印檔建立、子程序衍生及工作程序的異常對外連線。
規劃將網路層與外部檔案的 pickle 訊息替換為純資料格式與嚴格 schema。使用受限的 unpickler 僅能微幅降低風險，無法作為任意 pickle 皆安全的合規保證。

1 個額外的防禦考量

內部 AI 訊息通道缺乏純資料序列化協定

除了上述漏洞修補、網路隔離、身分驗證與容器圍堵外，團隊仍需在架構層採用僅承載資料的傳輸協定，並驗證所有反序列化路徑皆能阻擋可執行的物件圖 (object graph)。

建議做法: 在所有面對網路與外部檔案的路徑上，全面以純資料格式 (如 JSON/Protobuf) 結合嚴格的 schema 替代 pickle。徹底盤點程式碼中剩餘的 pickle.load() 與 pickle.loads() 呼叫，明確標示其信任邊界，並透過反向測試驗證非預期的位元組無法呼叫建構函式或執行任意程式碼。

結論

這個案例劃清了三種常被混淆的資安控制領域：漏洞修補負責修正產品本身的缺陷路徑，網路分區與工作負載身分決定哪些端點能連至 broker，而執行期沙箱隔離則在反序列化仍觸發程式碼執行時限制損害範圍。團隊可參考 AIDEFEND 對應的防禦手法，將修補、可達性控管、身分驗證與圍堵責任明確拆分至各個防線。最終的資安工程目標，在於停止將 pickle 與內部連接埠視為隱含的信任證明。