MaxKB đã gắn một công cụ shell vào mọi trợ lý được bật công cụ và không hề giới hạn quyền truy cập của nó.

MaxKB, một nền tảng trợ lý doanh nghiệp mã nguồn mở được công bố dưới tổ chức GitHub 1Panel-dev, đã xây dựng các tác nhân trò chuyện của mình trên một framework tự động thêm công cụ shell bất cứ khi nào một backend có khả năng shell được truyền vào — và MaxKB chưa bao giờ gỡ bỏ công cụ đó hay yêu cầu bất kỳ ai phê duyệt việc sử dụng nó. Lỗ hổng là CVE-2026-77521, được công bố dưới dạng tư vấn GitHub GHSA-f36j-f34j-h3rx vào ngày 2 tháng 9 năm 2026 và được chấm 10,0 trên 10 theo CVSS 3.1 đối với trường hợp trợ lý công khai hoặc được nhúng. Lasso Security, đơn vị đã phát hiện và báo cáo lỗ hổng này, đã chứng minh rằng một tin nhắn trò chuyện — hoặc văn bản mà trợ lý chỉ đơn thuần tiếp nhận thông qua truy xuất hoặc một tài liệu được tải lên — có thể dẫn dắt mô hình thực thi lệnh: trên một triển khai bare-metal trực tiếp trên máy chủ, và trên container chính thức thông qua một lớp bao mà các nhà nghiên cứu nói rằng có thể bị vượt qua bằng dấu chấm phẩy. Không có nguồn nào được trích dẫn ghi nhận lỗ hổng này bị khai thác trong thực tế. Mức độ nghiêm trọng, đánh giá độ tin cậy và danh sách nguồn của chính hồ sơ nằm trong kho lưu trữ sự cố AI, cùng với các mục MaxKB và công cụ tác nhân lân cận từ cùng đợt công bố.

MaxKB là một sản phẩm tự lưu trữ dùng để xây dựng các trợ lý tăng cường truy xuất: người vận hành tạo một trợ lý, gắn các khả năng vào đó — công cụ, máy chủ Model Context Protocol, kỹ năng, ứng dụng con — kết nối một cơ sở tri thức được xây dựng từ tài liệu tải lên hoặc website được thu thập, rồi đưa trợ lý ra ngoài hoặc thông qua một bảng điều khiển có xác thực, hoặc dưới dạng một widget trò chuyện công khai có thể nhúng. Chính sự linh hoạt đó là bề mặt phơi nhiễm. Điều kiện kích hoạt của bản khuyến cáo không phải là một cấu hình bất thường mà là cấu hình thông thường: bất kỳ trợ lý nào có gắn ít nhất một khả năng đều định tuyến cuộc trò chuyện của nó qua đường dẫn agent bị ảnh hưởng, trong khi cuộc trò chuyện không gắn khả năng nào thì không. Bài viết của Lasso mô tả dự án là một trong những dự án được áp dụng rộng rãi hơn trong danh mục của nó, và lưu ý rằng MaxKB thường được triển khai như một dịch vụ đa thuê bao — điều này đặt một lệnh chạy dưới quyền người dùng ứng dụng bên dưới mô hình thuê bao chứ không phải bên trong phần của một thuê bao.

Công cụ shell đi kèm với framework, chứ không phải sản phẩm.

MaxKB xây dựng các agent này bằng thư viện deepagents của LangChain, được ghim ở phiên bản 0.6.11 trong pyproject.toml của dự án tại cả tag dễ bị tổn thương và tag hiện tại. Trong apps/application/flow/tools.py, tại dòng 467 của tag v2.10.3-lts, dự án gọi create_deep_agent với backend được đặt thành SandboxShellBackend, một lớp con của MaxKB chạy các lệnh trên máy chủ. Theo khuyến cáo, deepagents tự động chèn một bộ công cụ bất cứ khi nào một backend shell được truyền theo cách đó: execute, ls, read_file, write_file, edit_file, glob và grep. Chúng không thuộc đối số tools=list, vốn chỉ chứa các công cụ của chính người vận hành, công cụ MCP và công cụ kỹ năng. Không thể loại bỏ chúng khỏi giao diện hoặc thông qua cấu hình.

MaxKB cũng không truyền excluded_tools, đối số thư viện mà lẽ ra sẽ loại bỏ chúng. Bản khuyến cáo cẩn trọng giải thích vì sao điều đó quan trọng ngay cả khi đây là một biện pháp khắc phục: excluded_tools "loại bỏ công cụ khỏi những gì mô hình được cho biết, chứ không loại bỏ khỏi bộ thực thi". Sự khác biệt giữa một công cụ mà mô hình không hề hay biết và một công cụ không thể chạy chính là toàn bộ lỗi này thu nhỏ lại.

