AI TracksSTUDIO
中文 EN
開始合作

資安與權限設計

7-Zip XZ 堆積緩衝區溢位（CVE-2026-14266）：原理、攻擊模型與修補實務

本文從緩衝區溢位的記憶體模型出發，說明此漏洞在 `MixCoder_Code`（`C/XzDec.c`）中的成因、為何屬於「高危而非重大」、以及個人與企業應如何處置。

2026.08.03 5 分鐘閱讀 Studio 管理員 到訪次數 20
7-Zip XZ 堆積緩衝區溢位（CVE-2026-14266）：原理、攻擊模型與修補實務

摘要

2026 年 6 月 25 日，7-Zip 釋出 26.02，修補影響 XZ 壓縮資料處理的堆積型緩衝區溢位漏洞 CVE-2026-14266。趨勢科技 Zero Day Initiative（ZDI）於 7 月 15 日公開技術細節，評為 CVSS 7.0（High）。目前尚無公開 PoC，也未見可信的野外利用報告；但因 7-Zip 無自動更新，長期未手動升級的環境仍處於風險窗口。

本文從緩衝區溢位的記憶體模型出發，說明此漏洞在 MixCoder_Code（C/XzDec.c）中的成因、為何屬於「高危而非重大」、以及個人與企業應如何處置。

一、先回到基礎：什麼是緩衝區溢位？

程式在處理輸入時，常會先配置一塊固定大小的記憶體（buffer），再把資料寫入其中。若寫入長度超過已配置容量，多餘位元組就會覆寫相鄰記憶體——這就是緩衝區溢位（Buffer Overflow）。

依配置位置可粗分為：

類型 配置位置 典型後果
Stack-based 呼叫堆疊（區域變數） 覆寫返回位址、控制流程劫持
Heap-based 堆積（malloc / new 等） 破壞堆積中繼資料、相鄰物件、函式指標，進而達成任意寫入或程式碼執行

CVE-2026-14266 屬於後者：Heap-based Buffer Overflow（CWE-122）。攻擊者不必直接「炸堆疊」，而是透過惡意構造的 XZ 串流，讓解碼器在堆積上的輸出緩衝區發生越界寫入（out-of-bounds write）。在特定條件下，這可進一步轉化為在目前程序權限下的任意程式碼執行（RCE）。

關鍵觀念：溢位本身是「寫錯長度」；能否變成穩定利用，還取決於配置器狀態、相鄰物件佈局、ASLR / DEP / CFG 等緩解機制，以及觸發路徑是否可重複。因此同一類缺陷，有時只造成崩潰（DoS），有時能升級為 RCE。

二、漏洞概況

項目 內容
CVE CVE-2026-14266
ZDI ZDI-26-444（ZDI-CAN-30169）
產品 7-Zip
弱點類型 Heap-based Buffer Overflow（CWE-122）
觸發條件 開啟／解壓特製的 XZ（chunked）資料
影響版本 脆弱邏輯至少可追溯至 7-Zip 21.07（2021）；實務上 26.01 及更早版本應視為需升級
修補版本 7-Zip 26.02（2026-06-25）
CVSS 3.0 7.0（High），向量 AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
發現者 Lunbun LLC（Landon Peng），經 ZDI 協調揭露
時程 2026-06-05 通報廠商 → 2026-06-25 修補釋出 → 2026-07-15 公開諮詢

ZDI 描述重點：缺陷存在於 XZ chunked data 的處理；特製壓縮資料可觸發堆積緩衝區溢位，攻擊者可在目前程序（7-Zip）權限脈絡下執行程式碼。利用需使用者互動（開啟惡意檔案或造訪惡意頁面誘使開啟）。

三、原理深入：為什麼會在 XZ 解碼時溢位？

3.1 XZ 與 MixCoder 的角色

XZ 格式常以過濾器鏈（filter chain）處理資料；7-Zip 在 C/XzDec.c 的 MixCoder_Code 負責協調多個 coder（例如 LZMA2）的解碼輸出。解碼是分段、多次傳遞進行的：每一次呼叫都會向輸出緩衝區寫入一段結果，並累計「已寫入多少」。

正確的長度契約應是：

本次可寫上限 = 緩衝區總容量 − 先前已寫入位元組數

若把「總容量」誤當成「本次還能寫的剩餘空間」，後續傳遞就可能寫出邊界。

3.2 缺陷本質：剩餘空間沒有被正確扣除

