MaxKB: đường điều phối của tác nhân cho phép người dùng bị từ chối quyền truy cập một công cụ vẫn có thể gọi công cụ đó và đọc thông tin xác thực của nó.

MaxKB, trợ lý AI doanh nghiệp mã nguồn mở được 1Panel-dev duy trì, cung cấp danh sách quyền theo từng người dùng và từng công cụ để quản trị viên có thể cấp cho một thành viên không gian làm việc quyền dùng một công cụ và từ chối một công cụ khác. Theo bản tư vấn bảo mật công bố ngày 2 tháng 9 năm 2026, việc từ chối đó có hiệu lực trên các tuyến riêng của công cụ nhưng không có hiệu lực trên đường dẫn mà tác nhân hoặc quy trình làm việc dùng để gọi chính công cụ đó. Một thành viên không gian làm việc giữ vai trò thấp nhất có thể nêu mã định danh của một công cụ bị từ chối khi xây dựng quy trình làm việc, chạy quy trình làm việc đó và nhận không chỉ đầu ra của công cụ mà còn cả thông tin xác thực mà MaxKB giải mã ở phía máy chủ để chạy công cụ đó. Các phiên bản 2.0.0 đến 2.9.2 bị ảnh hưởng và bản tư vấn không nêu phiên bản nào đã được vá. Bản ghi này — lỗ hổng bỏ qua phân quyền điều phối công cụ của MaxKB — 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.

Điều khiến hồ sơ này đáng được đọc kỹ không phải là điểm số. Mà là việc sản phẩm đã có sẵn biện pháp kiểm tra đúng, áp dụng nó ở cánh cửa hiển nhiên, và để một cánh cửa thứ hai dẫn tới cùng khả năng đó không được giám sát. Bản tư vấn, GHSA-383v-fx78-pphm, được viết bởi nhà nghiên cứu đã phát hiện ra lỗ hổng và công bố qua hệ thống tư vấn của GitHub lúc 07:43 UTC ngày 2 tháng 9 năm 2026, ghi công Matteo Panzeri (@matte1782). Bản ghi CVE, CVE-2026-77516, tiếp theo vào ngày 21 tháng 9 năm 2026.

Những gì khuyến cáo này xác lập

Mô hình theo từng công cụ của MaxKB là WorkspaceUserResourcePermission, được mô tả trong bản khuyến nghị như một danh sách cho phép mặc định từ chối được phân giải tại thời điểm yêu cầu. Các tuyến công cụ chuyên dụng thực thi nó. Bản khuyến nghị liệt kê việc thực thi trong apps/tools/views/tool.py, nơi Operate.put, Operate.get, Debug.post, Export.get và Delete mỗi cái đều có kiểm tra quyền xem đối với quyền công cụ trong workspace của người gọi. Debug.post là tuyến gần nhất với việc chỉ đơn thuần chạy một công cụ, và nó được kiểm soát.

Đường dẫn điều phối agent và workflow không áp dụng lại kiểm tra đó. Bản khuyến nghị chỉ ra ba vị trí riêng biệt mà nó bị thiếu. Trong apps/application/serializers/application.py, serializer của application gán tool_ids, skill_tool_ids và mcp_tool_ids trực tiếp từ dữ liệu đầu vào của request mà không có ủy quyền theo từng tool — và bản khuyến nghị chỉ ra rằng sự bất đối xứng này có thể thấy ngay trong cùng tệp, bởi vì knowledge_id_list được kiểm chứng dựa trên các knowledge base mà người dùng có quyền truy cập ở vài dòng bên dưới, trong khi tool thì không. Trong apps/common/utils/shared_resource_auth.py, filter_authorized_ids cho mọi tool trong workspace của chính người gọi đi qua một cách vô điều kiện; cổng kiểm soát xuyên workspace mà nó dựa vào là một hook chỉ có ở bản enterprise, không có trong bản community, và nó không bao giờ truy vấn WorkspaceUserResourcePermission. Và tại điểm cuối, apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py chạy mã đã lưu của tool với init_params được giải mã bởi rsa_long_decrypt dưới danh tính của application, mà không có kiểm tra cấp quyền theo từng tool.