Một cổng liệt kê ba công cụ và bỏ qua công cụ thứ tư

Cơ chế kiểm soát human-in-the-loop trong cùng lời gọi đó chỉ là một dòng, và nó liệt kê ba thao tác: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. Việc ghi tệp, đọc tệp và chỉnh sửa tệp đều được nêu tên. Thực thi lệnh hoàn toàn không phải là một khóa trong từ điển. Theo cách diễn giải của bản khuyến cáo, điều đó có nghĩa là không yêu cầu phê duyệt đối với execute — ba thao tác hệ thống tệp được nêu tên và được đặt rõ ràng để không ngắt, còn công cụ shell hoàn toàn không được nêu tên.

Ghép lại, đường đi là: văn bản không đáng tin cậy đến được mô hình, mô hình gọi execute, và lệnh được chạy. Bản khuyến cáo nêu ra hai cách để văn bản không đáng tin cậy đi đến. Cách trực tiếp là trò chuyện — một widget công khai hoặc được nhúng, hoặc cuộc trò chuyện của một tenant khác. Cách gián tiếp là nội dung mà trợ lý tiếp nhận: một tài liệu RAG, một tệp được tải lên, hoặc một trang web mà nền tảng thu thập vào cơ sở tri thức. Bài đăng của Lasso làm cho tuyến thứ hai trở nên cụ thể, khi nhận xét rằng "tập hợp những người có thể đặt văn bản trước mô hình lớn hơn tập hợp những người có thể trò chuyện với nó".

Trên bản cài đặt bare-metal, lệnh chỉ là một lệnh.

Mọi việc MaxKB làm về cách ly đều diễn ra trong apps/application/flow/backend/sandbox_shell.py, và trong v2.10.3-lts, nó bắt đầu bằng một giá trị mặc định. Dòng 9 ghi _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))), và SANDBOX không xuất hiện trong Config.defaults trong apps/maxkb/conf.py. Khi không có thiết lập MAXKB_SANDBOX tường minh, giá trị là 0, nhánh wrapper tại dòng 65 bị bỏ qua, và execute đi tới subprocess.run với shell=True trực tiếp trên host, với tư cách là người dùng đang chạy dịch vụ — root, theo cách diễn đạt trong bản khuyến nghị, nếu dịch vụ chạy dưới quyền root.

Đó là cấu hình mà các nhà nghiên cứu đã dùng cho bản chứng minh khái niệm trên máy chủ của họ. Họ chạy mã thật của MaxKB từ mã nguồn với MAXKB_SANDBOX không được đặt, tạo một trợ lý có gắn một công cụ, rồi yêu cầu nó trong một tin nhắn chat duy nhất chạy các lệnh thông tin hệ thống. Công cụ execute đã kích hoạt và ghi một tệp có nội dung là đầu ra uname, id và sw_vers của chính máy chủ — đầu ra mà theo khuyến cáo được xác nhận là không hề có bên trong bất kỳ container nào. Lasso cũng ghi lại giới hạn của thứ đã ngăn chặn nó: một tệp bằng chứng có tên lộ liễu đã bị mô hình từ chối, trong khi cách diễn đạt vận hành lành tính thì không. Theo lời họ, căn chỉnh mô hình là "một rào cản tạm thời một phần, không phải một biện pháp kiểm soát".

Trên image chính thức, sandbox đã chạy được mà vẫn bị rò rỉ

Container chính thức đặt MAXKB_SANDBOX=1 trong image cơ sở, tại installer/Dockerfile-base dòng 48, nên wrapper đang hoạt động ở đó — và wrapper chính là lỗ hổng thứ hai. Nó dựng một chuỗi: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so theo sau là gosu sandbox và sau đó là lệnh do model cung cấp, rồi giao cho một shell đang chạy với quyền root. Vì lệnh được nội suy dưới dạng văn bản, chỉ token đầu tiên của nó nằm dưới gosu. Mọi dấu chấm phẩy, pipe, chuyển hướng hoặc thay thế lệnh trong đầu ra của model đều được shell root bên ngoài đánh giá trước khi sandbox kịp nhìn thấy nó.

