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.

MaxKB versions 2.7.1 and below contain a Stored XSS vulnerability where the frontend's MdRenderer.vue component parses custom <iframe_render> tags from LLM responses or Application Prologue configurations, bypassing Markdown sanitization and XSS filtering. The unsanitized HTML is passed to IframeRender.vue and rendered into an iframe via srcdoc with sandbox="allow-scripts allow-same-origin", allowing injected scripts to escape the iframe and execute JavaScript in the parent window.

MaxKB versions 2.7.1 and below contain a Stored Cross-Site Scripting (XSS) vulnerability that allows authenticated users to inject arbitrary HTML and JavaScript into the Application prologue (Opening Remarks) field by wrapping malicious payloads in <html_rander> tags. The backend fails to sanitize or encode HTML entities in the prologue field, and the frontend renders this content using an innerHTML-equivalent mechanism, enabling persistent DOM-based Stored XSS against any visitor who opens the affected chatbot interface. The issue has been fixed in version 2.8.0.

MaxKB is an open-source AI assistant for enterprise. In versions 2.7.1 and below, an authenticated user can bypass sandbox result validation and spoof tool execution results by exploiting Python frame introspection to read the wrapper's UUID from its bytecode constants, then writing a forged result directly to file descriptor 1 (bypassing stdout redirection). By calling sys.exit(0), the attacker terminates the wrapper before it prints the legitimate output, causing the MaxKB service to parse and trust the spoofed response as the genuine tool result.

MaxKB versions 2.7.1 and below are vulnerable to Improper Neutralization of Formula Elements in a CSV File. When an administrator exports chat history to an Excel file (.xlsx), strings starting with formula characters are written without proper sanitization, which can lead to Arbitrary Code Execution (RCE) on the administrator's workstation via Dynamic Data Exchange (DDE) when opened in spreadsheet applications like Microsoft Excel.

MaxKB versions 2.7.1 and below contain an Eval Injection vulnerability in the Markdown rendering engine that lets any user of the AI chat interface execute arbitrary JavaScript in other users' browsers, including administrators, resulting in Stored XSS. The issue is fixed in version 2.8.0.

MaxKB versions 2.7.1 and below contain a stored XSS vulnerability through the application name or icon fields when creating an application. When a victim visits the public chat interface (/ui/chat/{access_token}), ChatHeadersMiddleware retrieves application data and directly inserts the unescaped application name and icon into the HTML response via string replacement. This allows an attacker to execute arbitrary JavaScript in the victim's browser context.

MaxKB is an open-source AI assistant for enterprise. Versions 2.7.1 and below contain a sandbox escape vulnerability in the ToolExecutor component. By leveraging Python's ctypes library to execute raw system calls, an authenticated attacker with workspace privileges can bypass the LD_PRELOAD-based sandbox.so module to achieve arbitrary code execution, enabling full network exfiltration and container compromise. This issue has been fixed in version 2.8.0.

MaxKB versions 2.7.1 and below have an incomplete LD_PRELOAD-based sandbox that an authenticated user with tool execution privileges can escape. Using the env command, an attacker can clear environment variables and drop the sandbox.so hook, leading to unrestricted Remote Code Execution (RCE) and network access. This issue has been fixed in version 2.8.0.

MaxKB versions 2.7.1 and below allow bypassing sandbox network protection using socket.sendto() with the MSG_FASTOPEN flag. An authenticated user with tool-editing permissions can reach internal services blocked by the banned hosts configuration.

MaxKB versions 2.7.1 and below contain an incomplete fix for CVE-2025-53928, leaving a Remote Code Execution vulnerability in the MCP node of the workflow engine. The fix only restricts the referencing code path, while the else branch loading mcp_servers directly from user-supplied JSON remains unpatched, allowing bypass and remote code execution.

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.

A vulnerability was found in 1Panel-dev MaxKB up to 2.6.1 in the execute function of apps/application/flow/step_node/mcp_node/impl/base_mcp_node.py within the Model Context Protocol Node component. Manipulation results in OS command injection, and the attack can be carried out remotely. The exploit has been made public and could be used; the vendor responded professionally and quickly released a fixed version.

1Panel-dev MaxKB up to 2.6.1 contains a Cross-Site Scripting (XSS) vulnerability in the ChatHeadersMiddleware component (apps/common/middleware/chat_headers_middleware.py). Manipulating the Name argument enables remote attack. A fix was released in version 2.8.0 (commit 026a2d623e2aa5efa67c4834651e79d5d7cab1da).

A vulnerability was detected in 1Panel-dev MaxKB up to 2.2.1. It affects the StaticHeadersMiddleware function in apps/common/middleware/static_headers_middleware.py within the Public Chat Interface component. Manipulation of the Name argument results in cross site scripting, and the attack may be launched remotely.

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.