CISA thêm lỗ hổng vượt qua xác thực MCP của LiteLLM vào KEV: Chỉ cần bất kỳ token Bearer nào

Vào ngày 2 tháng 9 năm 2026, Cơ quan An ninh mạng và Hạ tầng Hoa Kỳ đã thêm CVE-2026-59822 vào danh mục Known Exploited Vulnerabilities của mình với tên gọi "BerriAI LiteLLM Improper Authentication Vulnerability", một trong bảy lỗ hổng trong lô ngày hôm đó. Lỗi nằm ở điểm cuối MCP Streamable HTTP của LiteLLM: khi việc xác thực khóa LiteLLM thất bại, cơ chế dự phòng chuyển tiếp OAuth2 đã thay bằng một đối tượng UserAPIKeyAuth() rỗng thay vì từ chối yêu cầu, vì vậy bất kỳ tiêu đề Authorization Bearer nào bị ngụy tạo đều mở được một phiên MCP đã xác thực. Kẻ tấn công truy cập được điểm cuối đó có thể liệt kê và gọi mọi công cụ MCP mà cổng đã được cấu hình, và thông qua các công cụ đó tiếp cận các dịch vụ phía sau chúng. Mọi phiên bản trước 1.84.0 đều bị ảnh hưởng, và các cơ quan dân sự liên bang được yêu cầu khắc phục trước ngày 16 tháng 9. Bản ghi này — mục KEV về lỗ hổng bỏ qua xác thực MCP của LiteLLM — là một mục trong OrcaRouter AI Incident Archive, nơi lưu giữ toàn bộ tập bản ghi và các mục lân cận của sự cố này.

Lý do khiến một lỗi trong proxy quan trọng hơn mức mà điểm CVSS của nó hàm ý là những gì nằm phía sau proxy. Nhóm nghiên cứu mối đe dọa của Wiz nói thẳng: “Một proxy LiteLLM có thể giữ khóa cho mọi nhà cung cấp mô hình mà nó định tuyến tới, bao gồm OpenAI, Anthropic, Azure và Gemini. Nó cũng có thể chạy với quyền IAM trên đám mây và kết nối tới các dịch vụ nội bộ thông qua các máy chủ công cụ MCP. Chỉ một lần bị xâm phạm cũng có thể cho kẻ tấn công quyền truy cập vào thông tin xác thực và các dịch vụ nằm sau proxy, chứ không chỉ bản thân proxy.” Wiz Research cho biết họ đã phát hiện ra lỗ hổng này, và các honeypot của Wiz sau đó đã ghi nhận các nỗ lực khai thác nó.

Cơ chế: một bước kiểm tra thất bại nhưng lại trả về một phiên hợp lệ

Bản tư vấn của chính BerriAI, GHSA-7488-6r32-c95q, mô tả lỗi này trong hai câu: "Trình xử lý xác thực MCP đã hỗ trợ OAuth2 passthrough cho các máy chủ MCP thượng nguồn, nhưng đường dự phòng có thể thay thế việc xác thực khóa LiteLLM bị lỗi bằng một đối tượng UserAPIKeyAuth() rỗng. Điều này cho phép các yêu cầu có tiêu đề Authorization được ngụy tạo tiếp cận công cụ MCP mà không cần khóa LiteLLM hợp lệ." Từ quan trọng là fallback. Mã có một nhánh dành cho các triển khai truyền thẳng token OAuth của máy chủ MCP thượng nguồn, và khi một khóa LiteLLM không xác thực được, nhánh đó trả về một đối tượng xác thực rỗng thay vì lỗi.

Một đối tượng xác thực rỗng không giống với việc không có đối tượng xác thực nào. Mã phía hạ nguồn thấy một UserAPIKeyAuth được khởi tạo thành công và tiếp tục, mà không có tenant, không có người dùng và không có phạm vi nào được gắn vào đó. Bài viết của Wiz thẳng thừng hơn về hậu quả thực tế: “khi xác thực token thất bại, thay vì từ chối yêu cầu, máy chủ trả về một đối tượng UserAPIKeyAuth() rỗng không có giới hạn nào. Bất kỳ token Bearer nào (thậm chí chỉ một ký tự, ví dụ: x) đều cấp toàn quyền truy cập MCP.”