Bản khuyến nghị gọi kết quả này là thực thi confused-deputy: việc dispatch workflow chạy một công cụ, cùng các bí mật đã lưu của công cụ đó, mà chính người gọi ấy bị từ chối trên các route riêng của công cụ. Việc lộ thông tin xác thực là phần vượt quá mức sử dụng công cụ trái phép thông thường. Đối với một công cụ, init_params được mã hóa khi lưu trữ bằng RSA và chỉ được giải mã ở phía máy chủ tại thời điểm thực thi, vì vậy người gọi kích hoạt việc thực thi đó sẽ nhận được những giá trị mà họ chưa từng nắm giữ và không thể đã cung cấp.

Bằng chứng minh, qua chính những con số của nhà nghiên cứu

Bản khuyến cáo ghi nhận xác nhận động trên v2.9.2, được chạy từ image all-in-one chính thức, 1panel/maxkb:v2.9.2. Thiết lập gồm một workspace, một quản trị viên và một thành viên thứ hai giữ vai trò USER. Quản trị viên đã tạo Tool A và Tool B, đặt một bí mật ngẫu nhiên mới trong init_params của Tool B, và viết body của Tool B để trả về bí mật đó khi được thực thi. Sau đó, thành viên chỉ được cấp quyền theo từng công cụ cho Tool A, và bản khuyến cáo cho biết trạng thái không được cấp quyền đối với Tool B đã được kiểm tra lại trong cơ sở dữ liệu sau khi chạy.

Nửa bị từ chối của bài kiểm thử đã trả về đúng như sản phẩm cam kết. Với tư cách thành viên, tuyến gỡ lỗi cho Tool B trả về 403, tuyến cập nhật trả về 403, tuyến xuất trả về 403, và Tool A được cấp quyền trả về 200 như một bước kiểm tra nhanh. Nửa vượt qua sau đó đã liên kết Tool B vào một ứng dụng quy trình công việc thông qua một nút thư viện công cụ — liên kết được chấp nhận với HTTP 200 và không có kiểm tra theo từng công cụ — và việc chạy quy trình trả về HTTP 200 với nội dung chứa tên công cụ, bí mật sentinel, và danh sách khóa ["api_key"].

Bản khuyến nghị cho biết bí mật đã lộ ra ở ba lớp: trong phản hồi API của workflow, trong bản ghi thực thi công cụ với trạng thái SUCCESS, và trong hàng cơ sở dữ liệu nơi Tool B chứa init_params dưới dạng bản mã RSA 344 byte — đây là cách nhà nghiên cứu lập luận rằng giá trị đã được giải mã ở phía máy chủ dưới danh tính ứng dụng thay vì do bên gọi cung cấp. Cùng thành viên từng bị từ chối trên tuyến chạy của công cụ đã lấy được bí mật đã giải mã của công cụ bằng cách gắn nó vào một workflow.

Một điểm số được công bố, một điểm cao hơn được đưa ra tranh luận.

Điểm số gắn với CVE-2026-77516 là CVSS 3.1 5.4, Trung bình, với vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. Bản ghi của NVD cho thấy điểm đó có nguồn từ nguồn cấp tư vấn của GitHub chứ không phải từ phân tích của chính NVD, và mục này mang trạng thái Deferred, nghĩa là NVD chưa bổ sung thông tin cho mục đó. Phân loại của chính kho lưu trữ tuân theo điểm đã công bố đó: mức độ nghiêm trọng trung bình, không ghi nhận tác hại trong thực tế.

Phần tác động của chính bản khuyến cáo lập luận rằng cần cao hơn. Bản khuyến cáo nêu mức độ nghiêm trọng 7.1, Cao, trên một vector làm tăng tác động lên tính bảo mật lên mức cao, và cho biết con số này tăng lên 8.1 khi công cụ được điều phối thực hiện ghi có đặc quyền dưới danh tính ứng dụng. Đó là bất đồng về cách tính mức độ phơi lộ thông tin xác thực, không phải về việc cơ chế vượt qua có tồn tại hay không — cùng một tài liệu vừa chứng minh khiếm khuyết vừa lập luận rằng nó đang bị đánh giá thấp. Không có gì trong hồ sơ công khai giải quyết được con số nào đúng, và xếp hạng trung bình của kho lưu trữ bám theo điểm CVE đã công bố thay vì lập luận của bản khuyến cáo.

Hai đánh giá bổ sung nữa đã được ghi nhận. Các điểm quyết định SSVC của CISA, được thêm vào mục NVD ngày 28 tháng 9 năm 2026, ghi nhận khả năng khai thác là "poc", khả năng tự động hóa là "no", và tác động kỹ thuật là "partial" — giá trị "poc" phản ánh rằng có tồn tại một bằng chứng khái niệm, đúng là có, ngay trong chính bản khuyến cáo; đây không phải là kết luận về việc bị khai thác trong thực tế. Mô hình EPSS của FIRST đưa ra xác suất bị khai thác trong 30 ngày tới là 0,242%, ở phân vị thứ 15,2, trong ước tính ngày 27 tháng 10 năm 2026.

