Redis vá lỗ hổng cho phép chiếm quyền máy chủ qua RCE

[WhiteHat Team]

Một lỗ hổng vừa được phát hiện trong Redis có thể cho phép kẻ tấn công thực thi lệnh hệ điều hành từ xa trên máy chủ chạy cơ sở dữ liệu. Đáng chú ý, lỗ hổng này không được con người phát hiện mà do một công cụ AI tự động săn lỗi trong mã nguồn quy mô lớn tìm ra.
​

​

Lỗ hổng được định danh là CVE-2026-23479, tồn tại âm thầm hơn hai năm kể từ khi xuất hiện trong Redis 7.2.0 vào đầu năm 2023. Theo cơ sở dữ liệu lỗ hổng quốc gia NVD, lỗi có điểm CVSS 8,8/10, trong khi Redis đánh giá 7,7 theo chuẩn CVSS 4,0.

Điều khiến giới an ninh mạng đặc biệt lo ngại là Redis hiện nằm trong số những nền tảng cơ sở dữ liệu phổ biến nhất trên môi trường cloud, và rất nhiều hệ thống vẫn triển khai với cấu hình mặc định thiếu mật khẩu hoặc phân quyền lỏng lẻo.​

AI phát hiện lỗ hổng trong một trong những cơ sở dữ liệu phổ biến nhất thế giới​

Lỗ hổng được phát hiện bởi Team Xint Code, một công cụ AI chuyên phân tích mã nguồn để tìm lỗi bảo mật trong các dự án lớn. Theo mô tả từ Theori, hệ thống AI này có khả năng rà soát lượng lớn mã nguồn tự động và phát hiện các chuỗi lỗi phức tạp mà quá trình review thông thường có thể bỏ sót.

Nhóm nghiên cứu đã trình diễn khai thác thành công tại cuộc thi bảo mật ZeroDay.Cloud 2025 ở London vào cuối năm ngoái.

Theo phân tích từ Wiz, lỗ hổng xuất hiện do sự kết hợp của hai commit riêng biệt trong năm 2023. Từng thay đổi riêng lẻ không gây nguy hiểm, nhưng khi kết hợp lại đã tạo ra lỗi “use-after-free” nghiêm trọng trong cơ chế xử lý client bị block của Redis.

Điều đáng nói là lỗ hổng này đã vượt qua nhiều vòng rà soát bảo mật và tồn tại trong tất cả các nhánh ổn định của Redis suốt hơn hai năm.​

Lỗ hổng hoạt động như thế nào?​

Về bản chất, CVE-2026-23479 là lỗi use-after-free (CWE-416) nằm trong hàm unblockClientOnKey() thuộc file src/blocked.c.

Trong Redis, khi một lệnh bị chặn để chờ dữ liệu hoặc sự kiện, hệ thống sẽ “đánh thức” client tương ứng khi có thay đổi trên key. Tuy nhiên, sau khi xử lý lệnh bằng hàm processCommandAndResetClient(), Redis vẫn tiếp tục sử dụng con trỏ tới client cũ dù đối tượng này có thể đã bị giải phóng khỏi bộ nhớ.

Điều này tạo cơ hội cho hacker chèn dữ liệu giả vào vùng nhớ vừa được giải phóng và chiếm quyền kiểm soát luồng thực thi. Chuỗi khai thác công khai hiện nay diễn ra theo ba giai đoạn chính. Ở bước đầu tiên, hacker sử dụng một đoạn Lua script đơn giản để làm rò rỉ địa chỉ heap trong bộ nhớ Redis. Tiếp theo, kẻ tấn công thao túng cơ chế giới hạn bộ nhớ client, buộc Redis giải phóng client đang bị block rồi ngay lập tức chiếm lại vùng nhớ đó bằng một cấu trúc client giả mạo. Cuối cùng, Redis bị lợi dụng chính cơ chế quản lý bộ nhớ nội bộ để ghi đè con trỏ hàm trong Global Offset Table (GOT), chuyển hướng hàm strcasecmp() sang system(). Khi Redis xử lý lệnh tiếp theo, hệ thống thực chất sẽ chạy lệnh shell của hacker trên máy chủ.​

Vì sao lỗ hổng này đặc biệt nguy hiểm?​

Điểm nguy hiểm nằm ở việc Redis thường được triển khai với cấu hình mặc định rất rộng quyền.

