MaxKB vulnerabilities

MaxKB is an open-source AI assistant for enterprise. Prior to 2.10.5-lts, authenticated workspace members can inject control characters into AWS Bedrock access_key_id and secret_access_key fields that _update_aws_credentials writes to /root/.aws/credentials without safe parsing. An attacker can append a new AWS profile containing credential_process, then select that profile during a later model-validation request so botocore executes an attacker-controlled command as root.

MaxKB is an open-source AI assistant for enterprise. Prior to version 2.10.5-lts, assistants with a tool, MCP tool, skill, or sub-application use SandboxShellBackend, which exposes an execute shell tool without excluding it and omits execute from interrupt_on, so human approval is not required. Untrusted chat or ingested content can therefore cause command execution; source deployments with MAXKB_SANDBOX disabled run commands directly as the application user, while the official root container's string-based gosu wrapper allowed shell metacharacters to execute outside the intended sandbox.

Prior to version 2.10.6-lts, function-library code running under the LD_PRELOAD sandbox can invoke ctypes.CDLL from an importlib.abc.MetaPathFinder callback so the dlopen call-stack heuristic sees a Python import frame, then use unhooked dlsym with RTLD_NEXT to resolve glibc's real syscall and bypass the sandbox syscall blacklist.

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.

MaxKB from version 2.0.0 to 2.10.4-lts in UpdateStoreTool.update_tool passes caller-supplied download_url and download_callback_url to requests.get without trusted-host and redirect validation. An authenticated workspace user can make the server request internal, loopback, link-local, or cloud metadata URLs.

In MaxKB prior to 2.10.0-lts, the tool import functionality and MCP referencing mode do not consistently validate MCP transport type, allowing an authenticated user to import a .tool file with stdio transport containing malicious commands and trigger execution via an AI Chat node, leading to arbitrary system command execution.

An SSRF vulnerability in MaxKB before version 2.10.0 allows authenticated users to make arbitrary server requests via unvalidated downloadCallbackUrl and download_url parameters in tool creation and update endpoints. Attackers with the default USER role can exploit this to access internal network services.

MaxKB stores user passwords using unsalted MD5 hashes, making them easily crackable via rainbow tables or GPU-accelerated brute force.

MaxKB prior to version 2.9.1 is vulnerable to SSRF (Server-Side Request Forgery) via work_flow_template import. Authenticated users can supply arbitrary URLs in work_flow_template.downloadUrl which are fetched server-side without any URL validation or internal IP filtering.

MaxKB before version 2.9.0 exposes the webhook endpoint (/api/trigger/v1/webhook/{trigger_id}) without authentication. The WebhookAuth class returns (None, {}), which is interpreted as successful authentication. An unauthenticated attacker who knows a valid trigger ID can invoke webhook triggers to execute bound tasks.

MaxKB version 2.8.0 and prior are vulnerable to a broken access control vulnerability in the OSS file service URL fetch API (chat/api/oss/get_url). The endpoint uses application_id from the URL path without validating ownership, allowing attackers to perform operations under other applications’ policies.

MaxKB 2.8.0 and prior are vulnerable to a server-side request forgery (SSRF) bypass in the OSS file service URL fetch functionality due to inconsistent DNS resolution between validation and actual request execution, allowing attackers to access internal network services.

MaxKB before version 2.8.1 is vulnerable to a server-side request forgery (SSRF) bypass in the OSS file service URL fetch endpoint. Inconsistent URL parsing between the validation function and the HTTP client allows attackers to access internal network services.

A vulnerability in MaxKB up to 2.4.2, affecting an unknown function in the file ui/src/chat.ts of the MdPreview component, allows cross-site scripting (XSS). The attack can be executed remotely. Upgrading to version 2.5.0 is recommended.

MaxKB is an open-source AI assistant for enterprise. Versions 2.3.1 and below have improper file permissions which allow attackers to overwrite the built-in dynamic linker and other critical files, potentially resulting in privilege escalation. This issue is fixed in version 2.4.0.

MaxKB is an open-source AI assistant for enterprise. In versions 2.3.1 and below, the tool module allows an attacker to escape the sandbox environment and escalate privileges under certain concurrent conditions. This issue is fixed in version 2.4.0.

MaxKB, an enterprise AI assistant, prior to version 2.3.1 allows a user to obtain sensitive information via Python code in the tool module, even though the process runs in a sandbox. Version 2.3.1 fixes the issue.

MaxKB is an open-source AI assistant for enterprise. In versions prior to 2.3.1, a user can access internal network services such as databases through Python code in the tool module, although the process runs in a sandbox. Version 2.3.1 fixes the issue.