CVE-2026-39418

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.