BerriAI LiteLLM: bypass xác thực MCP qua OAuth2 passthrough fallback

LiteLLM là một proxy server (AI Gateway) để gọi các API LLM theo định dạng OpenAI (hoặc native). Trước phiên bản 1.84.0, MCP Streamable HTTP endpoint của LiteLLM cho phép kẻ tấn công chưa được xác thực sử dụng một header Authorization giả để kích hoạt nhánh fallback OAuth2 passthrough, nhánh này thay thế việc xác thực LiteLLM key thất bại bằng một đối tượng UserAPIKeyAuth() rỗng, cho phép các yêu cầu tiếp cận MCP tooling mà không cần LiteLLM key hợp lệ. Vấn đề này đã được khắc phục trong phiên bản 1.84.0.

• Gói PyPI litellm do BerriAI phát hành bị ảnh hưởng ở các phiên bản < 1.84.0.
• Bản sửa được xác nhận trong phiên bản 1.84.0.
• Phạm vi liên quan là MCP Streamable HTTP endpoint và logic xác thực MCP có hỗ trợ OAuth2 passthrough. Các hệ thống không bật hoặc không công khai MCP route vẫn cần được kiểm tra để xác nhận chúng không thể tiếp cận đường xử lý bị ảnh hưởng; bằng chứng hiện có không cho phép suy ra trạng thái an toàn chỉ từ việc endpoint không được quảng bá.
• Bản sửa của nhà cung cấp cũng siết chặt public-route detection trong cùng MCP handler. Trạng thái của các cấu hình, nhánh phát hành hoặc bản build tùy biến không được nêu trực tiếp trong bản ghi cần được xác minh riêng.

BerriAI LiteLLM xử lý xác thực riêng cho MCP Streamable HTTP trong MCP authentication handler. Khi yêu cầu có header Authorization nhưng việc kiểm tra LiteLLM key thất bại với lỗi 401 hoặc 403, nhánh OAuth2 passthrough có thể coi header đó là token dành cho MCP server upstream và thay thế kết quả lỗi bằng một đối tượng rỗng UserAPIKeyAuth(). Do đó, một Bearer token giả có thể biến lần xác thực thất bại thành phiên MCP được chấp nhận, cho phép yêu cầu tiếp tục đến các công cụ MCP mà không có LiteLLM key hợp lệ.

Điều kiện khai thác là dịch vụ phải có MCP Streamable HTTP endpoint có thể truy cập qua mạng và yêu cầu phải đi vào nhánh fallback nêu trên. Bản sửa của nhà cung cấp giới hạn fallback chỉ cho trường hợp mọi MCP server mà yêu cầu nhắm tới được cấu hình rõ ràng với auth_type=oauth2; các target không xác định hoặc target dùng cơ chế xác thực khác phải giữ nguyên lỗi xác thực. Bản sửa cùng handler cũng thay phép kiểm tra chuỗi .well-known trên toàn bộ URL bằng kiểm tra tiền tố đường dẫn /.well-known/, nhằm ngăn việc đánh lừa kiểm tra public route bằng query string, hostname hoặc đoạn đường dẫn khác. Mô tả CVE được cung cấp tập trung vào OAuth2 passthrough fallback; phạm vi cấu hình cụ thể của từng MCP server vẫn cần được kiểm tra trong môi trường triển khai.

Lỗ hổng có thể bị khai thác từ xa qua mạng đối với MCP endpoint có thể truy cập. Kẻ tấn công không cần xác thực trước, không cần người dùng tương tác và không cần quyền đặc biệt; độ phức tạp khai thác được ghi nhận là thấp. Vectơ chính là gửi một header Authorization chứa Bearer token giả để kích hoạt OAuth2 passthrough fallback sau khi LiteLLM key validation thất bại.

Bản ghi được cung cấp đánh dấu lỗ hổng đã bị khai thác và có public exploit. Wiz cũng báo cáo đã quan sát hoạt động khai thác trong hạ tầng honeypot. Bằng chứng hiện có không nêu tên nạn nhân, chiến dịch hoặc phạm vi tổ chức cụ thể.

