Wiz: gần 1 trong 10 cổng LiteLLM bị lộ chấp nhận khóa quản trị mẫu sk-1234

Ngày 9 tháng 9 năm 2026, Wiz Research công bố một nghiên cứu về LiteLLM, cổng AI mã nguồn mở nằm giữa các ứng dụng và các nhà cung cấp mô hình mà chúng trả tiền, và báo cáo rằng 294 trong số 3.074 triển khai LiteLLM mà họ có thể tiếp cận trên internet công cộng — 9,6%, gần một phần mười — chấp nhận sk-1234, khóa chủ ví dụ được in trong tài liệu thiết lập của chính dự án, hoặc không yêu cầu thông tin xác thực nào cả. Chuỗi đó không phải là một khóa API thông thường: trong LiteLLM, nó vừa là thông tin xác thực quản trị viên vừa là công tắc bật xác thực, nên bất kỳ ai trình nó ra đều có thể đọc mọi khóa nhà cung cấp mô hình được lưu trên cổng, theo dõi mọi lời nhắc và phản hồi đi qua cổng, và truy cập mọi máy chủ công cụ được kết nối qua Model Context Protocol. Các đồng tác giả của Wiz, Amitai Cohen và Yaara Shriki, đã nối quyền truy cập đó với việc thực thi mã ở cấp root và đánh cắp thông tin xác thực IAM trên đám mây của máy chủ. Bài tường thuật này dựa trên báo cáo của Wiz, các khuyến cáo bảo mật của chính LiteLLM và danh sách Lỗ hổng đã bị khai thác đã biết của CISA được ban hành sau đó, và kho lưu trữ sự cố AI ghi lại hồ sơ này cùng với các hồ sơ lân cận, mỗi hồ sơ đều có nguồn, mức độ nghiêm trọng và mức độ tin cậy riêng.

Ngày xuất bản là ngày duy nhất mà bản ghi mang, và đó là ngày xuất bản. Bản quét đằng sau tiêu đề được chạy vào tháng 2 năm 2026; hai lỗ hổng mã mà Wiz mô tả đã có bản vá được phát hành muộn nhất vào giữa tháng 5, trong các bản phát hành mà hồ sơ của chính dự án ghi là tháng 3 và tháng 5; các mã định danh CVE được cấp vào tháng 7; và mục niêm yết trong danh mục xuất hiện vào tháng 9. Gần như mọi thứ trong báo cáo đã cũ vào thời điểm nó được in, và đó là phần lớn điều mà báo cáo lập luận.

Con số 9,6% là từ một lần quét và Wiz cho biết đợt theo dõi hồi tháng 8 của chính họ không thể so sánh với lần quét đó.

Phép đo rất đơn giản và Wiz trình bày phương pháp của mình một cách rõ ràng: 3.074 proxy LiteLLM hướng internet được tìm thấy qua Shodan vào tháng 2 năm 2026, mỗi proxy được kiểm tra xem liệu nó có xác thực bằng khóa ví dụ đã được tài liệu hóa hay không. Trong số đó, 294 proxy đã xác thực thành công. Trong nhóm đó, 191 proxy hoàn toàn không được cấu hình khóa chính và sẽ chấp nhận bất kỳ chuỗi nào được cung cấp; số còn lại đã để nguyên phần giữ chỗ của hướng dẫn thiết lập. Cả hai kiểu lỗi này đều không cần đến một lỗi phần mềm. Cả hai chỉ cần địa chỉ của gateway và giá trị được in trong README của chính dự án.

Đây cũng là kết quả quét của chỉ một nhà cung cấp. Con số của Wiz đã được Sáng kiến An toàn AI của Cloud Security Alliance nhắc lại vào ngày 10 tháng 9 và được The Hacker News nhắc lại cùng ngày, nhưng cả hai đều nhắc lại kèm ghi nguồn, và không tìm thấy bản sao độc lập nào của con số 3.074 cho bài viết này. Wiz đã chạy một cuộc quét thứ hai vào tháng 8 năm 2026 và phát hiện hơn 85.000 instance, gấp khoảng hai mươi bảy lần con số của tháng Hai. Công ty cho biết phần lớn trong số đó có vẻ là honeypot hoặc triển khai thử nghiệm, và hai con số không thể so sánh với nhau. Hiện không có con số phơi nhiễm hiện tại, và bất kỳ bài viết nào trích dẫn một con số như vậy đều đang trích dẫn con số của tháng Hai.

