GNU gzip 解壓縮共用陣列未清空，導致緩衝區讀取溢位（CVE-2026-41992）
GitHub Advisory Database GHSA-qxh4-rprf-2mmj · 2026-06-29（oss-security 揭露於 2026-08-23）
GNU gzip 在 1.14（含）以前的版本存在一個緩衝區讀取溢位漏洞，編號 CVE-2026-41992。問題出在 gzip 內部給 LZW 與 LZH 兩種解壓縮格式共用的全域陣列，在單次 gzip -d 呼叫中處理完 LZW 資料後沒有被清空，導致後續解壓縮 LZH 資料時讀到陣列裡的殘留舊值。此漏洞已於 2026-08-23 透過 oss-security 郵件論壇對外揭露，GitHub Advisory Database 將其列為中度風險（CVSS 6.9，CWE-126 緩衝區過度讀取）。
漏洞機制
gzip 支援多種歷史壓縮格式，其中 LZ77、LZW、LZH 三種解碼器共用同一組名為 LEFT／RIGHT 的全域陣列。這組陣列原本只在單一格式解碼期間使用，但 gzip 允許在一次命令列呼叫中依序解壓多個檔案，例如先處理一個 LZW 壓縮檔、緊接著再處理一個 LZH 壓縮檔。
若攻擊者刻意打造一份特製的 LZW 檔案，讓 LEFT／RIGHT 陣列在解碼完成後停留在特定數值，再誘使受害者在同一個 gzip -d 指令中緊接著解壓另一份特製的 LZH 檔案，LZH 解碼器的 huf_decode_start() 函式便會讀到未被重置的舊索引值，進而造成陣列邊界外的記憶體讀取。
受影響版本
- GNU gzip
1.14及更早版本 - 觸發條件：單一
gzip -d程序需依序處理「特製 LZW 資料」後再處理「特製 LZH 資料」
修補與緩解
上游已提交修補 commit 63dbf6b3b9e6e781df1a6a64e609b10e23969681，在 huf_decode_start() 進入 LZH 解碼前先清空 LEFT／RIGHT 陣列，避免殘留資料被誤用。這個修補目前存在於原始碼版本控制中，尚待正式併入下一個 gzip 發行版，部分發行版（如 SUSE）已針對此 commit 各自提供更新套件。
# 檢查目前版本
gzip --version
# 若發行版已釋出更新，透過套件管理員升級
sudo apt update && sudo apt install --only-upgrade gzip對以自動化腳本方式呼叫 gzip -d 處理不受信任來源、且同一程序會連續解壓多種壓縮格式檔案的環境，應優先套用上游修補或等待發行版更新，避免將多種格式檔案交由同一個 gzip 呼叫連續處理。
原始來源：GitHub Advisory Database GHSA-qxh4-rprf-2mmj、oss-security 郵件論壇
Kata Containers 執行期未驗證設定路徑，容器使用者可讓主機以 root 執行任意程式（CVE-2026-50540）
Kata Containers Security Advisory GHSA-mp2j-xm59-qfgw · 2026-07-20（NVD 收錄於 2026-08-07，最後更新 2026-08-23）
Kata Containers 是一個讓容器以輕量虛擬機器（VM）方式執行、藉此取得比一般容器更強隔離性的開源專案。其 Rust 與 Go 兩種執行期（runtime）實作近日被揭露存在一個嚴重層級的主機端程式碼執行漏洞，編號 CVE-2026-50540，影響 4.0.0 之前的所有版本。上游已於 2026-07-20 發布安全公告，並於 2026-08-23 透過 oss-security 郵件論壇對外周知。
漏洞機制
Kata Containers 允許使用者透過 Pod annotation io.katacontainers.config_path 指定一份 TOML 設定檔，用來覆寫該 Pod 專屬的執行期組態。kata-runtime 的 load_config 函式在讀取這個路徑時沒有做任何白名單或格式限制，任何能設定 Pod annotation 的使用者都能指向主機檔案系統中的任意一份 TOML 檔案。
由於這份設定檔可以決定 hypervisor 執行檔路徑、virtio-fs daemon 路徑等關鍵欄位，攻擊者只要能在主機上放置或指向一份惡意檔案，就能讓 Kata 在建立 sandbox 時載入並以 root 權限執行，達成跨越容器邊界的主機端遠端程式碼執行。NVD 給出的 CVSS 分數為 9.1–9.6（Critical），因為觸發僅需低權限帳號且不需使用者互動。
受影響版本
- Kata Containers rust runtime
< 4.0.0 - Kata Containers go runtime
< 4.0.0 - 修補版本：
4.0.0（修補 commit03cc670076099530f4e1e9cb22849afdafb20f65）
修補與緩解
官方建議直接升級至 Kata Containers 4.0.0 或更新版本，該版本移除了對 io.katacontainers.config_path annotation 的無條件信任。若短期內無法升級，安全公告提供了兩種緩解方式。
- 停用
io.katacontainers.config_pathannotation，或限制其只能指向如/etc/kata-containers/、/opt/kata/等白名單目錄 - 在 Kubernetes 叢集部署 admission webhook，攔截並拒絕帶有該 annotation 的 Pod 建立請求
原始來源：Kata Containers Security Advisory、NVD CVE-2026-50540、修補 commit
Perl DBD::Pg 3.21.0 重寫 quote_float 配置不足，特殊浮點字串觸發堆積溢位寫入（CVE-2026-78183）
DBD::Pg 修補 commit 6d6f47e / DBD-Pg 3.21.1 Changes · 2026-08-23
DBD::Pg 是 Perl 用來連接 PostgreSQL 資料庫的 DBI 驅動模組，其中 quote_float() 函式負責在組出安全的 SQL 字面值時，替浮點數加上必要的括號與跳脫符號。版本 3.21.0 對 quote.c 做了重寫，重寫後的 quote_float() 在處理 NaN、Inf、+Inf、-Inf、Infinity 等特殊浮點字串時配置的緩衝區不足，導致堆積（heap）緩衝區溢位寫入，即 CVE-2026-78183。此問題已於 2026-08-23 隨 DBD-Pg 3.21.1 一併修補並公開揭露。
漏洞機制
quote_float() 原本的邏輯是配置「輸入字串長度 + 1」個位元組給輸出字串，這對一般數字（如 3.14）沒問題，因為輸出長度與輸入長度相近。但當輸入是 Inf、-Inf、Infinity 這類特殊字面值時，函式會將其轉換成加了單引號與型別轉換寫法的 SQL 字面值，實際輸出長度比輸入多出 3 個位元組。
因為配置緩衝區時只多留 1 個位元組，每辨識出一個特殊浮點字面值就會造成 2 個位元組的堆積溢位寫入。攻擊者只要能控制傳入 $dbh->quote() 的內容，例如呼叫 $dbh->quote("Infinity", DBI::SQL_NUMERIC)，就能觸發這個溢位。
受影響版本
- DBD::Pg
3.21.0（quote.c重寫版本引入的迴歸缺陷） - 更早版本不受影響
修補與緩解
// quote.c，quote_float()
- New(0, new_string, length + 1, char);
+ New(0, new_string, length + 3, char);修補 commit 6d6f47ed2403cda55c82b1bad56e388ba7390065 除了修正 quote_float() 的配置大小外，同時修正了 dbdimp.c 中另一處配置長度少算 1 個位元組的問題，以及 quote.c 內十六進位解碼迴圈缺少邊界檢查的風險，屬於針對同一份安全報告所做的防禦性強化。
- 升級至
DBD::Pg 3.21.1或更新版本