Một bản sửa lỗi có từ trước khuyến cáo, và không có bản nào trong phạm vi bị ảnh hưởng

Bảng phiên bản của bản tư vấn ghi rằng các phiên bản bị ảnh hưởng là từ 2.0.0 đến 2.9.2, phiên bản đã vá: không có, và nội dung của bản tư vấn nói rằng không có phiên bản khắc phục nào tại thời điểm đánh giá, đồng thời bổ sung rằng một bản sửa trong bản phát hành có gắn thẻ sẽ cho phép CVE neo vào đó. Kho lưu trữ của nhà cung cấp kể một câu chuyện hơi khác, và sự khác biệt này quan trọng với bất kỳ ai đang quyết định sẽ chạy phiên bản nào.

Trong kho lưu trữ MaxKB, các hàm đóng đường điều phối — validate_bound_tool_permissions và get_authorized_tool_ids trong apps/application/serializers/application.py — không có trong thẻ v2.9.2 và trong v2.10.2-lts, v2.10.3-lts và v2.10.4-lts, mà có từ v2.10.5-lts trở đi. Bản phát hành đó được công bố vào ngày 6 tháng 8 năm 2026, bốn tuần trước bản khuyến nghị. Cùng thẻ đó bổ sung kiểm tra công cụ theo từng người dùng vào base_tool_lib_node.py, dựa trên WorkspaceUserResourcePermission, và bổ sung bộ lọc nhận biết người dùng vào shared_resource_auth.py — nghĩa là về cơ bản, nó triển khai ba bước khắc phục mà bản khuyến nghị sau đó đề xuất.

Chưa ai công khai nêu mối liên hệ đó. Ghi chú phát hành v2.10.5-lts không đề cập đến bản sửa lỗi phân quyền công cụ; chúng liệt kê bốn mục bảo mật không liên quan và một loạt công việc tính năng và sửa lỗi. Bản khuyến cáo không nêu tên 2.10.5, và phạm vi bị ảnh hưởng của nó chỉ dừng ở 2.9.2, bản phát hành cuối cùng của dòng 2.9. Lịch sử phát hành cho thấy không có bản vá 2.9.x nào sau bản khuyến cáo, vì vậy một triển khai trên 2.9.2 không có bản dựng đã sửa lỗi trong chính dòng của nó. Bản phát hành hiện tại là v2.10.8-lts, được công bố vào ngày 22 tháng 10 năm 2026, có ghi chú mô tả các bản sửa lỗi X-Pack đối với việc cấp quyền cho công cụ dùng chung chứ không phải bất cứ điều gì trong đường dẫn điều phối của bản cộng đồng.

Điều gì chưa được thiết lập

Có ba điều đáng tách bạch khỏi phần trình diễn. Thứ nhất, không có báo cáo công khai nào về việc bypass này bị lợi dụng nhắm vào bất kỳ ai. Hồ sơ ghi nhận là một lỗ hổng đã được phát hiện, không phải một vụ xâm nhập đã được điều tra; nó không có nạn nhân, không có tác nhân được quy kết và không có thiệt hại, và bản chứng minh khái niệm của khuyến cáo được nhà nghiên cứu chạy trong một không gian làm việc có kiểm soát. Thứ hai, dường như không có cơ quan báo chí, cơ quan quản lý hay nhóm nghiên cứu thứ hai nào đã phân tích lỗ hổng này: các bài đưa tin hiện có chỉ giới hạn ở các cơ sở dữ liệu và trình tổng hợp lỗ hổng — trong đó có VulDB, cơ sở dữ liệu của Rapid7, Armis, SOCRadar và openCVE — vốn liệt kê CVE và mang theo mô tả từ khuyến cáo, và không cái nào đưa ra đánh giá độc lập về mã. Do đó, cơ chế như được mô tả ở đây chỉ dựa trên một khuyến cáo và trên chính mã nguồn của nhà cung cấp. Thứ ba, không có con số nào về việc có bao nhiêu triển khai MaxKB nằm trong phạm vi bị ảnh hưởng, và cả nhà cung cấp lẫn nhà nghiên cứu đều chưa công bố con số đó.

