Nửa cuối năm 2026 chứng kiến một loạt lỗ hổng đáng chú ý trên Proxmox VE và nhân KVM của Linux - nền tảng ảo hóa mà phần lớn dịch vụ VPS trên thị trường (trong đó có bên mình) đang chạy. Có mấy lỗi cho phép kẻ tấn công thoát khỏi máy ảo để chiếm quyền máy chủ host, tức là ảnh hưởng tới toàn bộ khách hàng dùng chung một node vật lý. Bài này mình tổng hợp lại các lỗi đáng lo nhất, mức độ thật sự của từng cái, và cách kiểm tra - vá cho ai đang tự vận hành Proxmox.
Vì sao đợt này đáng quan tâm
Với một server ảo hóa cho thuê, guest của khách chính là mã không tin cậy chạy sẵn trên host. Nên nhóm lỗi nguy hiểm nhất không phải mấy lỗi cấu hình lặt vặt, mà là nhóm cho phép thoát máy ảo (VM escape). Một khách bị chiếm quyền có thể trở thành bàn đạp tấn công sang khách khác trên cùng máy chủ.
Các lỗ hổng chính, xếp theo mức độ
CVE-2026-51080 (Critical, điểm CVSS 9.8). Lỗi nằm trong gói libpve-storage-perl của Proxmox VE. Khai thác được từ xa qua mạng, không cần quyền, không cần người dùng thao tác, và ảnh hưởng cả tính bí mật lẫn toàn vẹn lẫn khả dụng của hệ thống. Đây là lỗi cần vá trước tiên. Bản sửa nằm ở libpve-storage-perl 9.1.1 và 8.3.7.
CVE-2026-53359 - tên gọi "Januscape" (điểm 8.8). Đây là lỗi use-after-free trong phần shadow MMU của KVM, cho phép thoát máy ảo ra host, chạy được trên cả CPU Intel lẫn AMD. Có một điểm quan trọng: lỗi này cần vá kèm CVE-2026-46113 mới đóng hoàn toàn, chỉ vá riêng cái đầu là chưa đủ. Tin tương đối yên tâm là đường tấn công cần máy ảo bật ảo hóa lồng (nested virtualization) hoặc dùng CPU model "host" - cả hai đều không phải mặc định của Proxmox VE. Guest cấu hình mặc định thì đường thoát bị chặn, nhưng vẫn nên vá nhân Linux.
CVE-2026-64561 - tên gọi "Zapscape" (mới nhất, công bố khoảng giữa tháng 8/2026). Cùng nằm ở phân hệ shadow MMU của KVM như Januscape nhưng nguyên nhân khác, cho phép máy ảo thoát ra host và chạy mã với quyền nhân trong một số điều kiện. Điểm cần nhớ: QEMU không dính lỗi này, lỗi nằm hoàn toàn trong KVM của nhân Linux, nên nền tảng nào dùng KVM cũng bị ảnh hưởng bất kể phiên bản QEMU. Xử lý chung với Januscape bằng cách cập nhật nhân.
CVE-2026-51083 (điểm 6.5). Người dùng quyền thấp có thể lấy được mật khẩu dạng hash qua endpoint cloudinit/dump của gói qemu-server, từ đó crack ngoại tuyến và di chuyển ngang trong hệ thống. Đáng lưu ý nếu môi trường có tài khoản Proxmox quyền hạn chế cấp cho nhiều người. Bản sửa ở qemu-server 9.1.8 và 8.4.8.
CVE-2026-25499 (liên quan Terraform/OpenTofu). Về bản chất đây là lỗi tài liệu: dòng cấu hình sudoer mà tài liệu SSH của provider khuyến nghị bị hở, cho phép dùng chuỗi ../ để thoát thư mục và sửa file bất kỳ trên hệ thống. Chỉ ảnh hưởng nếu bạn dùng đúng dòng sudoer cũ đó để tự động hóa Proxmox bằng Terraform. Bản sửa ở provider 0.93.1. Không dùng Terraform quản Proxmox thì bỏ qua.
Một mốc quan trọng ai cũng nên biết: Proxmox VE 8 hết vòng đời
Từ ngày 31/8/2026, Proxmox chính thức đóng hỗ trợ dòng PVE 8 - không còn bản vá bảo mật, không còn sửa lỗi. Nghĩa là mọi lỗ hổng phát hiện sau mốc này trên PVE 8 sẽ không được vá. Bản hiện hành là Proxmox VE 9.2 (ra tháng 5/2026, nền Debian 13, QEMU 11.0, LXC 7.0, ZFS 2.4). Ai còn chạy PVE 8 nên lên kế hoạch nâng cấp lên 9.x càng sớm càng tốt, đây mới là rủi ro lớn và kéo dài nhất chứ không riêng một CVE nào.
Cách kiểm tra và vá cho ai tự vận hành Proxmox
Chạy trên từng node, qua SSH hoặc terminal:
# Xem phiên bản PVE và nhân đang chạy
pveversion -v | grep -E 'pve-manager|proxmox-kernel|pve-kernel'
uname -r
# Kiểm tra các gói dính CVE tháng 7
dpkg -l | grep -E 'libpve-storage-perl|qemu-server'
# libpve-storage-perl cần >= 9.1.1 (hoặc 8.3.7)
# qemu-server cần >= 9.1.8 (hoặc 8.4.8)
# Kiểm tra nhân đã vá Januscape chưa
apt changelog "linux-image-$(uname -r)" 2>/dev/null | grep -iE 'CVE-2026-53359|CVE-2026-46113'
# Cập nhật toàn bộ rồi khởi động lại để nạp nhân mới
apt update && apt dist-upgradeLưu ý: nhóm lỗi thoát máy ảo (Januscape, Zapscape) chỉ được đóng sau khi khởi động lại vào nhân đã vá, nên đừng quên bước reboot. Thứ tự hợp lý: vá gói Proxmox trước (51080, 51083), rồi cập nhật và reboot nhân, cuối cùng lên lịch chuyển các node còn PVE 8 sang 9.x.
Về hạ tầng của bên mình
Bên mình theo dõi sát các bản vá này và cập nhật hạ tầng VPS theo quy trình để giảm gián đoạn dịch vụ. Với khách hàng đang dùng VPS bên mình thì không cần thao tác gì thêm ở phần nền tảng ảo hóa - phần đó bên mình lo. Còn hệ điều hành và ứng dụng bên trong máy ảo của bạn thì vẫn nên tự cập nhật đều, vì đó là phần thuộc quyền quản trị của bạn.
Ai đang tự dựng Proxmox mà cần tư vấn về nâng cấp cụm nhiều node, quy trình vá không downtime, hay chuyển từ PVE 8 lên 9.x, cứ liên hệ bên mình.