Điều đó mang lại cho kẻ tấn công một menu lựa chọn. Giao thức MCP phơi bày một danh sách công cụ, vì vậy một phiên đã xác thực sẽ trả về tên và lược đồ của mọi công cụ mà gateway đã được cấu hình để truy cập — cơ sở dữ liệu, kho mã nguồn, API nội bộ, trong các ví dụ của Wiz. Khuyến cáo của nhà cung cấp nêu rõ tác động: “Kẻ tấn công có thể lợi dụng điều này để liệt kê và gọi các công cụ MCP đã được cấu hình, đồng thời truy cập các dịch vụ được kết nối được phơi bày qua MCP.” Sau đó, các lệnh gọi công cụ thực thi với bất kỳ quyền hạn nào mà bản thân proxy nắm giữ đối với các backend đó, đây chính là vấn đề tập trung thông tin xác thực mà Wiz mô tả.

Một bản vá vào tháng Năm, một CVE vào tháng Bảy, một hạn chót liên bang vào tháng Chín

Các mốc thời gian không khớp theo cách mà người đọc có thể giả định, và chính những khoảng trống mới là phần đáng chú ý. LiteLLM 1.84.0 — phiên bản đầu tiên mà bản khuyến cáo nêu là đã được vá — được tải lên PyPI vào ngày 14 tháng 5 năm 2026, theo siêu dữ liệu phát hành của chính chỉ mục gói. Mã định danh CVE được đăng ký với CVE Program vào ngày 7 tháng 7 năm 2026 và bản ghi được công bố vào ngày hôm sau, 8 tháng 7; mục OSV PYSEC-2026-3479 tiếp theo vào ngày 23 tháng 7. Việc đưa vào danh sách KEV diễn ra vào ngày 2 tháng 9, với hạn khắc phục là ngày 16 tháng 9.

Có hai điểm rút ra. Thứ nhất, bản dựng đã được vá đã công khai trong hơn ba tháng trước khi CISA liệt kê lỗ hổng là đã bị khai thác — vì vậy các tổ chức bị ràng buộc bởi thời hạn đã có sẵn một bản nâng cấp hoạt động được trong suốt thời gian đó, và việc bổ sung vào KEV không phải là thời điểm một bản sửa lỗi xuất hiện. Thứ hai, khoảng cách phiên bản đã nới rộng kể từ đó: bản phát hành LiteLLM hiện tại trên PyPI là 1.106.5, được tải lên vào ngày 27 tháng 10 năm 2026. Một triển khai vẫn đang ở bất kỳ phiên bản nào dưới 1.84.0 hiện đã chậm hơn hai mươi bản phát hành phụ, chứ không chỉ thiếu một bản vá.

Những gì danh sách niêm yết xác lập, và những gì nó không

Cảnh báo của CISA cho lô này nêu rằng các bổ sung được thực hiện "dựa trên bằng chứng về việc khai thác đang hoạt động", và mục có thể đọc bằng máy của danh mục cho CVE-2026-59822 có ngày thêm là 2 tháng 9 năm 2026, ngày đến hạn là 16 tháng 9 năm 2026, giá trị về việc được biết có sử dụng trong chiến dịch ransomware là "Không rõ", cùng hai điểm yếu: CWE-287 (xác thực không đúng) và CWE-306 (thiếu xác thực đối với chức năng quan trọng).

• Đã xác lập: CISA đánh giá lỗ hổng đang bị khai thác tích cực và đưa nó vào danh sách khắc phục của liên bang. Bản ghi SSVC của NVD, được gán cho CISA Coordinator và có dấu thời gian ngày 2 tháng 9 năm 2026, ghi nhận khai thác là "active", có thể tự động hóa là "yes" và tác động kỹ thuật là "partial".

