CVE-2026-66077 in RabbitMQ
Tóm tắt
Bởi VulDB • 23/09/2026
RabbitMQ là một broker tin nhắn và streaming. Trước các phiên bản 3.13.15, 4.0.20, 4.1.11 và 4.2.6, giao diện quản lý (management UI) sử dụng EJS 1.0 trong đó `<%= ... %>` KHÔNG thực hiện HTML-escape. File connection.ejs:135 render trực tiếp giá trị của `<%= connection.ssl_details.peer_cert_subject %>` (và peer_cert_issuer) vào trang. Mẫu tương tự xuất hiện tại streamConnection.ejs:102, 106, 110. Các giá trị này đến từ hàm rabbit_ssl:peer_cert_subject/1, định dạng DN dưới dạng chuỗi mà không thực hiện HTML-escape. Người xác minh (verifier) đã sửa đổi tuyên bố của nhà nghiên cứu ban đầu: lỗ hổng này chỉ có thể khai thác khi listener được cấu hình với verify_peer (do đó chứng thư số phải do một CA trong trust store của broker ký, chứ không phải tự ký tùy ý); tuy nhiên, trong các triển khai sử dụng mTLS cho xác thực client, bất kỳ người dùng nào có khả năng yêu cầu chứng chỉ từ CA tổ chức đều kiểm soát được Subject CN. Một kẻ tấn công có thể lấy được chứng chỉ client TLS do một CA mà broker tin tưởng ký (với verify_peer được bật) có thể nhúng JavaScript vào DN của Subject trong chứng thư số. Khi bất kỳ quản trị viên nào xem kết nối đó trên giao diện quản lý, script sẽ thực thi trong phiên trình duyệt của quản trị viên, cho phép chiếm quyền kiểm soát tài khoản toàn bộ (tạo người dùng, xuất định nghĩa cấu hình, v.v.). Chính sách bảo mật nội dung (CSP) của giao diện quản lý bao gồm 'unsafe-inline', do đó việc thực thi script inline không bị chặn. Các điều kiện tiên quyết bao gồm: listener TLS được cấu hình với ssl_options.verify = verify_peer; kẻ tấn công có thể lấy chứng chỉ client ký bởi CA với Subject do kẻ tấn công chọn (ví dụ: PKI doanh nghiệp tự phục vụ, hoặc plugin rabbitmq_trust_store đang được sử dụng); quản trị viên xem trang chi tiết kết nối. Vấn đề này đã được sửa trong các phiên bản 3.13.15, 4.0.20, 4.1.11 và 4.2.6.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.