Lỗ hổng CVE-2026-110720: Nguy cơ leo thang đặc quyền trong HashiCorp Consul-k8s

• Lỗ hổng định danh: CVE-2026-110720 ảnh hưởng đến các phiên bản Consul-k8s từ 0.42.0 đến 2.0.4.
• Cơ chế lỗi: Sai sót trong việc ràng buộc quy tắc ACL cho phép thực thể từ namespace khác chiếm quyền điều khiển.
• Điều kiện khai thác: Yêu cầu cấu hình global.acls.manageSystemACLs=true và quyền tạo ServiceAccount trong Kubernetes.
• Khuyến nghị: Nâng cấp ngay lập tức lên phiên bản 2.1.0 hoặc 1.8.18 để khắc phục rủi ro.

HashiCorp vừa chính thức công bố bản vá bảo mật cho một lỗ hổng nghiêm trọng liên quan đến cơ chế bỏ qua xác thực (authorization bypass) trong thành phần Consul-k8s. Lỗ hổng này, được định danh là CVE-2026-110720, cho phép kẻ tấn công có quyền truy cập vào một Kubernetes namespace có thể leo thang đặc quyền Consul từ các namespace khác, gây ra rủi ro lớn cho tính toàn vẹn của hệ thống quản lý cấu hình và dịch vụ.

Phân tích kỹ thuật lỗ hổng CVE-2026-110720

Lỗ hổng này xuất phát từ cách thức Consul-k8s quản lý các quy tắc kiểm soát truy cập (ACL) tự động. Khi tính năng global.acls.manageSystemACLs được kích hoạt, hệ thống sẽ tự động thiết lập các quy tắc xác thực và ràng buộc giữa Kubernetes ServiceAccount và các vai trò (role) tương ứng trong Consul để các thành phần có thể lấy được token xác thực.

Tuy nhiên, các nhà nghiên cứu bảo mật đã phát hiện ra rằng các quy tắc ràng buộc này không thực hiện kiểm tra nghiêm ngặt phạm vi (scope) của ServiceAccount. Cụ thể, hệ thống không giới hạn quyền xác thực chỉ trong phạm vi namespace đang lưu trữ triển khai Consul. Điều này tạo ra một kẽ hở cho phép một thực thể (identity) từ một namespace khác có thể mạo danh thành phần Consul và nhận được các đặc quyền tương ứng của thành phần đó.

Ma trận tác động và điều kiện khai thác

Để thực hiện khai thác thành công, kẻ tấn công cần đáp ứng một số điều kiện tiên quyết cụ thể. Đây không phải là một lỗ hổng có thể khai thác từ xa bởi người dùng không xác thực trên internet mà đòi hỏi quyền truy cập nội bộ vào cụm Kubernetes.

• Quyền hạn yêu cầu: Kẻ tấn công phải có khả năng tạo ServiceAccount và lấy token của nó trong một namespace bất kỳ thuộc cụm Kubernetes.
• Khả năng kết nối: Kẻ tấn công cần có quyền truy cập mạng tới Consul API để gửi các yêu cầu xác thực giả mạo.
• Cấu hình mục tiêu: Lỗ hổng chỉ tồn tại khi tham số global.acls.manageSystemACLs được đặt là true.

Dưới đây là bảng tổng hợp các thông tin kỹ thuật liên quan đến lỗ hổng này:

Hướng dẫn xử lý và giảm thiểu rủi ro

Các đội ngũ vận hành hệ thống (DevOps/SecOps) cần thực hiện rà soát ngay lập tức cấu hình triển khai Consul-k8s của mình. Việc kiểm tra phiên bản đơn thuần là chưa đủ, cần phải xác minh xem tính năng quản lý ACL hệ thống có đang được bật hay không.

⚠️ Cảnh báo quan trọng: Nếu hệ thống của bạn đang sử dụng global.acls.manageSystemACLs=true, hãy ưu tiên lập kế hoạch nâng cấp lên phiên bản 2.1.0 hoặc 1.8.18 trong thời gian sớm nhất. Nếu chưa thể nâng cấp ngay, hãy cân nhắc tạm thời vô hiệu hóa tính năng quản lý ACL tự động nếu quy trình nghiệp vụ cho phép.

Để kiểm tra cấu hình hiện tại, bạn có thể kiểm tra file cấu hình Helm hoặc các tham số triển khai của Consul-k8s:

# Kiểm tra cấu hình trong file values.yaml của Helm chart global:  acls:    manageSystemACLs: true # Nếu là true, hệ thống của bạn đang nằm trong diện rủi ro

Việc bảo mật các API endpoint và kiểm soát chặt chẽ quyền tạo ServiceAccount trong Kubernetes là chìa khóa để ngăn chặn các cuộc tấn công leo thang đặc quyền tương tự. Các nhà nghiên cứu bảo mật, bao gồm Elias Hasas (zer0d4y5), đã nhấn mạnh tầm quan trọng của việc đánh giá khả năng tiếp cận API khi thiết kế kiến trúc hạ tầng. Mọi thông tin chi tiết về bản vá có thể tham khảo thêm tại HashiCorp Security Advisory.