Redis đã phát hành bảy bản cập nhật bảo mật vào ngày 23 tháng 7 sau khi các nhà nghiên cứu công bố các mã khai thác PoC RCE có xác thực cho các phiên bản Redis gốc 6.2.22, 7.4.9, 8.6.4 và 8.8.0.
Cả bốn chuỗi khai thác đều yêu cầu lệnh RESTORE. Chuỗi khai thác trên Streams cũng cần EVAL và XGROUP; chuỗi 8.8.0 cần EVAL và module RedisBloom đi kèm. Redis cho biết các lỗi bộ nhớ tiềm ẩn có thể dẫn đến thực thi mã từ xa (RCE).
Các phiên bản Redis 6.2.23, 7.2.15 và 7.4.10 đã khắc phục lỗi Use-after-free liên quan đến shared-NACK trong Streams; Redis 8.2.8, 8.4.5 và 8.6.5 khắc phục cả vấn đề Streams và lỗi ghi ngoài phạm vi (out-of-bounds write) trong RedisBloom và TDigest; Redis 8.8.1 khắc phục các bộ nạp RedisBloom và TDigest, trong khi lớp bảo vệ Streams đã có sẵn trong Redis 8.8.0.
Hai mục tiêu PoC là Redis 6.2.22 và 7.4.9, vốn là các bản cập nhật bảo mật tháng 5 mà Redis đã khuyến nghị người dùng cài đặt, nhưng những phiên bản đó lại không bao gồm cơ chế bảo vệ quyền sở hữu shared-NACK.
Người dùng được khuyến cáo nâng cấp lên phiên bản đã khắc phục cho nhánh đang triển khai. Cho đến lúc đó, hãy thu hồi quyền RESTORE từ các tài khoản không thực sự cần thiết và chặn truy cập mạng không tin cậy. Việc hạn chế RESTORE sẽ cắt đứt cả hai con đường khai thác đã được tiết lộ.
Cả ghi chú phát hành ngày 23 tháng 7 của Redis lẫn các kho lưu trữ PoC công khai đều chưa ghi nhận việc khai thác trong thực tế tính đến ngày 24 tháng 7 năm 2026.
Hai con đường thông qua RESTORE
Con đường qua Redis Streams là một lỗi chia sẻ quyền sở hữu (shared-ownership). Một đối tượng RDB bị hỏng có thể khiến hai consumer cùng trỏ vào một bản ghi pending-entry, vì vậy việc xóa cả hai consumer sẽ giải phóng cùng một đối tượng hai lần (double-free).
Kịch bản khai thác được công bố được thiết kế để chuyển đổi sự cố hỏng bộ nhớ này thành quyền truy cập bộ nhớ tùy ý và cuối cùng là thực thi lệnh system().
Con đường qua RedisBloom là một lỗi ghi ngoài phạm vi trong bộ nạp TDigest RDB. Bộ nạp đã cấp phát bộ nhớ từ một giá trị được tuần tự hóa nhưng lại tin tưởng vào một trường dung lượng (capacity) riêng biệt do kẻ tấn công kiểm soát khi quyết định lượng dữ liệu cần nạp.
Kịch bản khai thác cho Redis 8.8.0 được thiết kế để biến sự sai lệch đó thành các nguyên hàm đọc và ghi, làm rò rỉ địa chỉ Redis và libc, sau đó gọi lệnh system().
Chuỗi Shared-NACK trong Streams
Con đường đầu tiên nằm trong Redis Streams. Một đối tượng RDB bị lỗi có thể khiến hai consumer cùng trỏ đến một bản ghi pending-entry, được đại diện nội bộ bởi streamNACK. Việc xóa consumer đầu tiên sẽ giải phóng đối tượng và khiến consumer thứ hai giữ một con trỏ lơ lửng (dangling pointer). Các kịch bản khai thác sau đó sẽ xóa luôn consumer thứ hai. Một khối bộ nhớ, hai lần giải phóng.
Ghi chú phát hành của Redis 8.6.4 dẫn chứng PR #15081. Tuy nhiên, qua xem xét mã nguồn, các nhà nghiên cứu nhận thấy mã nguồn 8.6.4 được gắn thẻ thiếu kiểm tra quyền sở hữu trùng lặp. Lớp bảo vệ này chỉ xuất hiện trong Redis 8.6.5, được phát hành vào ngày 23 tháng 7.
Kịch bản khai thác Redis 8.6.4 đã công bố được thiết kế để biến lỗi double-free thành quyền truy cập bộ nhớ tùy ý, sau đó làm nhiễm độc hàm băm của cơ sở dữ liệu để một lệnh GET được tạo thủ công có thể thực thi system(). Nó khôi phục con trỏ và kiểm tra xem Redis có còn phản hồi hay không.
Chuỗi TDigest trong RedisBloom
Con đường thứ hai nằm trong bộ nạp TDigest RDB của RedisBloom. Nó cấp phát các mảng centroid từ một giá trị nén được tuần tự hóa, sau đó tin tưởng vào một trường dung lượng riêng do kẻ tấn công kiểm soát để quyết định số lượng node có thể được nạp. Một lần cấp phát thực tế nhỏ đi kèm với siêu dữ liệu bị thổi phồng tạo ra lỗi ghi ngoài phạm vi.
Kịch bản khai thác Redis 8.8.0 được thiết kế để biến lỗi ghi thành các nguyên hàm đọc và ghi, làm rò rỉ địa chỉ Redis và libc, đồng thời làm nhiễm độc hàm băm cơ sở dữ liệu để lệnh GET thực thi system(). Một mã khai thác PoC riêng biệt khác cũng đã công bố cùng nguyên nhân gốc rễ và một chuỗi RCE có xác thực chống lại Redis 8.8.0.
Bản sửa lỗi tháng 7 của Redis yêu cầu dung lượng TDigest được nạp phải khớp với việc cấp phát bắt nguồn từ giá trị nén. Nó cũng giới hạn các bộ đếm node đã hợp nhất và chưa hợp nhất trước khi đọc các mảng.
Bảy bản phát hành, không có bản ghi CVE mới
Kho lưu trữ gọi vấn đề Streams là một phần của "họ bản sửa lỗi chưa hoàn chỉnh" CVE-2026-25589, nhưng Redis ánh xạ CVE đó cho lỗi hỏng bộ nhớ RedisBloom trong lệnh RESTORE, chứ không phải lỗi shared-NACK của Streams. Ghi chú phát hành tháng 7 của Redis không liệt kê CVE hoặc điểm CVSS cho cả hai loại lỗi mới này.
Tính đến ngày 24 tháng 7, các tìm kiếm không tìm thấy bản ghi NVD riêng biệt cho các phát hiện shared-NACK hoặc TDigest tháng 7. NVD vẫn liệt kê các bản ghi tháng 5 cho CVE-2026-25243 và CVE-2026-25589. Danh mục Lỗ hổng bị khai thác đã biết của CISA cũng chưa có mục nhập nào cho các định danh này.
Tiết lộ này theo sau một lỗi Redis RCE khác do AI phát hiện đã được vá vào tháng 5. Nhóm Bera Buddies tự mô tả mình là "Nghiên cứu Tác nhân AI". Chaofan Shou đã cho biết trên X rằng các tác nhân Kimi K3 đã tìm thấy 19 lỗi Zero-Day của Redis trong khoảng 90 phút và một lần chạy khác đã tạo ra mã khai thác Redis 8.8.0 trong 27 phút.
Các con số, thời gian và mức độ tự chủ được tuyên bố này hiện vẫn là tự báo cáo. Hồ sơ công khai của Redis xác nhận các lỗi và bản sửa lỗi, nhưng không xác nhận số lượng Zero-Day được tuyên bố hoặc mức độ độc lập của các tác nhân AI khi làm việc.
Redis 6.2.22 và 7.4.9 từng là đích đến của bản cập nhật tháng 5. Đến tháng 7, cả hai đều cần một bản cập nhật khác. Hãy kiểm tra chính xác phiên bản nhánh, thay vì chỉ xem liệu Redis có "vừa mới được vá" hay không.
