CVE-2026-119168 trên Nomad: khi symlink chạm tới thư mục host

Một cụm Nomad có thể vận hành ổn định trong thời gian dài nhưng vẫn gặp rủi ro khi workload được thay thế trên cùng một client. Ngày 29/10/2026, HashiCorp công bố CVE-2026-119168: trong một số lần di chuyển dữ liệu allocation, Nomad có thể đi theo liên kết tượng trưng (symlink) do workload tạo và thay đổi quyền của thư mục nằm ngoài vùng allocation.

Bài này dành cho quản trị viên Nomad và đội nền tảng. Điều quan trọng là không đánh đồng mọi cụm Nomad với trạng thái bị khai thác. Rủi ro chỉ hình thành khi nhiều điều kiện cùng xuất hiện, nhưng tác động có thể chạm tới dữ liệu và tệp trên máy chủ host.

Điều gì mới được HashiCorp công bố?

Theo thông báo HCSEC-2026-53 của HashiCorp, Nomad và Nomad Enterprise đến 2.0.7 bị ảnh hưởng. Bản sửa có trong Nomad 2.1.0; với Nomad Enterprise là 2.1.0, 1.11.12 và 1.10.18. Ngày đăng và ngày sự kiện công bố đều là 29/10/2026.

Cơ chế liên quan đến sticky ephemeral disk, tức vùng dữ liệu tạm vẫn được tái sử dụng khi allocation được thay thế trên cùng client. Trong lúc chuyển dữ liệu, một workload có thể thay thư mục task-local bằng symlink. Nếu allocation mới tiếp tục được đặt trên cùng client, Nomad có thể đi theo symlink khi đặt quyền sở hữu và quyền truy cập.

Khi nào cụm thực sự gặp rủi ro?

• Người tấn công đã có quyền gửi hoặc cập nhật job Nomad; đây không phải lỗi cho phép người ngoài Internet tự động chiếm cụm.
• Job dùng sticky ephemeral disk và allocation thay thế được đặt trên cùng Nomad client.
• Workload có thể thay một thư mục task-local bằng symlink trước khi dữ liệu được di chuyển.
• Nomad client chạy với quyền root; khi đó thao tác đổi quyền có thể tác động đến thư mục host ngoài allocation.
• Thư mục đích có dữ liệu hoặc tệp mà workload có thể lợi dụng sau khi quyền bị thay đổi.

Allocation không tái sử dụng dữ liệu cũ không nằm trong đường khai thác mà HashiCorp mô tả. Thông báo hãng cũng không nêu bằng chứng khai thác thực tế. Vì vậy, đội vận hành nên ưu tiên theo mức phơi nhiễm thay vì dùng tiêu đề gây hoảng sợ.

Tác động với hạ tầng máy chủ và VPS

Nếu chuỗi điều kiện thành công, workload có thể làm thay đổi owner hoặc mode của thư mục host. Hệ quả phụ thuộc vào thư mục bị trỏ tới: có thể chỉ gây lỗi ứng dụng, nhưng cũng có thể mở quyền đọc dữ liệu, sửa tệp được tiến trình đặc quyền sử dụng hoặc tạo đường leo thang đặc quyền.

Với môi trường nhiều nhóm dùng chung cluster, quyền tạo và sửa job là ranh giới quan trọng. Một tenant có quyền job quá rộng sẽ làm tăng rủi ro cho các workload khác trên cùng client. Đây là lý do cần kết hợp bản vá với phân quyền, tách node pool và giám sát thay đổi filesystem.

Checklist xử lý dành cho quản trị viên

1. Lập danh sách phiên bản Nomad server và client; không chỉ kiểm tra giao diện điều khiển trung tâm.
2. Tìm job khai báo sticky ephemeral disk và xác định client nào chạy các allocation đó.
3. Rà quyền ACL: ai có thể submit, dispatch hoặc update job, đặc biệt trong namespace dùng chung.
4. Lập kế hoạch nâng cấp lên Nomad 2.1.0 hoặc nhánh Enterprise đã vá 1.11.12/1.10.18; thử trước ở môi trường thử nghiệm.
5. Trong thời gian chờ vá, hạn chế quyền cập nhật job, tránh đặt workload không tin cậy lên client chạy tác vụ nhạy cảm và theo dõi thay đổi owner/mode bất thường.
6. Sau nâng cấp, tạo một ca kiểm thử thay thế allocation trên cùng client và xác nhận dữ liệu sticky vẫn hoạt động đúng.

Không nên coi việc chạy container là ranh giới bảo mật tuyệt đối. Container chia sẻ kernel với host; quyền của tiến trình điều phối và cách xử lý mount, symlink, volume quyết định mức cô lập thực tế.

Cách ưu tiên vá mà không gây gián đoạn

Bắt đầu từ client chứa workload nhiều tenant hoặc có sticky ephemeral disk. Drain từng client, quan sát allocation được chuyển đi, nâng cấp rồi đưa node trở lại cụm. Với workload có dữ liệu cục bộ, cần sao lưu và xác nhận quy trình phục hồi trước khi thao tác.

Nếu chưa thể nâng cấp toàn bộ, hãy giảm phạm vi rủi ro bằng cách tách workload có quyền sửa job khỏi node chứa dữ liệu nhạy cảm. Đây chỉ là biện pháp tạm thời; bản vá của HashiCorp vẫn là cách xử lý chính.

Câu hỏi thường gặp

Nguồn tham khảo

Nguồn chính: HashiCorp HCSEC-2026-53, đăng ngày 29/10/2026. Bài viết tập trung vào kiểm tra và phòng vệ, không cung cấp hướng dẫn khai thác.

Nếu đội của bạn vận hành Nomad trên máy chủ hoặc VPS, hãy chuẩn bị phiên bản server/client, danh sách job dùng sticky disk và sơ đồ namespace trước khi liên hệ qua thuemaychu.vn. Các thông tin này giúp đánh giá phạm vi kiểm tra và cửa sổ bảo trì phù hợp.