Bài viết của Lasso mô tả cách nó hoạt động: một payload gồm env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id, trong đó ls bị giới hạn, whoami thì không, và mọi thứ sau đó chạy tự do. Trong quá trình kiểm thử, các nhà nghiên cứu đã ghi một tệp thuộc sở hữu root bằng một chuyển hướng trong khi lệnh bên trong được sandbox chặn. Làm trầm trọng thêm, cả installer/Dockerfile lẫn installer/Dockerfile-base đều không chứa chỉ thị USER, nên image ứng dụng chạy với UID 0 — báo cáo tư vấn xác nhận quyền root tại thời điểm chạy. Do đó container vẫn thực thi các lệnh bất kể, và sandbox chỉ quyết định những lệnh nào được quy cho người dùng đặc quyền thấp một cách hình thức.

Toàn bộ luồng tấn công mà Lasso mô tả không cần bất kỳ quyền truy cập nào vào mục tiêu. Kẻ tấn công đặt các lệnh trên một trang web, chờ tác nhân của nạn nhân thu thập trang đó vào cơ sở tri thức, rồi nạn nhân đặt một câu hỏi thông thường. Câu trả lời trả về vẫn đúng và hợp lệ; lệnh curl được chèn vào đã kích hoạt tới máy chủ của kẻ tấn công. Bản khuyến nghị lưu ý rằng các nhà nghiên cứu chỉ kiểm thử các triển khai của chính họ, không phải bất kỳ phiên bản MaxKB bên thứ ba hay được lưu trữ nào.

Những gì các nguồn xác lập, và những gì đơn giản là không được đo lường

Cơ chế, hai chế độ triển khai, phần ghi công và bản phát hành đã khắc phục đều khớp nhau trên bốn tài liệu: thông báo tư vấn của GitHub, bản ghi NVD được công bố ngày 21 tháng 9 năm 2026, bài viết kỹ thuật của chính Lasso ngày 10 tháng 9 năm 2026, và báo cáo của GBHackers ngày 22 tháng 9 năm 2026, đây là nguồn đưa tin độc lập duy nhất được tìm thấy về CVE này. Không nguồn nào phản bác bất kỳ phần nào của phát hiện, và kho lưu trữ ghi nhận mục này là không có tranh chấp ở mức độ tin cậy cao nhất.

Điều mà các nguồn không chứa là bất kỳ thước đo nào về mức độ phơi nhiễm. Không có số lượng triển khai MaxKB, không có số lượng trợ lý hướng Internet hoặc được nhúng, không có kết quả quét, không có telemetry và không có nạn nhân nào được nêu tên. Không có gì trong hồ sơ cho thấy lỗ hổng bị sử dụng để tấn công bất kỳ ai, và đánh giá khai thác của chính CISA cũng đồng tình: khối SSVC gắn với bản ghi NVD ngày 22 tháng 9 năm 2026 đánh giá khả năng khai thác là "poc", khả năng tự động hóa là "yes" và tác động kỹ thuật là "total". Mô hình EPSS của FIRST đặt xác suất bị khai thác trong 30 ngày tới ở mức 1,05 phần trăm, phân vị thứ 64, vào ngày 27 tháng 10 năm 2026, và CVE không xuất hiện trong danh mục Known Exploited Vulnerabilities của CISA đề ngày 27 tháng 10 năm 2026. Xếp hạng của chính kho lưu trữ phản ánh cùng bằng chứng đó: mức độ nghiêm trọng cao, tác hại thực tế: false.

Điểm 10.0 xứng đáng được nêu rõ phạm vi của nó, vì đây là con số dễ bị trích dẫn sai ngữ cảnh nhất. Đây là điểm dành cho trường hợp trợ lý công khai hoặc được nhúng, trong đó vectơ CVSS ghi AV:N/AC:L/PR:N/UI:N/S:C — truy cập được qua mạng, không cần quyền, không cần tương tác của người dùng, với thay đổi phạm vi vì một lệnh bên trong trợ lý vượt sang hệ điều hành máy chủ. Điểm này là của CNA, và CNA ở đây là chương trình tư vấn của GitHub, cũng là nơi mã định danh nguồn của bản ghi CVE trỏ tới. NVD mang cùng vectơ này như một chỉ số thứ cấp và, tính đến ngày 28 tháng 10 năm 2026, liệt kê mục này ở trạng thái “Deferred”, nghĩa là NVD đã công bố phân tích của đơn vị gán điểm thay vì phân tích của chính mình.

Bản vá đã được phát hành trước bản khuyến cáo một tháng.