Một con số nữa trong báo cáo là dữ liệu telemetry của chính Wiz chứ không phải từ một lần quét: công ty cho biết LiteLLM có mặt trong khoảng một phần ba số môi trường đám mây mà họ quan sát. Đó là góc nhìn của một nhà cung cấp về cơ sở khách hàng của chính mình và đáng để tiếp nhận một cách thận trọng, nhưng nó giải thích vì sao các nhà nghiên cứu coi cấu hình sai của gateway là vấn đề đám mây chứ không phải vấn đề ứng dụng.

Khóa chính vừa là thông tin xác thực quản trị viên vừa là công tắc bật xác thực.

Thiết kế của LiteLLM giao cho một bí mật hai nhiệm vụ. Khóa chính xác thực các yêu cầu quản trị, và chính sự hiện diện của nó là thứ cho phép xác thực diễn ra: khi không có khóa chính và không có cấu hình JWT hay OAuth2, proxy sẽ chạy ở chế độ mở và chấp nhận mọi yêu cầu. Wiz đã tiếp cận cơ sở mã bằng Anthropic's Claude Code, tìm kiếm các tính năng nhận đầu vào do người dùng kiểm soát và truyền nó vào một ngữ cảnh thực thi, và trình xử lý xác thực là một trong ba bề mặt mà nó đã đánh dấu.

Trước v1.82.0-stable, hậu quả của tác vụ thứ hai đó còn tệ hơn một proxy mở. Wiz phát hiện rằng khi không có master key nào được đặt, trình xử lý xác thực đã gán vai trò PROXY_ADMIN cho mọi yêu cầu đến, vì vậy một bên gọi chưa xác thực không chỉ được chấp nhận mà còn được chấp nhận với tư cách quản trị viên. Yêu cầu kéo #22095, được trích dẫn trong báo cáo, đã thay đổi vai trò mặc định thành INTERNAL_USER và thêm kiểm tra quản trị vào các điểm cuối guardrail.

Quyền truy cập quản trị vào một gateway không phải là một đặc quyền hẹp. Instance nắm giữ khóa API cho mọi nhà cung cấp mà nó định tuyến tới, và chính điều đó khiến nó trở thành mục tiêu của LLMjacking — chạy khối lượng công việc mô hình trên hóa đơn của nạn nhân. Nó nhìn thấy các prompt và completion. Nó kết nối ra ngoài tới các máy chủ công cụ MCP, mà trong một triển khai nội bộ có khả năng bao gồm trình theo dõi vấn đề, chat, cơ sở dữ liệu và các pipeline triển khai.

Wiz cũng đã chứng minh một đường đi từ vị trí quản trị đó đến danh tính đám mây của máy chủ. LiteLLM cho phép quản trị viên đăng ký một tuyến chuyển tiếp đến bất kỳ URL đích nào, và đích không được kiểm tra đối chiếu với các dải địa chỉ riêng, localhost hay địa chỉ metadata đám mây. Trỏ một tuyến vào dịch vụ metadata của instance sẽ trả về thông tin xác thực IAM mà workload đang chạy dưới quyền đó. Chuyển dịch vụ metadata sang IMDSv2, vốn thường vô hiệu hóa loại giả mạo yêu cầu này bằng cách yêu cầu một token phiên lấy riêng, cũng không giúp được gì: LiteLLM chuyển tiếp mọi header được gắn tiền tố x-pass- tới đích với tiền tố bị loại bỏ, nên header token có thể bị lén chuyển qua. Wiz nói rằng có thể coi tính năng này đang hoạt động đúng như thiết kế trong một mô hình mối đe dọa tin tưởng quản trị viên, và do đó nó không có CVE và không có bản vá.

