CVE-2026-77521: MaxKB: Prompt-injectable agent can lead to command execution
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 interrupton, so human approval is not required. Untrusted chat or ingested content can therefore cause command execution; source deployments with MAXKBSANDBOX 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. This issue is fixed in version 2.10.5-lts.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
MaxKBto a version that resolves this vulnerability.Fixed in 2.10.5-lts - Compensating control
Ensure MAXKB_SANDBOX is enabled (do not run with MAXKB_SANDBOX disabled) to prevent commands from executing directly as the application user.
Event History
Frequently Asked Questions
Which MaxKB deployments are exposed to this issue?
MaxKB versions before 2.10.5-lts are affected when an assistant has a tool, MCP tool, skill, or sub-application that uses SandboxShellBackend. Source deployments with MAXKB_SANDBOX disabled are especially exposed because commands run directly as the application user.
What does an attacker need to exploit it?
An attacker needs a way to supply untrusted content to the affected assistant, such as through chat input or content that is ingested by MaxKB. No human approval is required before the exposed execute shell tool runs commands.
Are official container deployments affected differently?
Yes. The official root container used a string-based gosu wrapper that allowed shell metacharacters to execute outside the intended sandbox. This creates an additional path for command execution beyond the intended sandbox boundary.
What is the available remediation?
Upgrade MaxKB to version 2.10.5-lts, which fixes the issue. The provided data does not specify a workaround for deployments that cannot be upgraded immediately.