Dòng thời gian chạy ngược so với thời điểm công bố, và đây là phần khó trực giác nhất của hồ sơ. Lasso đã báo cáo lỗ hổng một cách riêng tư qua kênh cố vấn bảo mật của GitHub vào ngày 8 tháng 7 năm 2026. MaxKB trả lời vào ngày hôm sau, giới hạn phạm vi báo cáo vào image chính thức và yêu cầu một bản chứng minh khái niệm chạy trong container; các nhà nghiên cứu đã cung cấp bản đó cùng với cách vượt qua sandbox vào ngày 10 tháng 7. Một commit sửa lỗi, 594f50f2, đã được đưa vào ngày 9 tháng 7 — một ngày sau báo cáo — và viết lại sandbox_shell.py để chuỗi lệnh của mô hình được phân tích cú pháp trước, đồng thời tiền tố gosu được áp dụng cho mọi lệnh đơn thay vì chỉ lệnh đầu tiên, với mỗi danh sách đối số được trích dẫn lại để phép thay thế không thể thoát vào shell cha. Bài viết của Lasso mô tả thay đổi này là áp dụng tiền tố gosu “cho mọi lệnh đơn, không chỉ lệnh đầu tiên”.

Bản phát hành chứa bản vá này, v2.10.5-lts, được công bố vào ngày 6 tháng 8 năm 2026. Khuyến cáo của GitHub được đăng vào ngày 2 tháng 9, NVD công bố CVE vào ngày 21 tháng 9, khối SSVC của CISA được bổ sung và GBHackers đưa tin vào ngày 22 tháng 9, còn bài viết của chính Lasso xuất hiện vào ngày 10 tháng 9 — ở giữa chuỗi đó, không phải ở đầu. Một người vận hành theo dõi thẻ phát hành thay vì các nguồn cấp khuyến cáo đã có bản vá khoảng bốn tuần trước khi có cảnh báo.

Ranh giới phiên bản đáng được chú ý nhiều hơn mức bản khuyến cáo dành cho nó, vì hai nguồn chính không đồng nhất và kho lưu trữ giải quyết câu hỏi này. Trường biểu mẫu của bản khuyến cáo ghi các phiên bản bị ảnh hưởng là "<= 2.10.3-lts", kèm ghi chú rằng điều này đã được xác minh trên 2.10.3-lts và rằng đường dẫn dễ bị tổn thương "có khả năng" ảnh hưởng đến mọi phiên bản xây dựng agent theo cách này. Bài viết của chính Lasso nêu phạm vi bị ảnh hưởng là "<= 2.10.4-lts". Các thẻ xác nhận phạm vi rộng hơn: v2.10.4-lts, phát hành ngày 16 tháng 7 năm 2026, mang cùng tệp sandbox_shell.py 75 dòng như v2.10.3-lts, và tệp 311 dòng được viết lại xuất hiện lần đầu trong v2.10.5-lts. Một người vận hành trên 2.10.4-lts chỉ đọc phạm vi trong bản khuyến cáo sẽ kết luận rằng mình nằm ngoài phạm vi đó. Nhưng không phải vậy.

Những gì bản sửa lỗi không làm

Điều mà 2.10.5-lts sửa là wrapper: nó không còn dựng một chuỗi shell dưới quyền root. Điều mà nó không làm là bất cứ điều gì đối với công cụ. Đọc trực tiếp kho lưu trữ tại thẻ v2.10.8-lts, được xuất bản ngày 22 tháng 10 năm 2026, cho thấy agent vẫn được khởi tạo với backend=SandboxShellBackend và interrupt_on vẫn mang đúng ba khóa — write_file, read_file và edit_file — không có execute. Hai đề xuất khắc phục đầu tiên của bản khuyến cáo, là xây dựng trên một backend không thực thi theo mặc định và thêm "execute": True vào ánh xạ phê duyệt, không có trong bản phát hành đó.

Khuyến nghị fail-closed xuất hiện muộn hơn, trong v2.10.7-lts, và nó có ý nghĩa đối với chế độ triển khai vốn ở tình trạng tệ nhất. Được công bố vào ngày 15 tháng 10 năm 2026, bản này thay đổi dòng trong sandbox_shell.py từ CONFIG.get("SANDBOX", 0) thành CONFIG.get("SANDBOX", 1). Một bản cài đặt từ mã nguồn hoặc bare-metal chưa từng đặt biến này giờ đây có trình bao bọc được bật theo mặc định thay vì tắt, đây chính là khuyến nghị “fail closed on non-container deploys” theo nghĩa hẹp. Bản khuyến cáo yêu cầu nhiều hơn thế dưới cùng một tiêu đề — rằng luồng có khả năng thực thi phải từ chối khởi động khi runtime sandbox không khả dụng — và yêu cầu riêng rằng trình bao bọc không bao giờ được dựng chuỗi lệnh cho một shell root. Về phía container, đây là một sự thật chứ không phải khuyến nghị: cả installer/Dockerfile lẫn installer/Dockerfile-base đều không mang chỉ thị USER tại thẻ v2.10.8-lts, nên image ứng dụng vẫn khởi động với quyền root.

