Lỗ hổng nghiêm trọng chưa được vá trong LMCache cho phép thực thi mã từ xa

Các nhà nghiên cứu bảo mật đã xác định một lỗ hổng nghiêm trọng trong LMCache, một lớp tăng tốc mã nguồn mở dành cho các máy chủ mô hình ngôn ngữ lớn như vLLM. Được JFrog công bố vào ngày 7 tháng 10, lỗ hổng này cho phép kẻ tấn công không cần xác thực thực thi mã tùy ý trên các hệ thống bị ảnh hưởng. Tính đến thời điểm viết bài, chưa có phiên bản phần mềm sửa lỗi nào khả dụng, khiến các nhà vận hành phải dựa vào việc thay đổi cấu hình mạng để tự bảo vệ.

Chuyện gì đã xảy ra

Lỗ hổng, được theo dõi dưới mã CVE-2026-105192, mang mức độ nghiêm trọng 9.8/10. Nó ảnh hưởng đến các phiên bản LMCache từ 0.3.9 (phát hành vào tháng 10 năm 2025) cho đến phiên bản ổn định mới nhất là 0.5.5. Vấn đề này cũng tồn tại trong các ứng viên phát hành 0.5.6 và nhánh phát triển hiện tại. Nhóm nghiên cứu bảo mật của JFrog, do Yuval Moravchick dẫn đầu, đã phát hiện ra rằng chỉ một tin nhắn mạng được chế tác cẩn thận cũng có thể kích hoạt việc thực thi mã từ xa trên máy chủ cache.

Mức độ rủi ro phụ thuộc rất nhiều vào cấu hình triển khai. Theo mặc định, máy chủ đa tiến trình LMCache chỉ lắng nghe trên máy cục bộ, điều này ngăn chặn truy cập từ bên ngoài. Tuy nhiên, nhiều triển khai đa nút yêu cầu máy chủ phải lắng nghe trên một địa chỉ có thể định tuyến để chia sẻ dữ liệu cache giữa các máy. Cấu hình triển khai Kubernetes ví dụ chính thức của LMCache thiết lập máy chủ lắng nghe trên mọi giao diện mạng, về cơ bản làm lộ nó ra toàn bộ mạng cụm. Trong các cấu hình này, bất kỳ máy chủ nào có thể tiếp cận cổng đều có thể khai thác lỗ hổng.

Làm trầm trọng thêm mức độ nghiêm trọng, các hình ảnh container chính thức của LMCache chạy quy trình với tư cách người dùng root. Điều này có nghĩa là nếu khai thác thành công, kẻ tấn công sẽ có đặc quyền quản trị đầy đủ trên máy chủ. JFrog lưu ý rằng mặc dù tường lửa có thể hạn chế sự phơi nhiễm, nhưng chúng không loại bỏ hoàn toàn rủi ro nếu bất kỳ máy chủ đáng tin cậy nào trong phạm vi được phép bị xâm nhập. Hiện tại chưa có phương pháp nào được cung cấp để xác định xem một máy chủ đã bị tấn công hay chưa.

Cách thức hoạt động

Nguyên nhân gốc rễ nằm ở cách LMCache xử lý truyền thông liên tiến trình bằng thư viện nhắn tin ZeroMQ. Máy chủ đa tiến trình mở một socket để các quy trình worker đăng ký và chia sẻ dữ liệu cache, nhưng socket này thiếu bất kỳ cơ chế xác thực nào. Khi một tin nhắn đến, máy chủ sử dụng module pickle của Python để giải mã dữ liệu. Pickle được biết là không an toàn đối với dữ liệu không đáng tin cậy vì nó có thể thực thi mã tùy ý trong quá trình giải mã.

Điều quan trọng là, máy chủ giải nén dữ liệu pickle khi vẫn đang đọc các tham số tin nhắn, trước khi kiểm tra kiểu tin nhắn. Thứ tự thao tác này cho phép kẻ tấn công gửi một payload độc hại được thực thi ngay lập tức khi nhận được. Mã chạy với cùng đặc quyền như quy trình LMCache, mà như đã đề cập, thường là root trong các môi trường container hóa. Mô hình này tương tự với một nhóm các lỗ hổng gọi là ShadowMQ, được xác định trong các khung suy luận AI khác vào tháng 11 năm 2025, mặc dù chưa thiết lập được mối liên kết mã trực tiếp.

