Lỗ hổng LiteLLM và Starlette 'bắt tay' nhau tạo thành chuỗi tấn công RCE không cần xác thực, điểm CVSS chạm mức tối đa 10.0

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Cả hai điểm cuối này đều chấp nhận một cấu hình máy chủ MCP hoàn chỉnh trong phần thân của yêu cầu HTTP (JSON). Cấu hình này bao gồm các trường Cmd, args, và env—những thông số dùng để khởi chạy tiến trình máy chủ thông qua cơ chế stdio transport . Khi một người dùng đã xác thực gọi đến các điểm cuối này, LiteLLM sẽ lấy giá trị Cmd được cung cấp và thực thi nó như một tiến trình con trên chính máy chủ đang chạy proxy LiteLLM, với toàn bộ quyền hạn của tiến trình proxy đó .

Ban đầu, BerriAI chỉ công bố đây là một lỗ hổng thực thi lệnh từ xa 'cần xác thực'. Kẻ tấn công cần có một khóa API hợp lệ để truy cập các điểm cuối, và không có cơ chế kiểm tra vai trò (role) nào ở đây. Nghĩa là chỉ cần một người dùng nội bộ có đặc quyền thấp nhất, sở hữu bất kỳ khóa API proxy hợp lệ nào, cũng có thể thực thi lệnh tùy ý trên máy chủ . Nhưng câu chuyện chưa dừng lại ở đó.

'Mắc xích' thứ hai: 'Cú lừa' vượt xác thực từ lỗ hổng BadHost

Lỗ hổng thứ hai trong chuỗi tấn công là CVE-2026-48710, được các nhà nghiên cứu đặt biệt danh là "BadHost". Đây là một lỗi xác thực tiêu đề Host trong Starlette, một framework ASGI siêu nhẹ làm nền tảng cho FastAPI, vLLM, và hàng ngàn ứng dụng web Python khác, bao gồm cả LiteLLM . Tất cả các phiên bản Starlette từ 0.8.3 đến 1.0.0 đều bị ảnh hưởng .

Nguyên nhân cốt lõi nằm ở sự 'bất đồng' giữa cách Starlette định tuyến các yêu cầu đến và cách nó tái tạo URL cho logic ứng dụng . Tầng định tuyến ASGI sử dụng đường dẫn HTTP thô để quyết định điểm cuối nào sẽ xử lý yêu cầu. Nhưng thuộc tính request.url—thứ mà các middleware xác thực và decorator ứng dụng nhìn thấy—lại được xây dựng lại bằng cách nối giá trị thô của tiêu đề Host với đường dẫn yêu cầu mà không hề có bước xác thực nào .

Bằng cách chèn các ký tự phân cách như ? hoặc # vào tiêu đề Host, kẻ tấn công có thể làm cho request.url.path hiển thị một giá trị hoàn toàn khác so với đường dẫn được định tuyến thực tế . Middleware xác thực tưởng rằng yêu cầu đang gọi đến một đường dẫn vô hại như /, trong khi router ngầm chuyển tiếp nó đến một điểm cuối mục tiêu cần được bảo vệ.

Chuỗi tấn công hoàn chỉnh: Từ 8.7 lên 10.0

Bộ phận xác thực của LiteLLM hoạt động bằng cách kiểm tra request.url.path để quyết định xem một yêu cầu có cần khóa API hợp lệ hay không. Kỹ thuật vượt qua BadHost cho phép kẻ tấn công thao túng URL này, khiến middleware xác thực 'nhìn thấy' một đường dẫn không yêu cầu xác thực, trong khi bộ định tuyến ASGI đồng thời điều phối yêu cầu đó đến một trong những điểm cuối MCP dễ bị chèn lệnh .

Điều này loại bỏ hoàn toàn lá chắn kiểm soát truy cập duy nhất ngăn cách Internet với khả năng thực thi lệnh tùy ý. Một kẻ tấn công không cần bất kỳ thông tin xác thực hay quyền truy cập mạng nào trước đó có thể gửi một yêu cầu HTTP duy nhất được chế tạo đặc biệt, vượt qua mọi hàng rào xác thực và thực thi lệnh hệ điều hành trên máy chủ proxy LiteLLM . Horizon3.ai đã xác nhận chuỗi khai thác này hoạt động hoàn hảo và đánh giá mức CVSS kết hợp là 10.0 – mức độ nghiêm trọng tối đa .

Kịch bản tấn công và hậu quả khôn lường

Khi kẻ tấn công chiếm được quyền thực thi lệnh trên máy chủ proxy LiteLLM, bề mặt tấn công mở rộng một cách nhanh chóng và đáng sợ:

• Thực thi lệnh tùy ý: Kẻ tấn công có thể cài đặt cửa hậu (backdoor), phần mềm độc hại, công cụ đào tiền mã hóa, hoặc bất kỳ phần mềm nào mà quyền của tiến trình cho phép .
• Đánh cắp thông tin xác thực hàng loạt: Proxy LiteLLM nằm giữa các ứng dụng và hàng chục nhà cung cấp mô hình ngôn ngữ lớn (LLM). Nó lưu trữ khóa API cho OpenAI, Anthropic, Azure, AWS Bedrock, Google và nhiều dịch vụ khác trong cơ sở dữ liệu hoặc biến môi trường . Khai thác lỗ hổng này cho phép kẻ tấn công đánh cắp mọi thông tin xác thực được lưu trữ chỉ trong một thao tác.
• Di chuyển ngang trong hạ tầng AI: Với các khóa API đám mây bị đánh cắp và quyền truy cập shell vào máy chủ proxy, kẻ tấn công có thể dễ dàng xâm nhập vào các dịch vụ được kết nối, máy chủ MCP nội bộ, cơ sở dữ liệu vector, và các framework tác nhân AI (AI agent) ở phía sau .
• Ảnh hưởng hệ sinh thái rộng lớn: Bản thân lỗ hổng BadHost của Starlette ảnh hưởng đến hơn 400.000 dự án phụ thuộc, bao gồm các ứng dụng FastAPI, máy chủ vLLM, và các nền tảng tác nhân AI. Bất kỳ dự án nào sử dụng middleware xác thực dựa trên đường dẫn và đang dùng phiên bản Starlette cũ hơn 1.0.1 đều có nguy cơ bị vượt qua xác thực tương tự .

Vì sao động thái của CISA khiến mọi thứ trở nên cấp bách?

Việc CISA thêm CVE-2026-42271 vào danh mục KEV vào ngày 8 tháng 6 năm 2026 là một lời xác nhận rằng lỗ hổng này không chỉ là lý thuyết trên giấy. Những kẻ tấn công hiện đang tích cực vũ khí hóa nó . Đối với các cơ quan chính phủ liên bang Hoa Kỳ, Chỉ thị Hoạt động Ràng buộc 22-01 (Binding Operational Directive 22-01) yêu cầu họ phải vá tất cả các lỗ hổng trong danh sách KEV trong một khung thời gian cụ thể. Dù không bắt buộc về mặt pháp lý đối với khối tư nhân, CISA cũng khuyến nghị mạnh mẽ tất cả các tổ chức, cả công lẫn tư, nên coi đây là ưu tiên vá khẩn cấp .

Các bước khắc phục khẩn cấp

Việc vá lỗi cho chuỗi khai thác này yêu cầu hành động trên hai mặt trận, cùng với các biện pháp phòng thủ chuyên sâu để giảm thiểu rủi ro lộ lọt thông tin xác thực:

1. Nâng cấp LiteLLM lên phiên bản 1.83.7 trở lên. Bản phát hành này loại bỏ khả năng thực thi lệnh do người dùng cung cấp từ các điểm cuối kiểm tra MCP, đóng hoàn toàn vector chèn lệnh .
2. Nâng cấp Starlette lên phiên bản 1.0.1 trở lên. Bản vá này xác thực các tiêu đề Host đến dựa trên đặc tả URL và bỏ qua các tiêu đề chứa ký tự không hợp lệ, ngăn chặn kỹ thuật 'đánh lừa' đường dẫn vốn là trung tâm của việc vượt qua xác thực .
3. Xoay vòng ngay lập tức mọi thông tin xác thực đã lưu. Hãy mặc định rằng bất kỳ khóa API, mã thông báo truy cập, hay thông tin xác thực cơ sở dữ liệu nào mà proxy LiteLLM từng lưu trữ đều đã bị xâm phạm. Hãy xoay vòng tất cả các khóa của OpenAI, Anthropic, Azure, AWS và các nhà cung cấp khác, đồng thời kiểm tra hóa đơn để phát hiện các hoạt động sử dụng trái phép .
4. Chặn các điểm cuối nguy hiểm tại reverse proxy hoặc WAF. Đây là biện pháp phòng thủ chuyên sâu trong lúc bạn đang triển khai các bản vá. Hãy cấu hình reverse proxy hoặc tường lửa ứng dụng web (WAF) của bạn để chặn mọi yêu cầu đến

   POST /mcp-rest/test/connection

   và

   POST /mcp-rest/test/tools/list

   trước khi chúng đến được ứng dụng .
5. Kiểm tra lại nhật ký để phát hiện truy cập trái phép. Rà soát nhật ký proxy LiteLLM để tìm các hoạt động bất thường trên các điểm cuối kiểm tra MCP, đặc biệt là các yêu cầu đến từ địa chỉ IP không mong đợi hoặc những yêu cầu có tiêu đề Host bị thao túng .

Với mức độ nghiêm trọng kết hợp CVSS 10.0, tình trạng đang bị khai thác thực tế, và việc bị CISA đưa vào danh sách KEV, các tổ chức đang vận hành LiteLLM hoặc các dịch vụ sử dụng Starlette nên coi đây là một sự kiện 'vá-và-xoay vòng' khẩn cấp. Cánh cửa cho việc khai thác và đánh cắp thông tin xác thực đã mở và thời gian không còn nhiều.