Xét cùng nhau, tình trạng hồ sơ tính đến ngày 28 tháng 10 năm 2026 là như sau. Nửa sau của lỗ hổng — hộp cát mà một dấu chấm phẩy đã thoát ra — đã được đóng lại, và mặc định fail-open trên các triển khai máy chủ cũng đã được đóng lại. Nửa đầu, một công cụ execute đi kèm với một đối tượng backend và không phải là khóa trong bản đồ phê duyệt, vẫn là cách MaxKB xây dựng một trợ lý có bật công cụ. Lời khuyên khắc phục của chính các nhà nghiên cứu là phương án hẹp: nâng cấp lên 2.10.5-lts trở lên và chạy phiên bản Docker với sandbox được bật. GBHackers đã chuyển tiếp cùng chỉ dẫn đó cùng với một danh sách rộng hơn dành cho quản trị viên — vô hiệu hóa các backend agent có khả năng shell trừ khi thực sự cần thực thi mã, yêu cầu phê duyệt của con người trước mọi hành động execute, chạy container dưới quyền không phải root, và coi các trang đã thu thập, tài liệu RAG và tệp tải lên là đầu vào không đáng tin cậy.

Bản ghi MaxKB còn lại từ cùng lô tháng Chín

Mục MaxKB thứ hai của kho lưu trữ trong lô này là một lỗi khác với kết cục tồi tệ hơn. CVE-2026-77516, cũng được công bố trên NVD vào ngày 21 tháng 9 năm 2026, là lỗi bỏ qua quyền chứ không phải chèn lệnh: từ phiên bản 2.0.0 đến 2.9.2, một thành viên workspace ở vai trò thấp nhất, đã bị từ chối rõ ràng quyền truy cập vào một công cụ thông qua WorkspaceUserResourcePermission, vẫn có thể liên kết mã định danh của công cụ đó thông qua tool_ids, skill_tool_ids hoặc mcp_tool_ids và thực thi nó thông qua đường điều phối của agent hoặc workflow. Đường điều phối không áp dụng lại quyền cấp theo từng công cụ mà các tuyến công cụ chuyên dụng thực thi, và việc thực thi công cụ giải mã init_params phía máy chủ, nên bên gọi nhận được thông tin xác thực do công cụ mà họ bị từ chối mang theo. Điểm của nó là 5.4, và mô tả của NVD kết thúc bằng một câu mà CVE-2026-77521 không phải mang theo: "Không có phiên bản đã sửa nào tại thời điểm đánh giá này."

Sự tương phản là phần hữu ích cho bất kỳ ai đang phân loại cặp lỗ hổng này. Lỗ hổng đạt điểm 10.0 đã có bản sửa được commit trong vòng một ngày và được phát hành một tháng trước khi nó được công bố. Lỗ hổng đạt điểm 5.4 không có phiên bản đã sửa nào được công bố tại thời điểm CVE của nó.

Điều còn thực sự bỏ ngỏ thì nhỏ hơn mức điểm số gợi ý và lớn hơn mức một ghi chú vá lỗi ngụ ý. Phát hiện này không có gì tranh cãi và cơ chế đã được nhóm phát hiện xác minh từ đầu đến cuối trên cả hai chế độ triển khai. Mức độ phơi nhiễm hoàn toàn chưa được đo lường — chưa ai công bố có bao nhiêu trợ lý MaxKB mang một công cụ, bao nhiêu trong số đó có thể bị một bên không đáng tin cậy tiếp cận, hoặc bao nhiêu chạy trên máy chủ không có sandbox — nên hậu quả thực tế của lỗ hổng phụ thuộc vào thói quen triển khai mà không nguồn được trích dẫn nào thống kê. Và phần thiết kế đã đẩy điểm số lên mức tối đa vẫn còn đó trong bản phát hành hiện tại: một khả năng chạy lệnh, được gắn theo mặc định, vắng mặt khỏi bản đồ vốn yêu cầu con người xác nhận trước.