RabbitMQ vá khẩn cấp 2 lỗ hổng có thể làm lộ dữ liệu và chiếm quyền quản trị

[WhiteHat Team]

Các nhà nghiên cứu bảo mật từ Miggo vừa công bố hai lỗ hổng trong RabbitMQ, nền tảng Message Broker mã nguồn mở phổ biến nhất hiện nay. Một trong hai lỗ hổng cho phép kẻ tấn công không cần xác thực đánh cắp thông tin OAuth bí mật và chiếm quyền quản trị hệ thống, trong khi lỗ hổng còn lại có thể khiến người dùng thông thường âm thầm theo dõi dữ liệu của các tổ chức hoặc ứng dụng khác đang sử dụng chung hạ tầng.
​

Mặc dù chưa ghi nhận dấu hiệu bị khai thác trong thực tế, mức độ ảnh hưởng của các lỗ hổng này được đánh giá rất đáng lo ngại bởi RabbitMQ hiện là thành phần cốt lõi trong nhiều hệ thống doanh nghiệp, dịch vụ đám mây và ứng dụng hiện đại trên toàn cầu.​

RabbitMQ là gì và vì sao lỗ hổng này đáng lo ngại?​

RabbitMQ là nền tảng trung gian xử lý và truyền tải thông điệp được sử dụng rộng rãi trong các hệ thống phân tán và kiến trúc microservices.

Trong thực tế, RabbitMQ thường đảm nhiệm việc chuyển tiếp các sự kiện quan trọng như:​

• Xử lý đơn hàng thương mại điện tử.​
• Giao dịch thanh toán.​
• Xác thực người dùng.​
• Đồng bộ dữ liệu giữa các dịch vụ.​
• Kết nối giữa các ứng dụng trong môi trường doanh nghiệp.​

Theo Miggo, RabbitMQ hiện đạt hơn 15 triệu lượt tải mỗi năm và được sử dụng trong khoảng 8% container đang hoạt động trên toàn thế giới. Điều đó đồng nghĩa nếu một máy chủ RabbitMQ bị chiếm quyền, tin tặc có thể tiếp cận lượng lớn dữ liệu nhạy cảm đang được trao đổi giữa các hệ thống.​

CVE-2026-57219: Lỗ hổng cho phép chiếm quyền quản trị mà không cần đăng nhập​

Lỗ hổng nguy hiểm nhất được định danh là CVE-2026-57219, có điểm CVSS 8,7/10. Điểm đáng lo ngại là kẻ tấn công không cần xác thực vẫn có thể khai thác.

Giao diện quản trị RabbitMQ tồn tại một API cũ có tên: GET /api/auth

API này vô tình công khai toàn bộ cấu hình OAuth của hệ thống, bao gồm cả trường cực kỳ nhạy cảm: oauth_client_secret

Đây là khóa bí mật được sử dụng khi RabbitMQ kết nối với các hệ thống xác thực như:​

• Microsoft Entra ID (Azure AD)​
• Auth0​
• Keycloak​
• Cloud Foundry UAA​

Nếu lấy được khóa bí mật này, kẻ tấn công có thể yêu cầu cấp OAuth Token hợp lệ với quyền cao nhất, từ đó chiếm quyền kiểm soát toàn bộ RabbitMQ.​

Nguyên nhân kỹ thuật của lỗ hổng​

Quá trình điều tra cho thấy nguyên nhân lại đến từ một lỗi lập trình rất đơn giản. Trong khi các API quản trị khác đều yêu cầu xác thực quyền truy cập, API /api/auth sử dụng hàm: is_authorized/2

Tuy nhiên hàm này lại được lập trình để luôn trả về giá trị "true", đồng nghĩa mọi yêu cầu đều được xem là hợp lệ. Nói cách khác, bất kỳ ai có thể truy cập giao diện quản trị RabbitMQ đều có thể lấy được thông tin OAuth bí mật mà không cần đăng nhập.​

Kẻ tấn công có thể làm gì sau khi khai thác?​

Sau khi sở hữu OAuth Secret, tin tặc có thể:​

• Tạo hoặc chiếm quyền tài khoản quản trị.​
• Đọc toàn bộ thông điệp đang được truyền tải.​
• Chỉnh sửa hoặc xóa Queue.​
• Thay đổi cấu hình RabbitMQ.​
• Thêm người dùng mới.​
• Can thiệp vào luồng xử lý dữ liệu của ứng dụng.​

Trong nhiều doanh nghiệp, điều này đồng nghĩa với khả năng kiểm soát toàn bộ hệ thống giao tiếp giữa các ứng dụng nội bộ.​

CVE-2026-57221: Người dùng thông thường có thể theo dõi dữ liệu của người khác​