• Đã xác lập: hoạt động khai thác đã được quan sát trong một môi trường được kiểm soát. Wiz đã công bố lưu lượng honeypot cho thấy các yêu cầu với token một ký tự thăm dò một endpoint liệt kê mô hình: một GET tới /v1/models mang "Authorization: Bearer x". The Hacker News, khi đưa tin về lô KEV vào ngày 3 tháng 9, đã mô tả cùng hoạt động đó là việc Wiz quan sát "các nỗ lực khai thác liên quan đến CVE-2026-59822 nhắm vào các honeypot của mình để thăm dò các endpoint liệt kê mô hình."

• Đã xác lập: các điểm mức độ nghiêm trọng đều tồn tại và khác nhau theo từng khung. Khuyến nghị của BerriAI đánh giá lỗ hổng theo CVSS 4.0 ở mức 8.8, cao, với tính bảo mật cao, tính toàn vẹn thấp và tính khả dụng không có; đánh giá CVSS 3.1 của chính NIST, vốn là đánh giá chính trong NVD, đặt nó ở mức 8.2. Hai con số mô tả cùng một khiếm khuyết theo các hệ thống tính điểm khác nhau và không nên được so sánh như thể cái này thay thế cái kia.

• Chưa xác lập: bất kỳ nạn nhân nào được nêu tên. Cảnh báo của CISA, khuyến cáo của BerriAI, bài viết của Wiz và đưa tin của The Hacker News đều không xác định được một tổ chức nào có các công cụ MCP bị truy cập thông qua lỗ hổng này, cũng không báo cáo về thông tin xác thực hoặc dữ liệu bị lấy từ một tổ chức như vậy. Hồ sơ công khai về việc khai thác là dữ liệu telemetry từ honeypot và một kết luận của liên bang, chứ không phải một vụ xâm phạm được công bố.

• Chưa được xác lập: rằng không có nhóm ransomware nào sử dụng nó. Trường KEV ghi là "Unknown", đây là giá trị do CISA gán, không phải là kết luận về việc không tồn tại theo bất kỳ hướng nào.

Tiền lệ tháng Sáu, và đây không phải là chuỗi thực thi mã từ xa đó

Đây là lỗ hổng LiteLLM thứ hai lọt vào danh mục KEV trong năm 2026, và lỗ hổng trước đó rất dễ bị nhầm lẫn với nó. CVE-2026-42271, được thêm vào ngày 8 tháng 6 năm 2026 với hạn chót là ngày 22 tháng 6, là một lỗ hổng chèn lệnh trong các endpoint kiểm thử máy chủ MCP của LiteLLM: Wiz mô tả các endpoint này cho phép người dùng kiểm thử cấu hình máy chủ MCP trước khi lưu, trong đó trường command được truyền tới tiến trình thực thi subprocess mà không hề được kiểm tra hợp lệ. Kẻ tấn công đã gửi một cấu hình máy chủ stdio giả mạo, với lệnh bên trong tải xuống và chạy một trình đào tiền mã hóa, đồng thời trả về một bắt tay MCP trông có vẻ hợp lệ để bài kiểm thử có vẻ như đã thành công. Mục nhập của CISA cho lỗ hổng này liệt kê CWE-78 và CWE-77 — chèn lệnh và chèn đối số, chứ không phải xác thực.

Đó là lỗ hổng có thể bị chuỗi hóa. Wiz cho biết CVE-2026-42271 “có thể được chuỗi với một lỗ hổng vượt qua kiểm tra tiêu đề máy chủ (host header) của Starlette (CVE-2026-48710) để đạt được RCE hoàn toàn không cần xác thực”, và rằng các nhà nghiên cứu bên ngoài đã liên kết nhóm ransomware Qilin với việc khai thác tích cực chuỗi đó. CVE-2026-48710 đã được thêm vào danh mục KEV trong cùng đợt ngày 2 tháng 9 với lỗ hổng vượt qua của LiteLLM, với cùng hạn chót ngày 16 tháng 9, và ghi chú danh mục của chính CISA về lỗ hổng Starlette nói rằng nó có thể được chuỗi với CVE-2026-42271. Mối liên hệ với Qilin thuộc về cặp lỗ hổng đó. Đây không phải là một phát hiện về CVE-2026-59822, và không có nội dung nào trong các nguồn được xem xét liên kết nhóm ransomware này với lỗ hổng vượt qua xác thực.

