Vấn đề lần này không phải là bản vá cho một plugin WordPress. Nó nằm ở tầng bên dưới website của bạn, trong nền tảng vùng chứa và máy ảo mà một số nhà cung cấp lưu trữ dùng để vận hành khối lượng công việc của khách hàng. Nếu website của bạn đặt trên lưu trữ chia sẻ hoặc máy chủ ảo (VPS), nhiều khả năng bạn không thể tự áp dụng bản vá, nhưng bạn có thể đặt đúng câu hỏi và lưu lại câu trả lời. Mọi thông tin dưới đây được kiểm tra tính đến ngày 2 tháng 11 năm 2026.
Các thông báo chính thức xác lập điều gì
Canonical công bố thông báo bảo mật cho LXD và MicroCloud vào ngày 28 tháng 10 năm 2026. Thông báo mô tả một điểm yếu nghiêm trọng trong cách API HTTPS xác thực chứng chỉ của máy khách. Khi API này có thể truy cập qua mạng, một người chỉ nắm chứng chỉ công khai của một máy khách tin cậy có thể mạo danh máy khách đó mà không cần khóa riêng. Tùy theo quyền được gán cho máy khách đó, kẻ tấn công có thể giành quyền root trên máy chủ lưu trữ. Với MicroCloud, thông báo bổ sung một tình huống trong cụm: kẻ tấn công chặn được chứng chỉ công khai của một thành viên khi thành viên đó đang gia nhập có thể về sau mạo danh thành viên đã gia nhập.
Hồ sơ Ubuntu về CVE-2026-112816, công bố ngày 30 tháng 10 năm 2026, liệt kê các phiên bản bị ảnh hưởng là LXD 4.0.14, 5.0.10, 5.21.8 và 6.9, được sửa trong 4.0.15, 5.0.11, 5.21.9 và 6.10.1. Hồ sơ cũng ghi rằng các gói LXD trong kho lưu trữ Ubuntu không bị ảnh hưởng hoặc không được phát hành. Vì vậy câu hỏi đặt ra là dành cho các máy chủ cài LXD bằng gói snap. Máy chủ đã cập nhật đầy đủ qua apt, hay hệ quản trị nội dung (CMS) của website đã ở phiên bản mới nhất, tự nó không chứng minh được rằng bản sửa cho gói snap đã được cài.
| Sản phẩm | Kênh | Phiên bản đã sửa |
|---|---|---|
| LXD | 6/stable | 6.10.1 |
| LXD | 5.21/stable | 5.21.9 |
| LXD | 5.0/stable | 5.0.11 |
| LXD | 4.0/stable | 4.0.15 |
| MicroCloud | 2/stable | 2.1.5 |
| MicroCloud | 3/stable | 3.4.1 |
Các gói snap đã sửa đề ngày 29 tháng 10 năm 2026. Với hai gói snap của Canonical, thông báo cung cấp các lệnh sau:
sudo snap refresh lxd
sudo snap refresh microcloudThông báo vẫn mô tả việc phát hành theo từng giai đoạn từ kênh candidate sang kênh stable, nên một lần làm mới chưa chắc mang bản dựng đã sửa đến mọi máy chủ ngay lập tức. Hãy kiểm tra phiên bản đã cài sau khi làm mới. Giữ nguyên kênh hiện tại trừ khi việc đổi kênh đã nằm trong kế hoạch từ trước.
Thông báo liên quan của Incus
Incus là nhánh phát triển riêng tách ra từ LXD. Nhóm bảo trì công bố GHSA-xg75-xf37-cph9 vào ngày 29 tháng 10 năm 2026. Thông báo hiện liệt kê là chưa có mã CVE nào được biết đến. Hãy theo dõi Incus bằng chính mã GHSA của nó, và đừng dùng mã CVE của Canonical nêu trên để định danh vấn đề của Incus. Điểm lắng nghe HTTPS trong tiến trình incusd chấp nhận một chuỗi chứng chỉ độc hại, nên chứng chỉ công khai của máy chủ hoặc của một thành viên là đủ cho một số quyền truy cập. Không có cách khắc phục bằng cấu hình. Trong lúc chờ vá, dự án gợi ý giới hạn truy cập mạng tới điểm lắng nghe chỉ cho các máy tin cậy. Đây là biện pháp giảm rủi ro, không thay thế bản vá. Hai lệnh snap ở trên không áp dụng cho Incus. Quản trị viên Incus cập nhật lên v7.6.0 trở lên theo phương thức cài đặt mà họ đang được hỗ trợ.
| Sản phẩm | Bị ảnh hưởng | Đã vá |
|---|---|---|
| Incus (github.com/lxc/incus/v7/cmd/incusd) | trước v7.6.0 | từ v7.6.0 trở lên |
Khi nào vấn đề này liên quan đến bạn
Khả năng truy cập API HTTPS qua mạng là điều kiện phơi nhiễm cho kiểu tấn công mà các thông báo mô tả. Đó không phải là lý do để bỏ qua cập nhật. Các nhà phát triển yêu cầu mọi người dùng cập nhật, và một máy chủ không có API truy cập được qua mạng không vì thế mà được chứng minh là không bị ảnh hưởng. Theo tài liệu LXD, LXD mặc định chỉ lắng nghe trên một Unix socket cục bộ, và truy cập HTTPS từ xa chỉ tồn tại khi quản trị viên đã cấu hình bằng core.https_address. Mặc định này là phát biểu riêng về LXD. Chúng tôi không đưa ra khẳng định tương tự cho MicroCloud hay Incus. Đừng mở API của chính mình ra mạng để thử nghiệm. Vấn đề này cũng không có nghĩa là mọi website chạy trên Linux hay Ubuntu đều bị ảnh hưởng. Nó liên quan đến các máy chủ lưu trữ chạy những nền tảng này, nên câu hỏi hữu ích cho khách hàng dùng lưu trữ chia sẻ hoặc máy chủ ảo là tầng điều khiển của nhà cung cấp có dùng chúng hay không. Lỗ hổng được The Hacker News đưa tin rộng rãi hơn vào ngày 1 tháng 11 năm 2026.
Ý nghĩa đối với doanh nghiệp
- Phía nhà cung cấp. Quyền root trên một máy chủ lưu trữ đặt toàn bộ tệp, thông tin đăng nhập và bản sao lưu cục bộ của mọi khách hàng trên máy chủ đó vào vùng rủi ro, không chỉ một website.
- Phía chủ website. Mức rủi ro của bạn phụ thuộc vào hạ tầng mà bạn không kiểm soát. Điều bạn có thể làm là đặt câu hỏi rõ ràng và lưu lại câu trả lời.
- Cửa sổ bảo trì. Hãy xem việc cập nhật là bảo trì có kế hoạch theo quy trình được nhà cung cấp phê duyệt. Bảo đảm đã có bản sao lưu mới trước đó và kiểm tra các dịch vụ đang lưu trữ sau khi hoàn tất. Chúng tôi không khẳng định gì về thời gian cập nhật hay việc dịch vụ có bị gián đoạn hay không.
Danh sách kiểm tra thực tế
Đây là các bước kiểm tra thực tế do ViWeb đề xuất, không phải yêu cầu của nhà cung cấp phần mềm.
Nếu bạn tự quản trị máy chủ LXD, MicroCloud hoặc Incus:
- Ghi lại sản phẩm, kênh và phiên bản đã cài trên từng thành viên cụm trước khi thay đổi bất cứ điều gì.
- Xác nhận API HTTPS có được gắn vào địa chỉ mạng hay không và có thể truy cập từ đâu.
- Kiểm tra bản sao lưu hiện tại và lên lịch cửa sổ bảo trì.
- Với LXD hoặc MicroCloud, làm mới các gói snap đã cài trong kênh hiện tại của chúng. Với Incus, cập nhật lên v7.6.0 trở lên theo phương thức cài đặt mà bạn đang được hỗ trợ.
- Kiểm tra lại phiên bản đã cài trên từng thành viên, vì Canonical phát hành theo từng giai đoạn.
- Xác nhận các website và dịch vụ đang lưu trữ hoạt động bình thường sau khi cập nhật.
- Nếu nghi ngờ có truy cập API bất thường, hãy bảo toàn và rà soát nhật ký trước khi thay đổi thông tin đăng nhập. Đừng thay toàn bộ chứng chỉ theo phản xạ khi chưa có bằng chứng.
Nếu bạn dùng lưu trữ chia sẻ hoặc máy chủ ảo:
- Hỏi xem tầng điều khiển có dùng LXD, MicroCloud hay Incus không.
- Hỏi sản phẩm, kênh và phiên bản trên từng thành viên, và API có truy cập được từ mạng hay không.
- Yêu cầu bằng chứng hoàn tất, chẳng hạn ngày và kết quả kiểm tra phiên bản, thay vì chỉ một câu “chúng tôi đã vá”.
- Tự kiểm tra website của bạn hoạt động bình thường sau đợt bảo trì của nhà cung cấp.
Những giới hạn còn lại
- Các thông báo chúng tôi đã mở mô tả lỗ hổng và bản sửa. Chúng không xác lập việc khai thác đã xảy ra hay chưa, và chúng tôi không khẳng định theo hướng nào.
- Phiên bản đã sửa cho thấy máy chủ lưu trữ hiện đã được vá. Nó không xác lập điều gì đã xảy ra trước khi cập nhật, và bản vá không phải là bằng chứng cho thấy trước đó chưa từng bị xâm nhập.