Bảo mật

CVE-2026-114053 trong vLLM: RCE qua code_revision

vLLM 0.7.3 đến trước 0.31.0 có đường dẫn RCE trong một cấu hình đa phương thức cụ thể. Mặc định trust_remote_code=false không bị ảnh hưởng.

thuemaychu.vn
Minh họa yêu cầu đa phương thức bị chặn tại cổng bảo mật trước khi tải mã vào bộ xử lý mô hình LLM

Một máy chủ vLLM có thể đã đặt API key cho các endpoint sinh văn bản nhưng vẫn để hở đường dẫn tiền xử lý. Nếu đồng thời cho phép tải mã tùy biến từ kho mô hình, một tham số trong request đa phương thức có thể đổi revision mã được nạp. Đây là lỗi cấu hình kết hợp với đường xử lý thiếu ranh giới tin cậy.

GitHub Advisory Database duyệt và cập nhật CVE-2026-114053 ngày 27/10/2026. Bài này dành cho đội vận hành LLM và quản trị GPU server, tập trung vào điều kiện thực sự bị ảnh hưởng thay vì coi mọi cài đặt vLLM đều có RCE.

Phạm vi và phiên bản vá

Theo GitHub Advisory GHSA-h3rc-6mm3-gc2m, gói vllm từ 0.7.3 đến trước 0.31.0 bị ảnh hưởng; phiên bản vá là 0.31.0. CVE có điểm CVSS 3.1 là 8.1 High và CVSS 4.0 là 9.2 Critical trong hồ sơ CVE.

Đường tấn công chỉ tồn tại khi đủ các điều kiện: mô hình dùng mã AutoProcessor động; quản trị viên bật --trust-remote-code; máy chủ có thể tải revision do request chọn hoặc đã cache nó; kẻ tấn công kiểm soát một revision trong kho mô hình; và request đa phương thức đi qua đường tiền xử lý. Cấu hình mặc định trust_remote_code=False không bị ảnh hưởng.

Vì sao code_revision nguy hiểm?

vLLM cho phép request gửi mm_processor_kwargs. Tham số code_revision có thể đi qua lớp lọc và tới AutoProcessor.from_pretrained của Transformers. Khi mã từ xa được tin cậy, revision này quyết định module Python nào được tải và import. Import module tương đương chạy mã trong tiến trình vLLM.

Điểm đáng chú ý là revision dữ liệu hoặc trọng số do quản trị viên ghim vẫn có thể giữ nguyên, trong khi revision của mã processor bị đổi. Vì vậy, kiểm tra tên model và revision trọng số thôi chưa đủ để chứng minh an toàn.

Endpoint /tokenize cần được xem lại

Advisory nêu /tokenize đặc biệt quan trọng vì middleware xác thực tích hợp của vLLM bảo vệ một số tiền tố như /v1, /v2, /inference và /cohere, nhưng không mặc định bao phủ /tokenize. Đặt --api-key chưa chắc đã bảo vệ endpoint này nếu không có reverse proxy bên ngoài.

Điều đó không có nghĩa mọi /tokenize đều bị khai thác. Kẻ tấn công vẫn cần các điều kiện về mã processor và revision. Tuy nhiên, đội vận hành nên coi mọi endpoint xử lý input là bề mặt API và áp cùng chính sách mạng, xác thực, giới hạn tốc độ cùng ghi log.

Checklist xử lý không gián đoạn dài

  1. Xác định phiên bản vLLM trong container đang chạy và nâng lên 0.31.0 hoặc mới hơn trong môi trường thử nghiệm.
  2. Tìm cấu hình trust_remote_code; nếu không bắt buộc, tắt và dùng processor đã đóng gói hoặc được kiểm soát.
  3. Ghim commit cho model và mã processor; hạn chế egress từ container tới kho mô hình trong hệ thống phục vụ khách hàng.
  4. Đặt toàn bộ endpoint, gồm /tokenize, sau reverse proxy có xác thực và danh sách mạng được phép.
  5. Không cho request tùy ý chuyển các tham số tải mã; dùng allowlist cho mm_processor_kwargs.
  6. Chạy canary với prompt văn bản và đa phương thức, sau đó thay dần replica cũ.
  7. Rà log các request có code_revision, lỗi tải module, tải revision lạ và thay đổi tệp trong container.

Cách giảm tác động nếu chưa thể nâng ngay

Biện pháp an toàn nhất vẫn là nâng cấp. Trong thời gian ngắn, tắt trust_remote_code, chặn endpoint không dùng, buộc xác thực ở proxy và chặn container truy cập Internet có thể giảm rủi ro. Không coi đây là thay thế vĩnh viễn cho bản vá.

Sau khi vá, hãy dựng lại image thay vì cài chồng trong container đang chạy, rồi xóa cache mã tải từ xa nếu quy trình của bạn cho phép. Việc quay vòng khóa phụ thuộc vào bằng chứng phơi dịch vụ hoặc dấu hiệu xâm nhập; advisory không khẳng định khai thác thực tế.

Tác động với máy chủ suy luận tại Việt Nam

Các đội tự phục vụ mô hình đa phương thức thường ưu tiên tốc độ triển khai, nên trust_remote_code dễ được bật để model chạy nhanh. Trước khi đưa vào hệ thống phục vụ khách hàng, cần chuyển từ thử nghiệm tin cậy sang chuỗi cung ứng có commit cố định, image bất biến và endpoint được bảo vệ.

Nếu cần thử bản vLLM mới trên GPU server, hãy gửi loại GPU, model, phiên bản container, cổng API, yêu cầu đa phương thức và lưu lượng dự kiến tới hotro@thuemaychu.vn. Không gửi token hoặc khóa kho mô hình. Mục tiêu là lập kế hoạch canary và đo lại thời gian phản hồi sau nâng cấp.

Nguồn tham khảo

Mọi máy chủ vLLM trước 0.31.0 đều có thể bị RCE không?

Không. Phải đồng thời bật trust_remote_code, dùng processor động, nhận request đa phương thức và cho phép chọn revision mã mà kẻ tấn công kiểm soát.

Đặt api-key của vLLM có bảo vệ /tokenize không?

Theo advisory, middleware tích hợp không mặc định bảo vệ /tokenize. Nên đặt toàn bộ endpoint sau reverse proxy có xác thực và kiểm soát mạng.

Phiên bản vLLM nào đã vá?

GitHub Advisory ghi phiên bản vá là 0.31.0. Hãy thử với model và plugin thực tế trước khi thay toàn bộ replica.

Cần máy chủ cho workload này?

NOC thuemaychu.vn hỗ trợ chọn CPU, GPU và băng thông. PoC trong 24 giờ.

Bài viết liên quan

Xem tất cả bài viết
GọiFBZaloSalesZaloOA