公開分析指出，問題出在 MixCoder_Code 的 SingleBuf（outBuf）路徑：解碼器在每次傳遞取得的是完整輸出緩衝區長度（destLenOrig），而不是扣除 outWritten 後的剩餘可用空間。於是：

  1. 第一次寫入可能仍落在緩衝區內；
  2. 後續傳遞仍以「整段緩衝區長度」作為可寫上限；
  3. LZMA2 等下游解碼器據此設定寫入上限（例如 dic limit），實際寫入超過已配置的 heap buffer；
  4. 形成 out-of-bounds write，破壞堆積上相鄰記憶體。

可抽象為：

錯誤邏輯（概念）：
  destLen2 = destLenOrig;          // 每次都給「整段」長度
  decoder.Code(..., &destLen2);    // 可能寫超過剩餘空間

正確邏輯（概念）：
  if (destLen2 < outWritten) abort;
  destLen2 -= outWritten;          // 只允許寫入剩餘容量
  decoder.Code(..., &destLen2);
  outWritten += destLen2;

公開技術討論亦指出：單執行緒路徑上，上層 XzUnpacker_Code 可能已有基於 unpackSize 的剩餘量夾限；但多執行緒／SingleBuf 路徑若直接把完整長度往下傳，就會繞過這層保護。這解釋了為何問題看似「長度檢查已存在」，卻仍能在特定路徑觸發。

3.3 從「越界寫」到「程式碼執行」

堆積溢位常見利用鏈（概念層級，非利用教學）：

  1. 破壞相鄰物件：覆寫 heap 上的結構體欄位、vtable／函式指標、長度欄位；
  2. 取得任意寫入或控制流：在後續釋放／配置／呼叫時轉向攻擊者控制的位址；
  3. 在 7-Zip 程序內執行殼碼或載入器：權限等同使用者當下執行 7-Zip 的權限，不會自動提權。

因此 ZDI 雖標為 Remote Code Execution，語意上是「可透過遠端投遞的惡意檔達成本機程式碼執行」，而非「無需互動的遠端服務漏洞」。

四、嚴重性為何是 High（7.0），不是 Critical？

部分早期報導使用「重大／Critical」字眼，但 ZDI 正式評分為 7.0 High。解讀 CVSS 向量有助於正確分流：

指標 值 含義
AV:L Local 攻擊者需讓受害者在本機開啟惡意檔（常搭配釣魚／社工）
AC:H High 攻擊複雜度高，可靠利用並非輕鬆可重現
PR:N None 不需先取得目標帳號權限
UI:R Required 必須有使用者互動
S:U Unchanged 影響範圍不自動跨越至其他安全邊界
C/I/A:H High 一旦成功，機密性、完整性、可用性皆可受嚴重影響

實務含義：

  • 不是「掃到一個埠就能遠端打爆」的無互動漏洞；
  • 是「惡意壓縮檔 + 使用者開啟」這類經典投遞鏈，仍對一般使用者與企業桌面構成實質風險；
  • 成功後也只在 7-Zip 既有權限執行，不會自動變成 SYSTEM／管理員（除非使用者本身以高權限執行）。

對 SOC／弱點管理而言，應依 High + 廣泛部署的用戶端軟體 + 無自動更新 來排程，而不是因為「不是 Critical」就延後。

五、如何解決與防禦

5.1 根本解法：升級至 7-Zip 26.02（或更新）

官方修補的核心思路非常直接：

  • 每次寫入前，將可寫長度改為 剩餘容量（扣除 outWritten）；
  • 若累計寫入量與緩衝區狀態不一致（例如剩餘計算出現矛盾），立即中止並回傳錯誤，而非繼續解碼。

也就是說，修補屬於邊界夾限（bounds clamping）與失敗安全（fail-closed）：寧可解壓失敗，也不允許越界寫入。

操作建議：

  1. 前往官方網站 https://www.7-zip.org/ 下載並安裝 26.02 或更新版本（勿從不明鏡像下載）。
  2. 確認版本：開啟 7-Zip → Help → About，應顯示 26.02 以上。
  3. 注意：7-Zip 沒有自動更新；未手動升級的裝置不會自動獲得修補。
  4. 26.02 亦整合同年稍早 26.01 的相關修補（例如 NTFS 處理相關的 CVE-2026-48095），一次升級可同時收斂多個記憶體安全問題。

5.2 企業與供應鏈面

對象 建議作法
終端電腦／工程機 透過 SCCM、Intune、WSUS 第三方目錄或腳本盤點 7-Zip 版本，強制升級至 ≥ 26.02
內嵌 7-Zip／XZ 解碼器的產品 向廠商確認是否使用受影響程式碼路徑，並套用其官方修補
郵件閘道／沙箱 對來路不明的 .xz、含 XZ 串流的壓縮檔提高檢測與沙箱引爆優先級
使用者行為 持續宣導：勿開啟不明來源壓縮檔；即使「只是解壓」也可能觸發解析器漏洞
偵測應變 關注 7-Zip 異常崩潰、惡意壓縮檔投遞活動；目前雖無公開 PoC，細節公開後仿製風險會上升