Chi tiết chính

• Mã định danh CVE: CVE-2026-105192, được đánh giá mức độ nghiêm trọng 9.8/10.
• Phiên bản bị ảnh hưởng: LMCache từ 0.3.9 đến 0.5.5, cộng với các ứng viên phát hành 0.5.6 và các nhánh dev.
• Vector tấn công: Tin nhắn mạng không cần xác thực qua socket ZeroMQ trong chế độ đa tiến trình.
• Nguyên nhân gốc rễ: Giải mã không an toàn sử dụng Python pickle trước khi xác thực kiểu tin nhắn.
• Cấp độ đặc quyền: Mã được thực thi dưới tên người dùng LMProcess, vốn là root trong các container chính thức.
• Trạng thái bản vá: Hiện chưa có phiên bản sửa lỗi khả dụng.

Tại sao vấn đề này quan trọng

Đối với các nhóm kỹ sư xây dựng hạ tầng AI, lỗ hổng này nhấn mạnh những rủi ro khi áp dụng các công cụ tăng tốc mới mà không có quy trình kiểm toán bảo mật chặt chẽ. LMCache được thiết kế để đẩy nhanh suy luận LLM, một chỉ số hiệu suất quan trọng cho các ứng dụng sản xuất. Tuy nhiên, các ví dụ mặc định do dự án cung cấp khuyến khích việc liên kết mạng không an toàn. Các nhà vận hành tuân theo những ví dụ này để thiết lập cụm đa nút vô tình làm lộ hệ thống của họ trước nguy cơ thực thi mã từ xa.

Việc thiếu bản vá buộc các nhóm phải lựa chọn giữa hiệu suất và bảo mật. Tắt địa chỉ có thể định tuyến sẽ phá vỡ caching đa nút, tiềm ẩn làm giảm chất lượng dịch vụ. Giữ nó mở lại tạo cửa rộng cho kẻ tấn công. Tình huống này nhấn mạnh tầm quan trọng của các chiến lược phòng thủ theo chiều sâu, chẳng hạn như phân đoạn mạng nghiêm ngặt và nguyên tắc đặc quyền tối thiểu, thay vì chỉ dựa vào bảo mật ở cấp ứng dụng.

Ngoài ra, việc phát hiện ra sáu báo cáo bảo mật chưa được xác nhận khác trên GitHub gợi ý những vấn đề vệ sinh bảo mật rộng hơn trong dự án. Mặc dù những báo cáo này thiếu mã CVE hoặc xác nhận từ người bảo trì, chúng chỉ ra khả năng truy cập không cần xác thực vào dữ liệu khách thuê và các dịch vụ khác. Các nhóm sử dụng LMCache giờ đây phải giám sát không chỉ riêng CVE cụ thể này mà còn cả tư thế bảo mật tổng thể của dự án và phản ứng trước các mối đe dọa mới nổi.

Bạn có thể làm gì

• Hạn chế truy cập mạng: Cấu hình máy chủ đa tiến trình LMCache để chỉ lắng nghe trên localhost hoặc một mạng cụm cô lập, đáng tin cậy.
• Tránh liên kết công khai: Không liên kết máy chủ với các địa chỉ có thể định tuyến được truy cập từ các mạng không đáng tin cậy hoặc internet công khai.
• Triển khai tường lửa: Sử dụng các quy tắc tường lửa để hạn chế nghiêm ngặt các địa chỉ IP có thể kết nối với cổng LMCache, mặc dù lưu ý rằng điều này không giảm thiểu hoàn toàn rủi ro.
• Kiểm tra đặc quyền container: Nếu có thể, hãy sửa đổi cấu hình container để chạy quy trình LMCache với tư cách người dùng không phải root nhằm hạn chế tác động của việc khai thác.
• Theo dõi cập nhật: Giám sát chặt chẽ kho lưu trữ LMCache và các cảnh báo của JFrog để tìm kiếm phiên bản đã được vá lỗi.
• Kiểm toán triển khai: Xem xét các triển khai Kubernetes hoặc Docker hiện có để đảm bảo chúng không sử dụng các cấu hình ví dụ mặc định làm lộ tất cả các giao diện.