Lỗ hổng nghiêm trọng trên LXD và MicroCloud cho phép truy cập root mà không cần khóa riêng tư

Canonical đã phát hành các bản vá khẩn cấp cho một lỗ hổng bảo mật nghiêm trọng trong trình siêu ảo hóa container LXD và công cụ cụm MicroCloud. Lỗ hổng này được theo dõi với mã CVE-2026-112816, mang mức độ nghiêm trọng tối đa là 10.0 trên Hệ thống Đánh giá Điểm Lỗ hổng Chung (CVSS). Nó cho phép kẻ tấn công từ xa giả mạo các client đáng tin cậy và giành quyền truy cập trái phép vào cơ sở hạ tầng mà không cần sở hữu các khóa mật mã riêng tư cần thiết.

Chuyện gì đã xảy ra

Lỗi này cho phép kẻ tấn công đăng nhập dưới dạng client đáng tin cậy bằng cách khai thác một sai sót trong quá trình xác thực TLS song phương. Để thành công, kẻ tấn công cần có quyền truy cập mạng vào API HTTPS và chứng chỉ công khai của một client mà máy chủ đã tin tưởng. Sau khi được xác thực, kẻ tấn công sẽ hoạt động như client đó, giành toàn quyền truy cập vào cụm và các máy ảo của nó. Nếu tài khoản bị giả mạo có đặc quyền cao, kẻ tấn công có thể leo thang lên quyền truy cập root trên chính máy chủ.

Vấn đề này ban đầu được báo cáo bởi dự án Incus, một phiên bản fork cộng đồng của LXD, nơi xác nhận rằng lỗi ảnh hưởng đến cả hai nền tảng. Trong khi các gói chuẩn trong kho lưu trữ của Ubuntu dành cho LXD không bị ảnh hưởng, người dùng chạy LXD hoặc MicroCloud thông qua các gói Snap vẫn gặp rủi ro. Canonical tuyên bố rằng chưa có bằng chứng nào cho thấy lỗ hổng này đã bị khai thác trong thực tế, và hiện tại nó không xuất hiện trong danh sách Các lỗ hổng bị khai thác đã biết của CISA. Tuy nhiên, tác động tiềm tàng đủ nghiêm trọng để đòi hỏi sự chú ý ngay lập tức từ các đội ngũ quản trị cơ sở hạ tầng.

Cơ chế hoạt động

LXD và MicroCloud sử dụng TLS song phương (mTLS) để bảo vệ quyền truy cập API từ xa. Trong cấu hình này, một client chứng minh danh tính của mình bằng cách trình bày một chứng chỉ kỹ thuật số. Máy chủ kiểm tra chứng chỉ này so với một kho lưu trữ tin cậy, chứa danh tính của tất cả các client được phép. Lỗ hổng nằm ở cách máy chủ xác thực chuỗi chứng chỉ trong quá trình bắt tay này.

Trong một kết nối TLS tiêu chuẩn, giao thức chỉ chứng minh về mặt mật mã rằng client sở hữu khóa riêng tư cho chứng chỉ đầu tiên trong chuỗi, được gọi là chứng chỉ lá (leaf certificate). Phần còn lại của chuỗi chỉ đơn thuần là dữ liệu do client đính kèm. Cách triển khai lỗi trong LXD đã so sánh mọi chứng chỉ trong chuỗi được cung cấp với kho lưu trữ tin cậy, thay vì chỉ xác thực nghiêm ngặt chứng chỉ lá. Kẻ tấn công có thể lấy chứng chỉ công khai của một client đáng tin cậy, vốn không phải là bí mật, và đính kèm nó vào chuỗi của riêng họ. Máy chủ sau đó sẽ nhầm lẫn chấp nhận kẻ tấn công là client đáng tin cậy vì nó tìm thấy một khớp trong chuỗi, mặc dù kẻ tấn công không sở hữu khóa riêng tư tương ứng cho chứng chỉ cụ thể đó.

Chi tiết chính

• ID lỗ hổng: CVE-2026-112816 với điểm CVSS là 10.0.
• Sản phẩm bị ảnh hưởng: Các phiên bản LXD 4.0.14, 5.0.10, 5.21.8 và 6.9, cùng với các cụm MicroCloud.
• Phiên bản đã sửa lỗi: LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15 và MicroCloud 3.4.1 hoặc 2.1.5 thông qua các kênh Snap.
• Yêu cầu tấn công: Quyền truy cập mạng vào API HTTPS và sở hữu chứng chỉ công khai của một client đáng tin cậy.
• Nguồn gốc: Được báo cáo bởi dự án Incus, nơi đã phát hành bản sửa lỗi riêng trong phiên bản 7.6.0.
• Trạng thái khai thác: Tính đến ngày 30 tháng 10 năm 2026, chưa có vụ khai thác tích cực nào được biết đến hay mã khai thác công khai tồn tại.

Tại sao điều này quan trọng

Đối với các kỹ sư quản lý cơ sở hạ tầng đóng gói container, lỗ hổng này làm suy yếu mô hình tin cậy cơ bản của mTLS. TLS song phương thường được dựa vào như một cơ chế xác thực mạnh mẽ vì nó yêu cầu sở hữu khóa riêng tư. Lỗi này bỏ qua hoàn toàn yêu cầu đó, nghĩa là chỉ cần có một chứng chỉ công khai, vốn thường được phân phối rộng rãi hoặc thu thập trong quá trình tham gia mạng, là đủ để giả mạo. Điều này đặc biệt nguy hiểm đối với các môi trường MicroCloud, nơi kẻ tấn công có thể thu thập chứng chỉ công khai của một thành viên trong quá trình tham gia cụm và sau đó giả mạo thành viên đó.

Tác động vượt ra ngoài việc truy cập dữ liệu đơn giản. Vì LXD quản lý các container cấp hệ thống, việc giả mạo thành công một client có đặc quyền có thể dẫn đến việc chiếm quyền kiểm soát toàn bộ máy chủ. Điều này cấp cho kẻ tấn công quyền truy cập root vào máy vật lý hoặc máy ảo bên dưới, cho phép chúng thoát khỏi môi trường container hoàn toàn. Đối với các nhóm sử dụng LXD trong môi trường sản xuất, đặc biệt là những nhóm tiếp xúc API qua mạng, đây đại diện cho một thất bại nghiêm trọng trong kiểm soát truy cập không thể giảm thiểu chỉ bằng các thay đổi cấu hình.

Bạn có thể làm gì

• Cập nhật ngay lập tức các cài đặt LXD và MicroCloud của bạn bằng cách sử dụng sudo snap refresh lxd và sudo snap refresh microcloud.
• Xác minh phiên bản đã cài đặt sau khi cập nhật, vì các bản sửa lỗi có thể được triển khai dần dần từ kênh candidate sang stable.
• Hạn chế quyền truy cập mạng vào trình nghe API LXD nếu bạn không thể cập nhật ngay lập tức, vì cuộc tấn công yêu cầu quyền truy cập trực tiếp vào API HTTPS.
• Kiểm tra xem máy chủ LXD độc lập của bạn có bật core.https_address hay không; nếu không, nó có khả năng không bị lộ trước vector tấn công từ xa cụ thể này.
• Giám sát bất kỳ hoạt động bất thường nào trong thành phần cụm hoặc nhật ký API có thể chỉ ra nỗ lực giả mạo.
• Nếu bạn đang sử dụng Incus thay vì LXD, hãy nâng cấp lên phiên bản 7.6.0 trở lên để giải quyết vấn đề này cùng với 17 vấn đề bảo mật khác.