Lỗ hổng thứ hai được định danh là CVE-2026-57221, có điểm CVSS 5,3/10. Mặc dù mức độ nghiêm trọng thấp hơn, đây vẫn là vấn đề đáng lo ngại trong các môi trường đa khách hàng. Lỗ hổng xuất hiện trong tính năng Passive Declare của RabbitMQ. Đây là cơ chế cho phép kiểm tra xem Queue hoặc Exchange có tồn tại hay không mà không tạo mới chúng.

Thông thường thao tác này phải trải qua bước kiểm tra quyền truy cập. Tuy nhiên do lỗi trong mã nguồn, cơ chế kiểm tra quyền đã bị bỏ qua hoàn toàn.​

Kẻ tấn công có thể khai thác như thế nào?​

Chỉ cần có một tài khoản RabbitMQ hợp lệ, kể cả tài khoản không được cấp quyền truy cập dữ liệu, người dùng vẫn có thể:​

• Liệt kê các Queue trong hệ thống.​
• Liệt kê Exchange của các ứng dụng khác.​
• Theo dõi thống kê lưu lượng.​
• Xem số lượng người tiêu thụ (Consumer).​
• Quan sát hoạt động của các tenant khác.​

Trong môi trường nhiều doanh nghiệp hoặc nhiều ứng dụng cùng sử dụng chung RabbitMQ, đây là nguồn thông tin tình báo giá trị giúp kẻ tấn công xây dựng các cuộc tấn công tiếp theo.​

Nguyên nhân xuất phát từ một lỗi lập trình nhỏ​

Miggo cho biết nguyên nhân của CVE-2026-57221 bắt nguồn từ quy tắc đặt tên biến trong mã nguồn.

Một biến liên quan đến kiểm tra quyền truy cập bị đánh dấu là "không sử dụng", dẫn tới việc cơ chế xác thực vô tình bị vô hiệu hóa. Đây là ví dụ điển hình cho thấy những lỗi rất nhỏ trong quá trình phát triển phần mềm có thể tạo ra các lỗ hổng bảo mật nghiêm trọng.​

Phạm vi ảnh hưởng​

Cả hai lỗ hổng đều tồn tại từ phiên bản: RabbitMQ 3.13.0 (đầu năm 2024). Các phiên bản bị ảnh hưởng bao gồm phần lớn các hệ thống RabbitMQ được triển khai trong khoảng hơn hai năm trở lại đây.

Hiện chưa ghi nhận trường hợp bị khai thác ngoài thực tế. Tuy nhiên do thông tin kỹ thuật đã được công bố công khai, nguy cơ xuất hiện các cuộc tấn công trong thời gian tới là hoàn toàn có thể xảy ra.​

AI đã phát hiện lỗ hổng như thế nào?​

Điểm thú vị của nghiên cứu lần này là Miggo sử dụng hệ thống AI để tìm kiếm các bất thường trong cơ chế kiểm soát truy cập.

Theo nhóm nghiên cứu, các tác nhân AI (AI Agents) liên tục so sánh:​

• Các API có cơ chế xác thực khác nhau.​
• Các chức năng tương tự nhưng kiểm tra quyền khác nhau.​
• Các đoạn mã có dấu hiệu bỏ sót bước xác thực.​

Một chiến dịch phân tích RabbitMQ kéo dài khoảng 7 giờ, trong đó AI đã kiểm tra 206 giả thuyết bảo mật khác nhau trước khi xác định được hai lỗ hổng này.

Điều này phản ánh xu hướng mới trong lĩnh vực an ninh mạng, khi AI ngày càng được sử dụng để rà soát những hệ thống mã nguồn lớn và phức tạp.​

Đã có bản vá hay chưa?​

RabbitMQ đã phát hành bản vá cho cả hai lỗ hổng. Các tổ chức cần nâng cấp ngay lên một trong các phiên bản:​

• RabbitMQ 4.3.0​
• RabbitMQ 4.2.6​
• RabbitMQ 4.1.11​
• RabbitMQ 4.0.20​
• RabbitMQ 3.13.15​

Chuyên gia khuyến nghị gì?​

Khuyến nghị các quản trị viên cần gấp rút để ý:​

• Nâng cấp RabbitMQ lên phiên bản đã vá càng sớm càng tốt.​
• Thay đổi (rotate) OAuth Client Secret nếu giao diện quản trị từng được truy cập từ Internet.​
• Kiểm tra các container image, máy ảo và triển khai Kubernetes đang sử dụng RabbitMQ phiên bản cũ.​
• Tách biệt khách hàng hoặc ứng dụng bằng Virtual Host (vHost) riêng thay vì dùng chung.​
• Theo dõi các truy cập bất thường tới giao diện quản trị RabbitMQ.​
• Rà soát lịch sử cấp quyền OAuth để phát hiện dấu hiệu lộ lọt thông tin xác thực.​