5.3 開發者視角：這類漏洞如何從源頭避免？

即便你不是 7-Zip 維護者，此案例仍是經典的安全編碼教材：

  1. 長度契約要表達「剩餘」而非「總量」
    多段寫入 API 應統一使用 remaining = capacity - written，並在每次傳遞後更新 written。
  2. 上層夾限不能假設下層一定會再夾一次
    多執行緒、不同緩衝模式（SingleBuf / 串流）容易讓「以為已檢查」變成「某條路徑沒檢查」。
  3. 失敗要可中止
    發現長度不一致時應回傳錯誤並停止，避免「盡量解」導致記憶體破壞。
  4. 記憶體不安全語言需要額外防線
    C/C++ 解析器對不可信輸入應搭配模糊測試（fuzzing）、ASan/MSan，以及最小權限執行。
  5. 壓縮／媒體／文件解析器是高價值攻擊面
    複雜狀態機 + 不可信位元組流，是緩衝區錯誤的常客；更新策略必須假設「使用者會開啟惡意檔」。

5.4 暫時緩解（無法立即升級時）

  • 暫時改用已修補或較少暴露相同程式碼路徑的工具處理不可信壓縮檔（仍須評估替代軟體自身風險）。
  • 以應用程式控制（WDAC / AppLocker）限制未核准版本的 7-Zip 執行。
  • 對高風險角色（財務、採購、客服）強化附件沙箱與標示（MotW）政策——歷史上 7-Zip 相關漏洞也曾與 MotW 繞過利用鏈有關，壓縮軟體本身即為攻擊熱點。

暫時緩解無法取代升級；目標仍應是盡快完成 26.02 部署。

六、時間線與歷史脈絡

2026-04-27  7-Zip 26.01：修補一批類似記憶體安全問題（含 CVE-2026-48095 等）
2026-06-05  研究人員經 ZDI 向廠商通報 CVE-2026-14266
2026-06-25  7-Zip 26.02 發布（修補釋出，早於細節公開約 20 天）
2026-07-15  ZDI 公開 ZDI-26-444 技術諮詢
（截至公開初期） 尚無公開 PoC、尚無可信野外利用報告

這並非 7-Zip 首次出現壓縮格式解析的記憶體問題。壓縮器長期以 C/C++ 處理極複雜、不可信的位元組流，任何「長度、位移、區塊大小」計算偏差都可能變成安全漏洞。對維運而言，重點不是記住每一個 CVE 編號，而是建立：手動軟體也要納入修補清單。

七、結論與行動清單

CVE-2026-14266 的本質，是 XZ 解碼多段輸出時誤用「完整緩衝區長度」而非「剩餘可寫空間」，導致堆積越界寫入。修補方向正確且精簡：夾限剩餘長度、狀態不一致時中止。風險評級為 High 而非 Critical，反映的是利用條件（本機、需互動、高複雜度），不代表可以忽略。

立刻可做：

  1. 確認本機／艦隊中的 7-Zip 版本；低於 26.02 者升級。
  2. 盤點內嵌 7-Zip／XZ 解碼元件的產品，追蹤廠商公告。
  3. 將「無自動更新的常用工具」納入定期弱點掃描與修補流程。
  4. 對不可信壓縮檔維持釣魚防禦與沙箱策略。

緩衝區溢位不是新概念，但每次都提醒同一件事：解析不可信資料時，長度計算錯一次，就可能從「解壓失敗」變成「程序被接管」。 對 7-Zip 使用者來說，最有效的解法仍然是——手動更新到 26.02 或更新版本。

參考資料

  1. 資安人科技網：〈7-Zip 修補 XZ 壓縮處理堆積緩衝區溢位漏洞 CVE-2026-14266，建議手動更新至 26.02 版〉
    https://www.informationsecurity.com.tw/article/article_detail.aspx?aid=13103&mod=1
  2. Zero Day Initiative：ZDI-26-444
    https://www.zerodayinitiative.com/advisories/ZDI-26-444/
  3. 7-Zip 官方網站（請自此下載正版更新）
    https://www.7-zip.org/
  4. MITRE CWE-122：Heap-based Buffer Overflow
    https://cwe.mitre.org/data/definitions/122.html
← 返回技術文章