Hai CVE Kubernetes mới: kiểm tra quyền StatefulSet và Windows node

Một nhóm vận hành có thể đã chia ứng dụng theo namespace và tin rằng ranh giới này đủ an toàn. Hai lỗ hổng vừa xuất hiện trong nguồn CVE chính thức của Kubernetes cho thấy cần kiểm tra thêm quyền ghi StatefulSet, ControllerRevision và cách Windows node xử lý đường dẫn subPath. Tin tốt là cả hai đều cần điều kiện tương đối cụ thể và đã có phiên bản vá.

Bài này dành cho quản trị Kubernetes và đội bảo mật hạ tầng. Mục tiêu là xác định cụm nào thực sự có rủi ro, tránh nâng cấp vội nhưng cũng không bỏ sót quyền có thể vượt ranh giới namespace.

Điều mới được công bố ngày 20/10/2026

Nguồn CVE chính thức của Kubernetes được cập nhật lúc 00:23 UTC ngày 20/10/2026, bổ sung CVE-2026-2270 và CVE-2026-76654. Đây là ngày sự kiện công bố trong nguồn chính thức; hồ sơ kỹ thuật trên GitHub đã được mở từ tháng 9 trong quá trình xử lý kín.

CVE-2026-2270 có thể vượt ranh giới namespace như thế nào?

Theo hồ sơ CVE-2026-2270 của Kubernetes, người có quyền ghi đối tượng StatefulSet và ControllerRevision trong một namespace có thể khiến bộ điều khiển tạo Pod ở namespace khác. Pod này có thể mang metadata và đặc tả do người đó kiểm soát.

Điều kiện không đơn giản như chỉ có quyền tạo Pod. Pod chéo namespace sẽ bị bộ gom rác xóa ngay nếu OwnerReference không hợp lệ. Để tồn tại, kẻ tấn công phải tham chiếu đúng UID của một StatefulSet có sẵn trong namespace nạn nhân. Vì vậy đội vận hành nên kiểm tra cả quyền RBAC lẫn khả năng đọc hoặc suy ra UID ở namespace khác.

Các nhánh bị ảnh hưởng là kube-controller-manager đến 1.34.11, 1.35.8, 1.36.4 và đúng phiên bản 1.37.0. Bản đã sửa lần lượt là 1.34.12, 1.35.9, 1.36.5 và 1.37.1 trở lên. Kubernetes cho biết bản vá chỉ khôi phục trường spec của StatefulSet từ ControllerRevision.

CVE-2026-76654 chỉ liên quan Windows node nhưng cần chú ý miền Windows

Hồ sơ CVE-2026-76654 mô tả kubelet trên Windows có thể đi theo liên kết biểu tượng trong subPath tới một đường dẫn UNC, tức đường dẫn chia sẻ mạng kiểu \\server\share. Khi đó kubelet thử xác thực NTLM với máy chủ do kẻ tấn công kiểm soát.

Hậu quả có thể là lộ NetNTLMv2 hash của tài khoản chạy kubelet. Hash có thể bị thử dò mật khẩu hoặc chuyển tiếp để giả mạo node nếu máy đã gia nhập miền Windows. Linux node không nằm trong điều kiện được mô tả. Phiên bản kubelet bị ảnh hưởng và phiên bản vá giống các mốc của CVE-2026-2270; bản sửa từ chối đích UNC khi giải quyết liên kết trên Windows.

Checklist xử lý an toàn

1. Chụp lại phiên bản kube-controller-manager và kubelet theo từng node; không suy ra chỉ từ phiên bản kubectl trên máy quản trị.
2. Liệt kê Role và ClusterRole cho phép create, update hoặc patch StatefulSet và ControllerRevision; giảm quyền cho tài khoản ứng dụng không cần dùng.
3. Với Windows node, tìm workload dùng volumeMounts.subPath, kiểm tra node có gia nhập miền và chặn SMB/NTLM ra mạng không tin cậy.
4. Đọc hướng dẫn nâng cấp của bản phân phối Kubernetes đang dùng, thử trước trên cụm không phục vụ khách hàng và chuẩn bị đường lui.
5. Sau nâng cấp, kiểm tra controller, lịch Pod, volume, ứng dụng StatefulSet và nhật ký xác thực Windows.

Kubernetes chưa công bố bằng chứng khai thác thực tế trong hai hồ sơ; lời mời gửi bằng chứng cho nhóm bảo mật không đồng nghĩa đã có tấn công. Điểm Medium cũng không nên dùng để bỏ qua nếu một tài khoản tự động đang giữ quyền rộng hoặc Windows node nối với miền quan trọng.

Quản trị cụm tại Việt Nam nên ưu tiên gì?

Cụm chỉ chạy Linux vẫn cần rà CVE-2026-2270 nhưng không thuộc điều kiện CVE-2026-76654. Cụm thuê theo dịch vụ được quản lý cần hỏi nhà cung cấp phiên bản control plane và lịch vá, đồng thời tự kiểm tra RBAC phía tenant. Với cụm tự vận hành trên VPS, hãy tách thay đổi control plane và worker theo cửa sổ bảo trì để giảm phạm vi sự cố.

Nếu bạn phụ trách cụm tự vận hành, hãy gửi phiên bản control plane, danh sách hệ điều hành node, phạm vi RBAC và cửa sổ bảo trì qua trang Thuê Cloud VPS. Đội kỹ thuật có thể dùng các thông tin đó để cùng bạn xác định thứ tự kiểm tra hạ tầng; đây không phải cam kết rằng cụm hiện tại đang có lỗ hổng.