Đoạn cuối cùng đó là một minh họa, không phải một cuộc tấn công đã được quan sát. The Hacker News, khi đưa tin về nghiên cứu vào ngày 10 tháng 9, nêu rằng không có nguồn nào báo cáo việc có ai thực hiện điều đó nhắm vào một triển khai thực tế, và rằng nó trước tiên yêu cầu quyền quản trị. Cách diễn đạt của Wiz cũng tương tự: cơ chế chuyển tiếp là một thuộc tính thiết kế chỉ trở thành lỗ hổng khi thông tin xác thực quản trị viên là một chuỗi lấy từ tài liệu.

8.8 và 2.1 đang đánh giá cùng một chuỗi từ những vị trí xuất phát khác nhau

Hai CVE mang các phát hiện kỹ thuật, và điểm số được công bố của chúng khó có thể chênh lệch xa hơn được nữa.

CVE-2026-59822 là lỗ hổng bỏ qua xác thực MCP, và bản tư vấn của LiteLLM đánh giá nó ở mức High, 8.8 theo CVSS 4.0, không yêu cầu đặc quyền, không cần tương tác của người dùng và không có yêu cầu tấn công. Điểm cuối MCP có trình xử lý xác thực riêng, được xây dựng để chấp nhận khóa LiteLLM hoặc token OAuth2 dành cho máy chủ công cụ thượng nguồn. Khi một token không vượt qua bước kiểm tra của LiteLLM, trình xử lý bắt lỗi 401 và thay thế bằng một đối tượng xác thực rỗng thay vì từ chối yêu cầu. Do đó, bất kỳ token Bearer nào cũng tạo ra một phiên MCP hợp lệ, kể cả chỉ một ký tự: bản chứng minh khái niệm của Wiz gửi một token bearer một chữ cái và nhận lại mã định danh phiên. Lỗ hổng đã được sửa trong phiên bản 1.84.0.

CVE-2026-59821 là lỗ hổng guardrail, và bản khuyến cáo của chính dự án này đánh giá nó ở mức Low, 2.1, yêu cầu đặc quyền cao và có các yêu cầu tấn công. Tính năng guardrail mã tùy chỉnh cho phép quản trị viên gửi mã Python mà máy chủ biên dịch và thực thi. Điểm cuối kiểm thử của Web UI đã xác thực mã dựa trên danh sách các mẫu bị cấm và loại bỏ builtins trước khi chạy; còn các điểm cuối tạo và cập nhật trên production thì không làm cả hai việc đó. Python tự khôi phục builtins khi chúng không tồn tại, vì vậy mã được gửi lên đã chạm tới thư viện chuẩn. Bản proof of concept của Wiz đăng ký một guardrail chạy lệnh shell ngay tại thời điểm đăng ký — trước bất kỳ yêu cầu mô hình nào — và trả về đầu ra của lệnh làm lý do chặn, mà trong thử nghiệm của họ kết quả trả về là root. Lỗ hổng đã được vá trong v1.82.0-stable.

Hai mô tả này tương thích với nhau, và câu hòa giải nằm ngay trong chính bản khuyến nghị bảo mật: LiteLLM lưu ý rằng trong các triển khai không cấu hình master key, người gọi có thể bị coi là quản trị viên proxy, và đó chính là điều khiến các endpoint guardrail nằm trong tầm với. A 2.1 giả định một người dùng có đặc quyền. Chuỗi của Wiz là điều xảy ra khi khóa mặc định khiến mọi người gọi đều có đặc quyền. Không điểm số nào sai về vị trí xuất phát của chính nó; chúng bất đồng về tần suất vị trí đó trống.

Có một lưu ý đối với tuyên bố của Wiz rằng sau 1.82.0, kẻ tấn công nắm giữ khóa mặc định chỉ có thể thực thi mã bên trong một sandbox. The Hacker News chỉ ra một bản tư vấn riêng từ tháng 5 năm 2026, CVE-2026-40217, mô tả việc thoát khỏi sandbox đó thông qua các kỹ thuật bytecode trong các phiên bản từ 1.81.8 đến trước 1.83.10, bên trong một tiến trình proxy mà bản tư vấn cho biết chạy với quyền root trong image container mặc định. Để đạt được điểm cuối đó cần thông tin xác thực quản trị viên proxy, mà đó chính xác là khóa chính.