Nhóm đối tượng có nguy cơ thì hẹp nhưng không dễ đếm: các bản cài đặt MaxKB self-hosted community-edition trên 2.0.0 đến 2.9.2 có nhiều hơn một thành viên không gian làm việc, trong đó quản trị viên đã dùng quyền hạn theo từng công cụ để không cấp một công cụ có chứa thông tin xác thực. Lỗ hổng không phải là thực thi mã từ xa và cần một tài khoản hợp lệ có đặc quyền thấp, đó là lý do tác động lên tính bảo mật là yếu tố quyết định điểm số chứ không phải đường tấn công. Những gì kẻ tấn công đạt được bị giới hạn bởi những gì các công cụ bị từ chối nắm giữ — khóa API, token và bất cứ thứ gì chúng mở khóa — đây cũng là lý do các tác giả của khuyến cáo lập luận rằng tác động lớn hơn mức mà xếp hạng bảo mật thấp ngụ ý.

Những gì một người vận hành có thể làm

Phần khắc phục trong bản khuyến nghị hướng đến những người bảo trì thay vì người vận hành, và ba bước của nó ánh xạ vào đoạn mã đã xuất hiện trong v2.10.5-lts: áp dụng quyền cấp theo từng công cụ trước khi thực thi một công cụ trong phần triển khai tool-library và tool node, xác thực mọi giá trị được liên kết của tool_ids, skill_tool_ids và mcp_tool_ids tại thời điểm liên kết theo cách knowledge_id_list vốn đã được xác thực, và làm cho filter_authorized_ids tham chiếu quyền cấp theo từng công cụ thay vì chỉ dựa vào tư cách thành viên workspace.

Đối với một nhóm đang vận hành bản dựng bị ảnh hưởng, các bước thực tế rút ra từ chính phần mô tả của bản khuyến cáo là những bước sau.

• Hãy coi mọi bí mật được lưu trong init_params của một công cụ trên một triển khai bị ảnh hưởng là có thể bị bất kỳ thành viên không gian làm việc nào truy cập, kể cả vai trò thấp nhất, và hãy xoay vòng các thông tin xác thực đó thay vì cho rằng việc từ chối theo từng công cụ đã bảo vệ chúng.

Kiểm tra tư cách thành viên không gian làm việc. Cơ chế vượt qua cần một tài khoản đã xác thực trong không gian làm việc, vì vậy việc xóa các thành viên không hoạt động hoặc không đáng tin cậy sẽ giảm mức độ phơi nhiễm ngay cả khi không thể vá mã.

• Xem lại những quy trình công việc và tác nhân nào liên kết các công cụ mang thông tin xác thực, vì theo khuyến cáo, chính bước liên kết đó được chấp nhận mà không cần kiểm tra riêng từng công cụ.

• Nếu nâng cấp, hãy lưu ý rằng kiểm tra theo từng người dùng xuất hiện trong kho mã nguồn từ v2.10.5-lts trở đi và không có bản phát hành nào được bản tư vấn chỉ định là bản vá — người vận hành dựa vào việc nâng cấp là dựa vào mã nguồn đã gắn thẻ, chứ không dựa vào tuyên bố vá lỗi của nhà cung cấp.

Không điều nào trong số này khiến lỗ hổng trở nên kịch tính. Nó khiến lỗ hổng trở nên bình thường theo một cách cụ thể và đáng để học hỏi: mô hình phân quyền được thiết kế đúng, được ghi tài liệu đúng và được áp dụng trên những route mà ai đó nhớ ra là phải chặn. Đường dispatch được viết bởi những người nghĩ về việc một workflow nên có thể làm gì, chứ không nghĩ về ai đang yêu cầu — và trên một nền tảng agent, đó chính là đường mà hầu hết các yêu cầu thực sự đi qua.

Bài học từ hồ sơ này mang tính cấu trúc chứ không phải số lượng. Quyền trên từng tài nguyên chỉ vững mạnh ngang mức điểm vào được bảo vệ yếu nhất của nó, và một nền tảng agent tích lũy điểm vào rất nhanh: một tuyến gỡ lỗi, một tuyến xuất, một nút quy trình làm việc, một trình kích hoạt trò chuyện. MaxKB đã có danh sách cấp quyền và bước kiểm tra; điều còn thiếu, đối với dòng 2.0 đến 2.9, là thói quen đặt cùng một câu hỏi ở mọi cánh cửa.