Một chi tiết hành chính phân biệt hai mục LiteLLM: hành động bắt buộc của mục tháng Sáu viện dẫn BOD 22-01, chỉ thị vận hành ràng buộc cũ hơn, trong khi mục tháng Chín viện dẫn BOD 26-04, “Ưu tiên cập nhật bảo mật dựa trên rủi ro”. Cảnh báo của CISA không giải thích sự thay đổi, và danh mục không chú thích điều đó.

Điều gì đã thay đổi sau

Con đường khắc phục rất ngắn. Khuyến cáo của BerriAI đề xuất nâng cấp lên 1.84.0 trở lên và đưa ra một cách xử lý tạm thời cho các nhóm không thể chuyển ngay: "vô hiệu hóa các tuyến MCP hoặc chặn quyền truy cập vào /mcp/ và các endpoint MCP liên quan tại reverse proxy hoặc API gateway của bạn." Cách xử lý tạm thời đó là một biện pháp thô — nó loại bỏ khả năng thay vì kiểm soát nó — nhưng đó là biện pháp giảm thiểu duy nhất mà nhà cung cấp nêu ra cho các triển khai chưa được vá.

Văn bản yêu cầu hành động của CISA dành cho các điểm xâm nhập đặt các cơ quan liên bang trước cùng một sự đánh đổi: áp dụng các biện pháp giảm thiểu theo hướng dẫn của nhà cung cấp và phù hợp với BOD 26-04, "hoặc ngừng sử dụng sản phẩm nếu không có biện pháp giảm thiểu", trong đó mỗi cơ quan chịu trách nhiệm đánh giá mức độ phơi nhiễm internet của một tài sản. Chỉ thị này chỉ ràng buộc đối với các cơ quan thuộc nhánh hành pháp dân sự liên bang; CISA khuyến khích các tổ chức khác áp dụng cách ưu tiên dựa trên rủi ro tương tự mà không bắt buộc.

Việc liệu có bất kỳ ai bên ngoài một honeypot đã hành động theo hạn chót hay không thì không được công khai. Cả CISA lẫn BerriAI đều chưa công bố số liệu về việc có bao nhiêu triển khai LiteLLM bị lộ, bao nhiêu đã được vá trước ngày 16 tháng 9, hoặc bao nhiêu đã bị truy cập thông qua đường vòng.

Những gì vẫn còn mở

Ba khoảng trống đáng được nêu rõ thay vì che đậy. Không có báo cáo sự cố công khai nào liên kết CVE-2026-59822 với một vụ xâm nhập cụ thể, nên việc đưa vào danh sách KEV dựa trên bằng chứng khai thác của CISA và các quan sát honeypot của Wiz chứ không dựa trên một nạn nhân được ghi nhận. Không có tuyên bố nào từ nhà cung cấp về việc đường dẫn dự phòng đã được viết theo cách đó như thế nào, hoặc nó đã tồn tại bao lâu trước 1.84.0 — bản khuyến cáo mô tả khiếm khuyết và bản sửa lỗi, chứ không mô tả lịch sử của nó. Và các thời hạn trong đợt này không đồng nhất: năm trong số bảy mục được thêm vào ngày 2 tháng 9 có thời hạn là ngày 5 tháng 9, trong khi các mục LiteLLM và Starlette có thời hạn là ngày 16 tháng 9. CISA không nói lý do.

Điều đã được xác định rõ thì hẹp hơn và hữu ích hơn điểm số. Trên các phiên bản bị ảnh hưởng, một ký tự đơn lẻ trong Authorization header không thể phân biệt với một khóa hợp lệ đối với MCP endpoint — và những phiên bản hoạt động theo cách đó đã không còn là phiên bản hiện hành từ tháng 5 năm 2026.