Con số 8.8 cũng không mang tính phổ quát. Ghi chú nghiên cứu của Cloud Security Alliance nhận định rằng khuyến cáo của GitLab liệt kê điểm cơ sở là 8.2 cho cùng lỗ hổng và từ chối phân xử giữa hai phương pháp, chỉ lưu ý rằng cả hai đều nằm trong ngưỡng cao. Mức độ nghiêm trọng high trong hồ sơ không phụ thuộc vào việc dùng con số nào.

Một CVE đã bị khai thác trong thực tế; sự cố lộ khóa mặc định không có nạn nhân được nêu tên.

CISA đã thêm CVE-2026-59822 vào danh mục Lỗ hổng bị khai thác đã biết vào ngày 2 tháng 9 năm 2026 và đặt hạn chót khắc phục là ngày 16 tháng 9 năm 2026 cho các cơ quan dân sự liên bang; mục trong danh mục mang CWE-287 và CWE-306, xác thực không đúng và thiếu xác thực. Ghi chú của Cloud Security Alliance báo cáo rằng các tổ chức theo dõi trong ngành đã mô tả đây là lỗ hổng đầu tiên dành riêng cho MCP trên danh sách đó. Wiz đã công bố việc khai thác mà họ quan sát được: từ ngày 7 tháng 7 năm 2026, các honeypot của họ đã ghi nhận các yêu cầu mang token bearer một ký tự thăm dò các điểm cuối liệt kê mô hình, và Wiz mô tả không có cách sử dụng nào khác của lỗ hổng này.

Không có gì tương đương tồn tại đối với khóa mặc định. Không có nạn nhân nào được nêu tên, không có cổng kết nối nào được xác định là đã bị chiếm đoạt thông qua sk-1234, và không có dữ liệu từ xa nào cho thấy 294 máy chủ đang bị sử dụng. Mục lưu trữ không ghi nhận tổn hại thực tế nào, đây là một tuyên bố về bằng chứng chứ không phải về cơ chế: mức độ phơi nhiễm đã được đo lường, chứ không phải được chứng kiến là đang bị sử dụng.

Hai mục khác thường được xếp cùng những mục này và không phải là cùng một thứ. CVE-2026-42271, thực thi lệnh thông qua hai endpoint kiểm thử MCP, là lỗ hổng LiteLLM mà kẻ tấn công đã thực sự sử dụng để chạy mã; các honeypot của Wiz đã ghi nhận nó cài đặt một trình đào tiền mã hóa. Vụ việc tháng 8 năm 2026 mà Microsoft công bố, trong đó một kẻ xâm nhập đã đọc các biến môi trường của container gateway, khôi phục khóa chính, các khóa nhà cung cấp và một chuỗi kết nối cơ sở dữ liệu, rồi sao chép các bản ghi từ bảng model và virtual-key của LiteLLM, minh họa giá trị của một gateway bị xâm phạm hơn là một cách xâm nhập mới; The Hacker News đưa tin rằng Microsoft đánh giá điểm xâm nhập là chuỗi CVE-2026-42271.

Lập trường của những người duy trì là việc thiếu khóa chính (master key) là một lỗi thiết lập, không phải lỗ hổng bảo mật.

Chính sách bảo mật của LiteLLM rất rõ ràng. Trong danh sách các vấn đề nằm ngoài phạm vi, chính sách này có nêu "các cuộc tấn công đòi hỏi phải cấu hình sai khi thiết lập (ví dụ: không đặt master_key trong cấu hình proxy)", đồng thời khẳng định rằng những vấn đề này rõ ràng nằm ngoài phạm vi và không được coi là lỗ hổng. Wiz cũng đưa ra một kết luận tương thích theo hướng ngược lại khi cho rằng hành vi chuyển tiếp có thể được xem là đang hoạt động đúng như thiết kế.

