Kubeflow Pipelines 2.18.0 vá hai lỗi rò log và cạn bộ nhớ

Một cụm Kubeflow có thể tách namespace cho nhiều nhóm AI nhưng vẫn để lộ log hoặc bị một tệp pipeline làm cạn bộ nhớ API server. Hai cảnh báo được GitHub rà soát ngày 30/10/2026 cho thấy Kubeflow Pipelines đến 2.17.3 chịu ảnh hưởng. Bản 2.18.0 đã sửa cả hai, nên đội MLOps cần ưu tiên nâng cấp thay vì chỉ tăng RAM cho cụm.

Hai lỗ hổng khác nhau ở điểm nào?

CVE-2026-118759 có điểm CVSS 7,5, mức cao. Điểm yếu nằm ở API lấy log của một lần chạy: yêu cầu có thể thiếu bước kiểm tra quyền phù hợp. Người gọi truy cập được backend và biết thông tin lần chạy hoặc nút xử lý có thể đọc log ngoài phạm vi được phép. Log huấn luyện thường chứa đường dẫn dữ liệu, tham số, thông tin lỗi và đôi khi cả khóa truy cập bị ứng dụng ghi nhầm.

CVE-2026-118761 cũng được chấm 7,5. API server giải nén gói pipeline trước khi kiểm tra namespace và quyền. Một “decompression bomb” là tệp nén rất nhỏ nhưng phình ra cực lớn khi giải nén. Nếu endpoint nhập hoặc tải pipeline có thể bị gọi, tệp như vậy có thể làm tiến trình dùng hết bộ nhớ, khiến dịch vụ điều phối ngừng đáp ứng.

Vì sao cụm AI thuê GPU vẫn cần quan tâm?

GPU không phải thành phần có lỗi, nhưng Kubeflow Pipelines điều phối công việc chạy trên GPU. Khi API server ngừng hoạt động, tác vụ mới không được lên lịch, thử nghiệm bị treo và người vận hành khó quan sát trạng thái. Nếu log bị đọc trái phép, thông tin truy cập kho mô hình hoặc kho dữ liệu có thể kéo theo rủi ro lớn hơn chi phí tài nguyên.

Môi trường nhiều nhóm dùng chung có mức phơi nhiễm cao hơn cụm một nhóm. Namespace là ranh giới logic trong Kubernetes; nó chỉ có tác dụng khi từng API kiểm tra quyền trước khi xử lý dữ liệu. Hai cảnh báo này nhắc đội nền tảng không nên coi namespace là lớp bảo vệ duy nhất.

Nâng cấp và kiểm tra theo thứ tự nào?

1. Ghi nhận phiên bản Kubeflow Pipelines và các thành phần API server đang chạy; xác định cụm nào ở 2.17.3 hoặc cũ hơn.
2. Kiểm tra đường nâng cấp lên 2.18.0 trong môi trường thử nghiệm, đặc biệt CRD, cấu hình xác thực và plugin giao diện đang dùng.
3. Sao lưu cấu hình, manifest và dữ liệu metadata theo quy trình của tổ chức; không coi snapshot máy ảo là bản sao duy nhất.
4. Nâng cấp 2.18.0, chạy một pipeline mẫu, kiểm tra log đúng quyền và xác minh API không còn giải nén trước bước ủy quyền.
5. Rà log truy cập backend để tìm yêu cầu bất thường tới endpoint log hoặc upload/import pipeline; GitHub không xác nhận mọi cụm đã bị khai thác.
6. Luân chuyển khóa truy cập nếu từng ghi vào log. Việc xóa log không vô hiệu hóa khóa đã lộ.

Giảm thiểu khi chưa thể nâng ngay

Với CVE-2026-118759, hãy hạn chế endpoint log ở lớp mạng hoặc cổng API, chỉ cho giao diện và dịch vụ tin cậy truy cập. Vai trò tùy chỉnh cần quyền readLog đúng phạm vi. Với CVE-2026-118761, giới hạn kích thước yêu cầu và bộ nhớ container chỉ giảm tác động; giới hạn kích thước tệp nén không đủ vì dữ liệu có thể phình mạnh sau giải nén. Biện pháp chính vẫn là chặn endpoint nhập pipeline với người không cần dùng và nâng lên 2.18.0.

Đội vận hành cũng nên đặt giới hạn CPU, bộ nhớ và số lần khởi động lại cho API server, đồng thời cảnh báo khi bộ nhớ tăng đột biến. Đây là lớp chịu lỗi, không phải bản vá. Nếu chỉ tự động khởi động lại, kẻ tấn công có thể tiếp tục gửi yêu cầu làm dịch vụ lặp lại trạng thái gián đoạn.

Nguồn tra cứu

Hành động cho đội MLOps

Đội MLOps nên chuẩn bị phiên bản Kubeflow hiện tại, số namespace, cách người dùng truy cập API, chính sách mạng và cửa sổ nâng cấp. Khi cần đối chiếu tài nguyên cho cụm thử nghiệm hoặc triển khai AI, liên hệ qua trang GPU Server với các thông tin đó để đánh giá cấu hình phù hợp; việc vá quyền truy cập và API phải hoàn tất độc lập với quyết định thuê thêm GPU.