Swati Khandelwal2026 年 7 月 24 日漏洞 / 資料庫安全性

Redis 於 7 月 23 日發布 七項安全性更新，研究人員已公開針對原版 Redis 6.2.22、7.4.9、8.6.4 及 8.8.0 版本的已驗證 RCE 概念驗證程式。

所有四條利用鏈都需要 RESTORE。Streams 利用鏈還需要 EVAL 和 XGROUP；8.8.0 利用鏈則需要 EVAL 以及內建的 RedisBloom 模組。Redis 表示，底層記憶體缺陷可能導致遠端程式碼執行。

Redis 6.2.23、7.2.15 及 7.4.10 修復了 Streams 共享 NACK 使用後釋放問題；Redis 8.2.8、8.4.5 及 8.6.5 同時修復了 Streams 問題以及 RedisBloom 與 TDigest 的越界寫入；Redis 8.8.1 修復了 RedisBloom 及 TDigest 載入器，而 Streams 防護已在 Redis 8.8.0 中存在。

兩個概念驗證目標——Redis 6.2.22 及 7.4.9——正是 Redis 曾建議使用者安裝的五月安全性更新，但這些版本並未包含共享 NACK 擁有權防護。

請升級至已部署分支的修復版本。在此之前，請撤銷不需要 RESTORE 的帳戶權限，並阻擋不受信任的網路存取。限制 RESTORE 可切斷兩條已公開的利用路徑。

Cybersecurity

截至 2026 年 7 月 24 日，Redis 的 7 月 23 日版本說明及所檢視的 公開概念驗證儲存庫均未通報實際攻擊事件。

透過 RESTORE 的兩條路徑

Redis Streams 路徑是一項共享擁有權的漏洞。損壞的 RDB 物件可能使兩個消費者指向同一條待處理項目記錄，因此移除兩個消費者會釋放同一物件兩次。

已發布的腳本旨在將產生的記憶體損壞轉換為任意記憶體存取，並最終呼叫 system()。

RedisBloom 路徑則是 TDigest RDB 載入器中的越界寫入。載入器從一個序列化值分配記憶體，但卻信任另一個攻擊者可控制的容量欄位來決定要載入多少資料。

Redis 8.8.0 腳本旨在將此不一致轉換為讀取與寫入原語、洩漏 Redis 及 libc 位址，並呼叫 system()。

Streams 共享 NACK 利用鏈

第一條路徑位於 Redis Streams。一個損壞的 RDB 物件可使兩個消費者指向同一條待處理項目記錄，該記錄在內部由 streamNACK 表示。移除第一個消費者會釋放該物件，並使第二個消費者保留一個懸空指標。腳本接著也移除第二個消費者。一次區塊，兩次釋放。

Redis 8.6.4 的版本說明引用了 PR #15081。但 The Hacker News 檢視原始碼後發現，標記的 8.6.4 原始碼缺少該變更所新增的重複擁有權檢查。該防護出現在 7 月 23 日發布的 Redis 8.6.5 中。

已發布的 Redis 8.6.4 腳本旨在將雙重釋放轉換為任意記憶體存取，接著毒化資料庫雜湊函式，使一個特製的 GET 呼叫 system()。它還原指標並檢查 Redis 是否仍回應。

RedisBloom TDigest 利用鏈

第二條路徑位於 RedisBloom 的 TDigest RDB 載入器。它從序列化壓縮值分配其質心陣列，然後信任另一個攻擊者可控制的容量欄位來決定可載入多少節點。一個小的實際分配搭配膨脹的中繼資料會產生越界寫入。

Redis 8.8.0 腳本旨在將寫入轉換為讀取與寫入原語、洩漏 Redis 及 libc 位址，並毒化資料庫雜湊函式，使特製的 GET 呼叫 system()。另一個另行發布的概念驗證公開了相同的根本原因，以及針對 Redis 8.8.0 的已驗證 RCE 利用鏈。

Cybersecurity

Redis 的 七月修復要求已載入的 TDigest 容量必須符合從壓縮值推導出的分配。它還在讀取陣列之前限制已合併與未合併節點計數器。

七項更新，無新 CVE 記錄

該儲存庫將 Streams 問題歸類為 CVE-2026-25589「不完整修復系列」的一部分，但 Redis 將該 CVE 對應至 RESTORE 期間的 RedisBloom 記憶體損壞，而非 Streams 共享 NACK 缺陷。Redis 的七月版本說明未列出任一新漏洞類別的 CVE 或 CVSS 分數。

截至 7 月 24 日，The Hacker News 的搜尋未發現 7 月共享 NACK 或 TDigest 發現的獨立 NVD 記錄。NVD 仍列出五月針對 CVE-2026-25243 及 CVE-2026-25589 的記錄。在 CISA 已知遭利用漏洞目錄的搜尋也未返回任一識別碼的條目。

此次揭露緊隨 另一項五月修復的 AI 發現 Redis RCE 漏洞之後。Bera Buddies 自稱為「AI 代理研究」。Chaofan Shou 在 X 上表示，Kimi K3 代理在大約 90 分鐘內發現 19 個 Redis 零時差漏洞，並另一次執行在 27 分鐘內產生 Redis 8.8.0 利用程式。

這些數量、時間及所聲稱的自主程度仍屬自行通報。Redis 的公開記錄確認了漏洞與修復，但未驗證所聲稱的零時差數量或代理工作的獨立程度。

Redis 6.2.22 及 7.4.9 是五月的目標版本。到七月，兩者都需要再次更新。請檢查確切的分支版本，而非 Redis 是否僅「最近已修補」。

覺得這篇文章有趣嗎？請在 Google 新聞、Twitter 及 LinkedIn 追蹤我們，以閱讀我們發布的更多獨家內容。