Lập trường đó đã được kiểm chứng công khai. Vào ngày 15 tháng 8 năm 2026, một nhà nghiên cứu đã mở issue GitHub #37054, báo cáo rằng một proxy không đặt LITELLM_MASTER_KEY sẽ xác thực mọi giá trị khóa và rằng tệp docker-compose đi kèm không đặt khóa này. Issue đã bị đóng 30 phút sau đó, và bình luận duy nhất trên đó đến từ cùng tài khoản: bình luận này viện dẫn chỉ dẫn của chính sách bảo mật rằng báo cáo phải đi qua kênh báo cáo lỗ hổng riêng tư thay vì issue công khai, xin lỗi vì đã gửi công khai, và nói rằng toàn bộ báo cáo đang được gửi qua kênh advisory thay vào đó. Không có phản hồi nào của người bảo trì xuất hiện trên thread, nên hồ sơ cho thấy người báo cáo rút báo cáo công khai chứ không phải dự án phản hồi lại báo cáo đó. Không có gì công khai ghi lại điều gì đã xảy ra với bản gửi riêng tư.

Không tìm thấy bất kỳ tuyên bố công khai nào từ BerriAI bảo vệ hoặc sửa đổi quan điểm đó về báo cáo tháng Chín cho bài viết này. Phản hồi có thể thấy được của công ty nằm trong ghi chú phát hành và các tệp cấu hình của họ chứ không phải ở dạng văn xuôi.

Đợt cưỡng chế diễn ra vào ngày 3 tháng 10, hai mươi bốn ngày sau báo cáo.

Hai lỗi mã nguồn đã được sửa từ rất lâu trước báo cáo. Dòng thời gian công bố của Wiz ghi nhận việc thực thi mã guardrail được báo cáo vào ngày 18 tháng 2 năm 2026 và được sửa vào ngày 25 tháng 2 trong v1.82.0, lỗi vượt qua MCP được sửa vào ngày 25 tháng 4 trong v1.84.0, việc khai thác được quan sát vào ngày 7 tháng 7, các mã định danh CVE được công bố vào ngày 8 tháng 7 và việc đưa vào danh mục vào ngày 2 tháng 9. Các artefact phát hành mang ngày muộn hơn ngày sửa lỗi: chỉ mục gói cho thấy v1.82.0 vào ngày 1 tháng 3 năm 2026 và v1.84.0 vào ngày 14 tháng 5, đánh dấu thời điểm mỗi bản sửa trở nên có thể cài đặt chứ không phải thời điểm nó được đưa vào. Hai hồ sơ phát hành của chính chủ ghi ngày cho cùng các bản sửa đó muộn hơn dòng thời gian này. Bản phát hành v1.82.0-stable trên GitHub mang ngày 11 tháng 3 năm 2026 và gói 1.82.0 trên PyPI ngày 1 tháng 3; v1.84.0 được ghi ngày 14 tháng 5 năm 2026 trên cả hai. Không có tài liệu nào được công bố giải thích khoảng cách này, và điều đó không ảnh hưởng đến lập luận, vì mọi ngày trong số đó đều rơi vào nhiều tháng trước báo cáo tháng 9. Hai tư vấn bảo mật trên GitHub còn thêm một ngày thứ ba: chúng được công bố vào ngày 30 tháng 6 năm 2026, ba tuần trước các mã định danh CVE mà Wiz nói đã được phát hành vào ngày 8 tháng 7.

Điều mà không bản phát hành nào trong số đó khắc phục được là giá trị mặc định. Wiz báo cáo rằng tính đến ngày 9 tháng 9, khóa master vẫn được đặt thành sk-1234 khi cài đặt LiteLLM thông qua Docker Compose hoặc pip install, và The Hacker News đã xác nhận hướng dẫn thiết lập vẫn sử dụng giá trị đó vào ngày hôm đó. Thay đổi đến với v1.104.0, được tải lên Python Package Index vào ngày 3 tháng 10 năm 2026, với ghi chú phát hành liệt kê đây là thay đổi phá vỡ tương thích: proxy giờ từ chối khởi động nếu khóa master chưa được đặt, trống hoặc đã được công khai, chỉ ra nguồn của giá trị không hợp lệ trong lỗi khởi động và in ra một lệnh tạo khóa an toàn. Một mục đi kèm ghi lại thay đổi nhằm ngừng quảng bá một giá trị khóa master yếu đã được công khai trong các cấu hình và ví dụ được phát hành kèm, và tệp docker-compose trên nhánh chính của dự án không còn đặt bất kỳ khóa nào nữa.

