MaxKB CVE-2026-77521

Requires an assistant configured with at least one tool, MCP tool, skill, or sub-application, which activates the SandboxShellBackend and thereby exposes the un-gated execute shell tool (the human-approval interrupt_on list omits execute). The attacker's vector is untrusted content the assistant processes - chat input or ingested/RAG documents - so no attacker authentication is asserted (PR:N). Impact is amplified in two deployment modes: source installs with MAXKB_SANDBOX disabled execute commands directly as the application user with no sandbox, and the official root container's string-based gosu wrapper allowed shell metacharacters to break out of the intended sandbox. LIMITING factors: an eligible tool/skill must actually be configured on the assistant; exploitation depends on reliably coercing the LLM to emit the attacker's command (prompt-injection non-determinism); and full sandbox-escape severity depends on the specific deployment (MAXKB_SANDBOX disabled or the vulnerable root-container gosu wrapper).

This is a genuine top-priority issue, not a high-CVSS-but-low-risk one. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0) reflects a full remote code-execution primitive with scope change, and the CWE-78 command-injection root cause is corroborated by the vendor security advisory (GHSA-f36j-f34j-h3rx) and the fixing commit 594f50f2. The core weakness is a design/authorization gap: the SandboxShellBackend exposes an execute shell tool that is neither excluded nor placed in interrupt_on, so the normal human-approval gate never fires, and untrusted chat or RAG-ingested content can drive the LLM into running commands. Two deployment-specific amplifiers raise real-world severity: source deployments with MAXKB_SANDBOX disabled run commands directly as the application user, and the official root container's string-based gosu wrapper let shell metacharacters execute outside the intended sandbox. Signals that TEMPER urgency: no EPSS score, no CISA KEV listing, and no public exploit are present in the input, so there is no evidence of active exploitation. Also note the PR:N rating is defensible only because the trigger is untrusted CONTENT (prompt injection / poisoned ingestion) rather than an authenticated request - but successfully coercing an LLM to emit a precise attacker command is probabilistic, so raw AC:L arguably understates practical difficulty. Net: patch-now class defect, but exploitation reliability and the configuration prerequisite mean it is less turnkey than the 10.0 alone implies.

An attacker plants malicious instructions in content the MaxKB assistant will process - a chat message, an uploaded document, or a web/RAG source that gets ingested. Because the assistant is configured with a tool, MCP tool, skill, or sub-application, the SandboxShellBackend's execute shell tool is available without any human-approval interrupt, so the injected instructions cause the assistant to run attacker-chosen shell commands as the application user (or, via the root container's gosu metacharacter flaw, outside the sandbox). No public exploit is identified in the input, but the fixing commit's shell-parsing hardening confirms the injection path is concrete.