Theo Wiz, phần lớn Redis trên môi trường cloud hiện không bật mật khẩu hoặc dùng chung tài khoản có đầy đủ đặc quyền như:​

• CONFIG​
• EVAL (Lua scripting)​
• Stream commands​
• Read/Write toàn bộ dữ liệu​

Điều này khiến hacker chỉ cần có phiên truy cập xác thực là có thể hoàn thành toàn bộ chuỗi khai thác.

Ngoài ra, Docker image chính thức của Redis cũng vô tình làm việc khai thác dễ dàng hơn do chỉ bật Partial RELRO, khiến bảng GOT vẫn có thể ghi đè trong thời gian chạy.

Các cơ chế bảo vệ như ASLR hay PIE gần như không giúp giảm thiểu rủi ro trong trường hợp này.​

Hậu quả có thể nghiêm trọng tới mức nào?​

Nếu bị khai thác thành công, hacker có thể:​

• Thực thi lệnh hệ điều hành trên máy chủ Redis​
• Cài backdoor hoặc mã độc​
• Đánh cắp dữ liệu trong database​
• Di chuyển ngang sang hệ thống nội bộ khác​
• Chiếm quyền hạ tầng cloud​
• Tấn công chuỗi cung ứng ứng dụng sử dụng Redis​

Do Redis thường được dùng làm cache, session store hoặc message queue cho nhiều ứng dụng lớn, việc bị chiếm quyền Redis có thể kéo theo rủi ro trên toàn bộ hệ sinh thái doanh nghiệp.

Các chuyên gia cảnh báo những Redis public-facing trên Internet là nhóm nguy hiểm nhất, đặc biệt nếu dùng chung tài khoản quản trị cho nhiều dịch vụ.​

Những phiên bản bị ảnh hưởng​

Redis xác nhận các phiên bản sau bị ảnh hưởng:​

• 7.2.0 → 7.2.13​
• 7.4.0 → 7.4.8​
• 8.2.0 → 8.2.5​
• 8.4.0 → 8.4.2​
• 8.6.0 → 8.6.2​

Các phiên bản đã vá gồm:​

• 7.2.14​
• 7.4.9​
• 8.2.6​
• 8.4.3​
• 8.6.3​

Theo Redis, các bản cập nhật minor này có thể nâng cấp trực tiếp mà không cần thay đổi kiến trúc triển khai.​

Người dùng và quản trị viên cần làm gì?​

Redis cho biết chưa ghi nhận dấu hiệu lỗ hổng bị khai thác ngoài thực tế. Tuy nhiên, do mã khai thác kỹ thuật đã được công khai hoàn chỉnh, nguy cơ xuất hiện các cuộc tấn công thực tế trong thời gian tới là rất cao.

Các chuyên gia khuyến nghị quản trị viên:​

• Nâng cấp Redis ngay lên phiên bản đã vá​
• Không public Redis trực tiếp ra Internet​
• Bật TLS và xác thực đầy đủ​
• Tách riêng quyền CONFIG, scripting và admin​
• Vô hiệu hóa Lua scripting nếu không cần thiết​
• Kiểm tra các Redis dùng chung tài khoản quản trị​
• Thay đổi mật khẩu Redis đang được dùng rộng rãi​
• Giám sát hành vi thực thi lệnh bất thường​

Trong trường hợp chưa thể vá ngay, việc chặn quyền CONFIG và @scripting có thể ngăn chuỗi khai thác hiện tại, dù không loại bỏ tận gốc lỗi use-after-free.​

Một tín hiệu mới cho tương lai của an ninh mạng AI​

CVE-2026-23479 không chỉ nguy hiểm vì ảnh hưởng tới Redis mà còn vì cách nó được phát hiện. Đây là một trong những trường hợp nổi bật cho thấy AI bắt đầu đóng vai trò thực tế trong việc săn tìm lỗ hổng phức tạp ở quy mô lớn. Hai commit nhỏ, tồn tại suốt hai năm và vượt qua nhiều vòng kiểm tra bảo mật, cuối cùng lại bị phát hiện bởi một hệ thống AI tự động.

Sự kiện này cho thấy cuộc đua giữa AI phòng thủ và AI tấn công trong an ninh mạng đang bước sang một giai đoạn hoàn toàn mới.​