LMDeploy dính lỗ hổng SSRF nghiêm trọng, tin tặc vũ khí hóa thần tốc chỉ sau 12h

WhiteHat Team

Administrators
Thành viên BQT
09/04/2020
128
1.835 bài viết
LMDeploy dính lỗ hổng SSRF nghiêm trọng, tin tặc vũ khí hóa thần tốc chỉ sau 12h
Chỉ 12 giờ 31 phút sau khi xuất hiện trên advisory của GitHub, lỗ hổng CVE-2026-33626 trong LMDeploy đã nhanh chóng bị biến thành công cụ tấn công thực tế. Sự việc này không chỉ là một lỗ hổng kỹ thuật đơn thuần, mà còn phản ánh rõ tốc độ vũ khí hóa lỗ hổng đang dần vượt xa khả năng ứng phó của các hệ thống AI hiện nay

LMDeploy.png

LMDeploy là bộ công cụ do Shanghai AI Laboratory phát triển trong khuôn khổ dự án InternLM, được sử dụng để triển khai các mô hình ngôn ngữ và thị giác–ngôn ngữ thông qua API tương thích OpenAI. Nền tảng này hiện được dùng rộng rãi để vận hành các mô hình như InternVL2, internlm-xcomposer2 và Qwen2-VL.

Ngày 21/4/2026, GitHub công bố một cảnh báo mang mã GHSA-6w67-hwm5-92mq, sau đó được gán mã CVE-2026-33626, mô tả một lỗ hổng Server-Side Request Forgery (SSRF) trong cơ chế tải ảnh của thành phần vision-language. Ở các phiên bản trước 0.12.3, hàm load_image() cho phép hệ thống tải dữ liệu từ URL tùy ý qua trường image_url mà không kiểm tra hostname, dải IP hoặc giao thức, từ đó cho phép kẻ tấn công buộc máy chủ mô hình gửi các yêu cầu HTTP vào mạng nội bộ, dịch vụ metadata trên cloud hoặc các endpoint không công khai trên Internet.

Ngay sau khi lỗ hổng được công bố, hoạt động tấn công đã xuất hiện. Theo dữ liệu telemetry từ Sysdig Threat Research Team (TRT), cuộc tấn công đầu tiên được ghi nhận lúc 03:35 UTC ngày 22/4/2026, nhắm vào một hệ thống honeypot chạy LMDeploy và xuất phát từ địa chỉ IP 103.116.72.119 tại Kowloon Bay, Hong Kong. Đáng chú ý, cuộc tấn công xảy ra chỉ 12 giờ 31 phút sau khi cảnh báo được công bố trên GitHub, dù chưa có mã khai thác PoC công khai, cho thấy tin tặc đã nhanh chóng biến thông tin kỹ thuật trong cảnh báo thành khai thác thực tế.

Trong khoảng 8 phút hoạt động, kẻ tấn công không chỉ kiểm tra lỗ hổng mà còn tận dụng thành phần tải ảnh của LMDeploy như một công cụ SSRF HTTP đa dụng. Các yêu cầu ban đầu nhắm vào dịch vụ AWS Instance Metadata (IMDS) tại địa chỉ 169.254.169.254 nhằm tìm cách thu thập thông tin IAM, sau đó mở rộng sang các dịch vụ nội bộ như Redis (cổng 6379), MySQL (cổng 3306), cũng như các giao diện HTTP quản trị trên cổng 8080 và 80.

Đồng thời, đối tượng sử dụng một domain callback ngoài băng thông qua requestrepo.com để xác nhận khả năng khai thác SSRF dạng “blind” và kiểm tra kết nối ra ngoài (egress), một kỹ thuật phổ biến trong các hoạt động khai thác hiện nay.

Không dừng lại ở việc trinh sát, kẻ tấn công còn thăm dò hệ thống phân tán của LMDeploy bằng cách gọi endpoint quản trị không yêu cầu xác thực tại đường dẫn /distserve, nhằm gây gián đoạn kết nối nội bộ giữa các thành phần model-engine và có thể ảnh hưởng đến quá trình suy luận của các mô hình AI đang được phục vụ trên hệ thống.

Những gì ghi nhận được cho thấy kẻ tấn công đã nắm rõ kiến trúc phân tán của LMDeploy, đồng thời cho thấy một lỗ hổng SSRF trong thành phần phục vụ AI có thể nhanh chóng bị khai thác để ảnh hưởng đến tính sẵn sàng và mở rộng di chuyển ngang trong hệ thống.

Với những gì đã được ghi nhận, CVE-2026-33626 được xếp hạng nghiêm trọng cao với điểm CVSS 7.5, ảnh hưởng đến các phiên bản LMDeploy trước 0.12.3. Để khắc phục, dự án LMDeploy đã phát hành bản cập nhật 0.12.3, siết chặt cơ chế kiểm tra URL, chặn truy cập tới các dải địa chỉ link-local, loopback và private theo RFC1918, qua đó triệt tiêu khả năng quét cổng nội bộ và truy cập dịch vụ metadata.

Để bảo vệ hệ thống, các đơn vị vận hành cần khẩn trương nâng cấp lên LMDeploy phiên bản 0.12.3 hoặc mới hơn. Đồng thời, nên triển khai IMDSv2 với cơ chế token trên môi trường cloud và kiểm soát chặt lưu lượng outbound từ các node GPU/inference. Chỉ nên cho phép kết nối tới các đích thực sự cần thiết như hệ thống lưu trữ đối tượng hoặc logging, nhằm hạn chế nguy cơ bị khai thác SSRF trong các kịch bản tương tự.

Với việc khai thác xuất hiện chỉ trong vài giờ sau công bố, các chu kỳ vá lỗi định kỳ và quy trình phản ứng chậm đang dần trở nên không đủ để bảo vệ hạ tầng AI trước các cuộc tấn công SSRF có tốc độ và mức độ thích ứng ngày càng cao.
Theo Cyber Press
 
Mời các bạn tham gia Group WhiteHat để thảo luận và cập nhật tin tức an ninh mạng hàng ngày.
Lưu ý từ WhiteHat: Kiến thức an ninh mạng để phòng chống, không làm điều xấu. Luật pháp liên quan
Thẻ
cve-2026-33626 lmdeploy lỗ hổng ssrf
Bên trên