Công cụ AI tự hành phát hiện lỗ hổng RCE tồn tại 2 năm trong Redis (CVE-2026-23479)

Redis vừa phát hành bản vá cho một lỗ hổng use-after-free nghiêm trọng trong mã nguồn xử lý client bị chặn (blocking-client). Lỗ hổng này, được định danh là CVE-2026-23479, cho phép người dùng đã xác thực thực thi các lệnh hệ điều hành tùy ý trên máy chủ chạy cơ sở dữ liệu. Điểm đáng chú ý là lỗ hổng này đã tồn tại trong mọi phiên bản ổn định của Redis kể từ bản 7.2.0 (tháng 1/2023) cho đến khi được khắc phục vào ngày 5/5 vừa qua.

Chi tiết kỹ thuật về lỗ hổng

Lỗ hổng nằm trong hàm unblockClientOnKey() thuộc tệp src/blocked.c. Vấn đề phát sinh khi một sự kiện khóa (key event) kích hoạt một lệnh bị chặn. Hàm này thực hiện điều phối lệnh thông qua processCommandAndResetClient() nhưng vẫn tiếp tục sử dụng con trỏ client cũ, trong khi hàm này có khả năng giải phóng (free) client đó. Kết quả là một lỗi use-after-free (CWE-416) xảy ra khi chương trình cố gắng truy cập vào vùng nhớ đã bị giải phóng.

Theo phân tích từ Wiz, lỗ hổng này là kết quả của hai lần thay đổi mã nguồn (commit) riêng biệt vào đầu năm 2023. Mặc dù mỗi thay đổi khi đứng độc lập không gây nguy hiểm, nhưng khi kết hợp lại, chúng đã tạo ra một kịch bản khai thác RCE hoàn chỉnh.

Quy trình khai thác

Kẻ tấn công có thể khai thác lỗ hổng này qua ba giai đoạn:

Rò rỉ bộ nhớ: Sử dụng một đoạn script Lua đơn giản để rò rỉ con trỏ heap.
Grooming bộ nhớ: Tận dụng cơ chế quản lý bộ nhớ của Redis để giải phóng một client bị chặn và thay thế bằng một cấu trúc client giả mạo.
Thực thi mã: Ghi đè con trỏ hàm trong bảng Global Offset Table (GOT) để trỏ đến hàm system(), từ đó thực thi lệnh shell trên máy chủ.

Do Docker image chính thức của Redis sử dụng cơ chế bảo mật partial RELRO, bảng GOT vẫn có thể ghi được tại thời điểm chạy (runtime), khiến việc khai thác trở nên khả thi hơn.

Khuyến nghị bảo mật

Redis đã phát hành các bản vá trong các phiên bản 7.2.14, 7.4.9, 8.2.6, 8.4.3 và 8.6.3. Người dùng được khuyến cáo cập nhật lên phiên bản mới nhất ngay lập tức.

Trong trường hợp chưa thể cập nhật, các quản trị viên cần thực hiện các biện pháp giảm thiểu rủi ro:

Cách ly Redis khỏi internet công cộng và sử dụng TLS.
Thắt chặt các quy tắc ACL: Không cấp quyền @admin, CONFIG và @scripting cho cùng một vai trò người dùng.
Vô hiệu hóa @scripting nếu không sử dụng Lua để ngăn chặn giai đoạn rò rỉ bộ nhớ đầu tiên.

Lỗ hổng này là minh chứng cho thấy ngay cả những dự án phần mềm lớn cũng có thể ẩn chứa các lỗi nghiêm trọng trong thời gian dài mà các phương pháp kiểm duyệt mã nguồn truyền thống bỏ sót, đồng thời nhấn mạnh vai trò của các công cụ AI trong việc tự động hóa tìm kiếm lỗ hổng (fuzzing/bug hunting).

Nguồn tham khảo: The Hacker News