Đó là trình tự đáng giữ lại. Mã đã được vá vào mùa xuân. Giá trị khiến những bản vá đó không đủ vẫn nằm trong hướng dẫn cài đặt đến tận tháng Mười, và chỉ đến lúc đó phần mềm mới bắt đầu từ chối nó. Không có gì trong bản sửa nào buộc bản sửa kia phải chờ.

Điều chưa thay đổi là tuyến pass-through tới dịch vụ metadata của instance. Nó vẫn không có CVE và không có bản vá, vì dự án coi quản trị viên là đáng tin cậy. Do đó, danh sách khắc phục của Wiz chủ yếu là việc của người vận hành: một khóa chính mạnh và duy nhất, rà soát các guardrail đã đăng ký rồi khởi động lại tiến trình để xóa mã đang được giữ trong bộ nhớ, kiểm toán các endpoint pass-through với lưu lượng ra của container bị hạn chế, và các vai trò IAM đặc quyền tối thiểu. Không có việc nào trong bốn việc đó đạt được chỉ bằng cách nâng cấp.

Điều mà hồ sơ không xác lập

• Không tìm thấy bản tái lập độc lập nào của đợt quét 3.074 máy chủ. Con số 9,6% là kết quả đo của Wiz, và mọi tường thuật khác về con số này đều nhắc lại nó kèm ghi nguồn.

• Hiện không có số liệu phơi nhiễm hiện tại. Báo cáo theo dõi tháng 8 đã phát hiện {{1}}hơn 85.000 instance{{/1}}, mà Wiz cho biết phần lớn là honeypot hoặc môi trường triển khai thử nghiệm và không thể so sánh với con số của tháng 2.

• Không có nạn nhân nào. Không có mục nào trong hồ sơ nêu tên một gateway, một nhà vận hành hoặc một tài khoản đám mây bị xâm phạm thông qua khóa mặc định, và hoạt động khai thác mà Wiz ghi nhận là việc vượt qua MCP chứ không phải sk-1234.

• Không có bằng chứng rằng 294 máy chủ đã được sử dụng. Bản quét chỉ kiểm tra liệu chúng có xác thực được hay không, một tuyên bố yếu hơn so với việc chứng minh rằng ai đó đã thực sự làm vậy.

• Không có mức độ nghiêm trọng thống nhất cho lỗ hổng guardrail. Wiz và các nhà bảo trì mô tả cùng một hành vi nhưng đánh giá nó rất khác nhau, và sự khác biệt nằm ở các đặc quyền mà mỗi bên cho rằng kẻ tấn công đã có sẵn.

Wiz cũng là một nhà cung cấp bảo mật đám mây bán dịch vụ phát hiện cho loại lộ lọt này, và báo cáo kết thúc bằng một mục về cách các sản phẩm của chính họ xác định các triển khai LiteLLM, các phiên bản dễ bị tổn thương và các instance shadow. Đó là bối cảnh để đọc phần khắc phục, không phải lý do để xem nhẹ một phép đo mà các chi tiết kỹ thuật của nó được chính các khuyến cáo của nhà bảo trì xác nhận.

Phần của bản ghi vượt ra ngoài LiteLLM là khoảng thời gian giữa hai ngày. Lỗ hổng đã được đóng vào mùa xuân. Giá trị mặc định khiến lỗ hổng trở nên quan trọng đối với một người lạ vẫn được in trong hướng dẫn cài đặt vào tháng Chín, và phần mềm chỉ bắt đầu từ chối nó vào tháng Mười. Những người vận hành đã thay đổi chuỗi không bao giờ phải chờ đợi bất kỳ điều nào trong số đó.