CVE-2026-79919

Prior to version 2.10.6-lts, the ToolExecutor LD_PRELOAD sandbox hooks execve, execvpe, and execveat to prevent subprocess creation but does not hook fexecve. An authenticated attacker able to execute tool code can call fexecve to start a process outside the sandbox's intended subprocess policy.

In MaxKB versions 2.7.0 through 2.10.4-lts, the POST /chat/api/{application_id}/chat/{chat_id}/share_chat endpoint verifies only that a conversation exists but does not verify it belongs to the authenticated chat_user_id or the application bound to the caller's token. An attacker with any chat token and a known victim chat_id can create a public ChatShareLink exposing the victim's conversation and PublicFileAccess state making associated files retrievable without credentials, with no revoke path.

In MaxKB 2.10.2-lts and earlier, management chat-record routes authorize the path application_id but load records using global chat_id and chat_record_id values without confirming the chat belongs to the authorized application. A normal user in the same workspace who knows the chat_id of a persisted record for a victim's published application can read victim chat records and copy victim answers via add_knowledge.

MaxKB, an open-source AI assistant for enterprise, in version 2.10.3-lts and earlier, has a vulnerability in the model parameter form route. An authenticated user with model read permission in an attacker-controlled workspace can read or overwrite the victim's model_params_form in another workspace using a known model_id, without including workspace_id in the query.

In MaxKB 2.10.3-lts and earlier, the knowledge web-document import and synchronization crawler passes an authenticated user's URL to Fork.fork, which calls requests.get with verify=False and without restricting schemes, loopback, link-local, private, or reserved addresses. The response body becomes imported document content, allowing a low-privileged user to read cloud metadata or internal HTTP services through the MaxKB server.

In MaxKB 2.10.2-lts and earlier, a normal user in the same workspace can obtain another user's application_id from the homepage application question-ranking endpoint when the victim's published application has ranking activity in the selected date range. An attacker who can create and publish workflow applications can place the disclosed identifier in a workflow node, trigger it, receive victim application output, and create durable application_chat records under the victim application.

In MaxKB 2.10.2-lts and earlier, the /chat/api/mcp authentication path looks up an ApplicationApiKey using only its secret and active status, without enforcing the is_permanent and expire_time checks used by the standard chat API. A previously valid, non-permanent application key that remains active after expiration can initialize the MCP endpoint, list tool metadata, invoke tools/call, and create durable application_chat state.

In MaxKB 2.10.2-lts and earlier, a normal workspace user who knows another user's active MCP tool_id can retrieve the hidden tool through the tool-detail route, which does not apply per-resource authorization used by the list route. The response includes Tool.code, which may contain MCP server configuration and headers, and an attacker who can create or edit a workflow can place the foreign mcp_tool_id in a workflow mcp-node so debug uses the owner's MCP configuration.

In MaxKB from version 2.0.0 through 2.10.2-lts, document and paragraph operate routes authorize only knowledge_id in the request path, then query the target Document by document_id or Paragraph by paragraph_id without confirming the object belongs to that knowledge base. A normal workspace user with a known victim document or paragraph UUID can read or modify content in another user's knowledge base.

In MaxKB from version 2.0.0 through 2.9.2, a lowest-role workspace member denied access to a tool by WorkspaceUserResourcePermission can still bind its identifier through tool_ids, skill_tool_ids, or mcp_tool_ids and execute it through the agent or workflow dispatch path. The dispatch path does not reapply the per-tool grant, and tool execution decrypts server-side init_params, allowing the caller to receive credentials carried by the denied tool.