Khai thác thành công khiến LiteLLM xử lý yêu cầu như một MCP session đã được xác thực dù người gửi không có LiteLLM key hợp lệ. Kẻ tấn công có thể liệt kê và gọi các MCP tool được phép truy cập qua proxy, từ đó đọc dữ liệu hoặc tạo thay đổi trên các dịch vụ kết nối nếu tool hỗ trợ những thao tác đó.

Tác động bảo mật có thể bao gồm mất tính bí mật đối với dữ liệu do MCP cung cấp và ảnh hưởng tính toàn vẹn đối với các tool có khả năng thay đổi trạng thái. Tác động đến tính sẵn sàng không được mô tả là hậu quả trực tiếp trong bản ghi. Phạm vi cuối cùng phụ thuộc vào target MCP server, quyền của từng tool và dữ liệu mà các dịch vụ phía sau cung cấp.

Kẻ tấn công có thể sử dụng MCP session được chấp nhận trái phép để liệt kê các công cụ đã cấu hình và gọi những công cụ đó. Hậu quả có thể bao gồm đọc dữ liệu từ các dịch vụ kết nối, truy cập kết quả hoặc thông tin nhạy cảm do MCP cung cấp, và thực hiện các thao tác thay đổi dữ liệu nếu công cụ tương ứng cho phép.

Mức độ ảnh hưởng phụ thuộc vào phạm vi MCP server, quyền của từng tool và các hệ thống phía sau LiteLLM. Không có bằng chứng trong bản ghi cho thấy mọi triển khai đều cho phép thực thi mã, chiếm quyền toàn bộ máy chủ hoặc gây gián đoạn dịch vụ; các khả năng đó phải được đánh giá theo cấu hình thực tế.

1. Nâng cấp gói litellm lên phiên bản 1.84.0, là phiên bản được xác nhận đã sửa lỗi.
2. Nếu chưa thể nâng cấp ngay, vô hiệu hóa MCP routes hoặc chặn /mcp/ và các MCP endpoint liên quan tại reverse proxy hoặc API gateway.
3. Hạn chế quyền truy cập mạng đến MCP endpoint chỉ cho các nguồn tin cậy, đồng thời rà soát cấu hình để OAuth2 passthrough chỉ được bật cho các MCP server thực sự được cấu hình với auth_type=oauth2.
4. Vì bản ghi đánh dấu lỗ hổng đã bị khai thác, kiểm tra log truy cập, audit trail và hoạt động của các MCP server trước khi bản vá được triển khai. Nếu phát hiện yêu cầu MCP bất thường hoặc tool call không gắn với danh tính hợp lệ, xử lý theo quy trình ứng phó sự cố của tổ chức.

1. Kiểm kê các bản cài đặt litellm, xác định phiên bản và khoanh vùng các hệ thống đang bật hoặc công khai MCP Streamable HTTP. Các bản cài đặt thuộc phạm vi trước 1.84.0 cần được ưu tiên kiểm tra.
2. Rà soát reverse proxy, API gateway và firewall để tìm các tuyến /mcp/ cùng những MCP endpoint liên quan có thể truy cập từ Internet hoặc từ mạng không tin cậy.
3. Kiểm tra access log và audit log đối với các yêu cầu MCP có header Authorization: Bearer không tương ứng với LiteLLM key hợp lệ, đặc biệt khi yêu cầu vẫn thực hiện được các thao tác tools/list hoặc tools/call.
4. Đối chiếu các lần gọi MCP thành công với danh tính, API key và quyền truy cập hợp lệ. Việc không tìm thấy log đáng ngờ không chứng minh hệ thống chưa bị khai thác.
5. Kiểm tra cấu hình target MCP và xác nhận các server dùng OAuth2 passthrough thật sự được quản trị viên cấu hình với auth_type=oauth2. Ngoài ra, nên rà soát các yêu cầu MCP có chuỗi .well-known trong query string, hostname hoặc vị trí khác ngoài tiền tố đường dẫn /.well-known/, vì bản sửa của nhà cung cấp đã xử lý thêm điều kiện public-route liên quan này.