Công cụ AI tự động phát hiện lỗ hổng RCE trong Redis

Bizfly Cloud

1384

05-06-2026

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

Redis đã vá một lỗ hổng use-after-free trong cơ chế xử lý blocking client, cho phép một người dùng đã được xác thực (authenticated) thực thi các lệnh hệ điều hành tùy ý trên máy chủ đang chạy cơ sở dữ liệu. Lỗ hổng này được phát hiện bởi một công cụ AI tự động được xây dựng để săn tìm lỗi trong các kho mã nguồn lớn.

Được theo dõi với mã CVE-2026-23479, lỗ hổng xuất hiện từ phiên bản Redis 7.2.0 và tồn tại trong tất cả các nhánh ổn định cho đến khi bản vá được phát hành vào ngày 5/5, mà không bị phát hiện trong hơn hai năm. Cơ sở dữ liệu lỗ hổng quốc gia (NVD) đánh giá mức độ nghiêm trọng là 8,8 điểm theo thang CVSS 3.1, trong khi Redis đánh giá là 7,7 điểm theo CVSS 4.0. Lỗ hổng được báo cáo bởi Team Xint Code, và hiện tài liệu phân tích kỹ thuật chi tiết đã được công khai.

Mức độ ảnh hưởng càng đáng lo ngại hơn do Redis được triển khai rất rộng rãi trên môi trường đám mây. Theo phân tích của Wiz, được công bố cùng với bài viết mô tả cách khai thác, Redis xuất hiện trong phần lớn các môi trường cloud, và đa số các phiên bản Redis đó đang chạy không có mật khẩu. Dù việc khai thác yêu cầu một phiên làm việc đã được xác thực, nhưng trong cấu hình mặc định, tài khoản người dùng mặc định vốn đã có đầy đủ các quyền cần thiết để thực hiện toàn bộ chuỗi tấn công này.

Lỗ hổng nằm trong hàm unblockClientOnKey() của tệp src/blocked.c, được gọi khi một sự kiện trên khóa (key event) đánh thức một lệnh đang bị chặn (blocked command).

Hàm này chuyển tiếp lệnh đang chờ xử lý thông qua processCommandAndResetClient(), sau đó tiếp tục sử dụng cùng một con trỏ (pointer) tới client. Vấn đề nằm ở chỗ: hàm processCommandAndResetClient() có thể giải phóng (free) bộ nhớ của client như một tác dụng phụ trong quá trình thực thi, và chính phần chú thích trong mã nguồn của hàm này cũng đã nêu rõ điều đó. Tuy nhiên, hàm gọi lại bỏ qua giá trị trả về và vẫn tiếp tục truy cập vào cấu trúc dữ liệu của client đã bị giải phóng, dẫn đến lỗi use-after-free (CWE-416).

Theo phân tích của Wiz, phải mất hai lần thay đổi mã nguồn (commit) mới vô tình tạo ra lỗ hổng này:

• Một đợt tái cấu trúc mã vào tháng 1/2023 (PR #11012) đã thêm lời gọi hàm mà không kiểm tra kết quả trả về.

• Một thay đổi khác vào tháng 3/2023 (PR #11568) bổ sung thêm các thao tác truy cập client sau lời gọi hàm đó.

Mỗi thay đổi riêng lẻ đều không nguy hiểm. Tuy nhiên, khi kết hợp với nhau, chúng tạo thành một chuỗi lỗi hoàn chỉnh, được phát hành rộng rãi từ Redis 7.2.0 và tồn tại qua nhiều vòng rà soát bảo mật mà không bị phát hiện.

Chuỗi tấn công bắt đầu bằng việc rò rỉ địa chỉ heap. Từ đó, nó giải phóng một client và chèn một client giả vào cùng memory, sau đó lợi dụng chính cơ chế quản lý memory của Redis để ghi đè lên (function pointer) con trỏ hàm.

Phiên bản được published chạy qua ba giai đoạn.

• Đầu tiên, một one-line Lua script (EVAL "return tostring(redis.call)" 0) làm rò rỉ heap pointer.
• Thứ hai, hacker điều chỉnh giới hạn memory của client, đặt một client có kích thước lớn vào một stream, sau đó bỏ giới hạn và đánh thức client đó. Redis giải phóng client bị chặn giữa chừng cuộc gọi hàm, một lệnh SET được gửi thông qua cơ chế pipelining sẽ nhanh chóng chiếm lại đúng vùng bộ nhớ vừa được giải phóng và ghi vào đó một cấu trúc client giả mạo.
• Thứ ba, cơ chế quản lý bộ nhớ thường xuyên của Redis trong hàm updateClientMemoryUsage() thực hiện việc giảm giá trị ngoài phạm vi bộ nhớ hợp lệ (out-of-bounds decrement) do attacker kiểm soát, nhắm vào Global Offset Table (bảng chứa địa chỉ các hàm thư viện được chương trình sử dụng) để trỏ lại hàm strcasecmp() vào hàm system(). Lệnh tiếp theo mà Redis phân tích cú pháp sẽ chạy dưới dạng lệnh shell.

Docker image chính thức của Redis giúp bước cuối cùng dễ dàng hơn. Nó chỉ đi kèm với quyền RELRO một phần, cho phép ghi vào GOT trong quá trình chạy. ASLR và PIE không giúp ích gì ở đây, vì thao tác ghi phụ thuộc vào một biến toàn cục (global) có offset cố định trong quá trình xây dựng.

Chuỗi đầy đủ cần một phiên xác thực với các lệnh CONFIG SET, EVAL, lệnh luồng (XREAD/XADD) và SET/GET cơ bản, tương ứng với các danh mục ACL @admin, @scripting, @stream và @read/@write.

Người dùng mặc định có tất cả các quyền này, và trong phần lớn các môi trường triển khai, những quyền đó được gộp vào một vai trò dùng chung cho ứng dụng hoặc người vận hành hệ thống. Việc từ chối hoàn toàn quyền sử dụng CONFIG sẽ ngăn chặn chuỗi khai thác cụ thể này, nhưng không khắc phục được lỗi use-after-free bên dưới. 

Nhóm Xint Code đã chứng minh lỗ hổng thực thi mã từ xa (RCE) hoạt động tại ZeroDay.Cloud 2025, cuộc thi hack của Wiz ở London vào tháng 12 năm ngoái. Theori mô tả Xint Code là một công cụ bảo mật AI tự động được xây dựng để tìm lỗi trong các codebase lớn.

Redis cho biết họ không có bằng chứng về việc khai thác trong môi trường của riêng họ hoặc của khách hàng. Tính đến thời điểm bài viết được công bố, cũng chưa xuất hiện báo cáo công khai nào về việc lỗ hổng bị khai thác ngoài thực tế. Tuy nhiên, toàn bộ chuỗi khai thác kỹ thuật hiện đã được công khai, làm gia tăng nguy cơ xuất hiện các cuộc tấn công khai thác tiếp theo. 

Nâng cấp lên phiên bản vá lỗi tương ứng với nhánh bạn đang sử dụng: 7.2.14, 7.4.9, 8.2.6, 8.4.3 hoặc 8.6.3, tất cả đều được phát hành vào ngày 5/5. Các bản nâng cấp nhỏ (minor upgrade) trong cùng một nhánh được thiết kế để có thể thay thế trực tiếp mà không cần thay đổi đáng kể.

Đối với các dịch vụ Redis được quản lý (managed Redis services), việc vá lỗi sẽ được thực hiện theo lịch trình riêng của từng nhà cung cấp. Redis cho biết dịch vụ Redis Cloud đã hoàn tất việc triển khai bản vá.

Nếu bạn chưa thể vá lỗi ngay: không nên sử dụng Redis trên public internet và bảo vệ bằng TLS, thắt chặt ACL để không có vai trò nào nắm giữ cùng lúc các quyền @admin, CONFIG và @scripting. Cùng với đó từ chối quyền @scripting nếu bạn không sử dụng Lua, điều này sẽ chặn được giai đoạn rò rỉ thông tin ở Bước 1 của chuỗi khai thác. 

Ưu tiên xử lý các phiên bản Redis được công khai trên Internet, thông tin đăng nhập ứng dụng dùng chung và bất kỳ vai trò nào kết hợp quyền CONFIG, scripting và truy cập stream . Đồng thời, hãy thay đổi thông tin đăng nhập Redis đang được chia sẻ và sử dụng chung cho tất cả các trường hợp.

CVE-2026-23479 là 1 trong 5 lỗ hổng Redis thuộc loại RCE được công bố tháng trước, và nó là  lỗ hổng kế tiếp của RediShell năm 2025 của Redis, một lỗ hổng sử dụng use-after-free khác liên quan đến Lua scripting. Đây cũng là lỗ hổng được một công cụ AI phát hiện. Hai thay đổi mã nguồn (commit) đã vô tình tạo ra nó,  hai năm không được phát hiện, và nó nằm trong một trong những database được triển khai nhiều nhất cho đến khi một cuộc thi hack phát hiện ra. Việc rà soát mã nguồn (code review) thông thường đã không phát hiện ra nó. 

Bizfly Cloud tổng hợp