Summary
A critical command-injection vulnerability in MaxKB allows untrusted chat or ingested content to trigger shell commands through assistants configured with SandboxShellBackend.
Because the shell execution tool is not excluded and does not require human approval, successful exploitation may result in arbitrary command execution as the application or container user.
Affected context
The issue occurs in MaxKB assistants that use a tool, MCP tool, skill, or sub-application backed by SandboxShellBackend. Risk depends on deployment configuration: source deployments with the sandbox disabled may execute commands directly as the application user, while the official root container's string-based wrapper may interpret shell metacharacters outside the intended sandbox boundary.
Exploit preconditions
- Attack surface: Assistant tool execution and sandbox shell integration
- Required access: Ability to submit or cause processing of chat or ingested content that reaches an affected assistant
- Trigger point: Automatic invocation of the exposed shell execution tool
- Approval requirement: Human approval is not enforced for shell execution because the operation is omitted from the interrupt policy
- Why exploitation is possible: Untrusted content can influence shell commands, and deployment-specific sandbox or wrapper behavior may execute them with excessive privileges
Why this happens
The vulnerability results from exposing a shell execution capability without applying an approval requirement or sufficiently restricting command construction. The execution operation is omitted from the interrupt_on policy, allowing assistant-controlled or content-influenced actions to proceed automatically.
This maps primarily to CWE-78: Improper Neutralization of Special Elements used in an OS Command, with related concerns involving excessive privileges (CWE-250) and an exposed dangerous functionality (CWE-749).
Potential impact
- An attacker may execute arbitrary operating-system commands
- The application or container runtime may be compromised
- Sensitive files, credentials, or environment variables could be accessed
- Commands could run with the privileges of the application or root container
- The attacker could modify data, disrupt services, or establish persistence
- The vulnerability could enable lateral movement into connected systems
General mitigation guidance
Mitigation typically focuses on removing unrestricted shell execution from assistant workflows and enforcing strong trust boundaries around tool invocation.
Common defensive patterns include:
- Replacing general-purpose shell access with narrowly scoped, allowlisted operations
- Requiring explicit human approval for every command-capable action
- Treating chat, retrieved documents, and ingested content as untrusted input
- Avoiding shell-string construction and using structured process APIs with fixed arguments
- Neutralizing or rejecting shell metacharacters where shell interpretation cannot be eliminated
- Running sandboxed workloads as a dedicated non-privileged user rather than root
- Applying container, filesystem, network, and credential restrictions
- Disabling shell tools for assistants that do not require them
How teams detect issues like this
Detection can combine source review, runtime monitoring, and policy enforcement:
- Use static analysis to identify shell invocation, string-based command wrappers, metacharacter-sensitive execution, and dynamic tool registration.
- Review assistant tool definitions to confirm that command-capable operations require approval and cannot be reached from untrusted content without explicit authorization.
- Search deployment configuration for disabled sandbox controls, root execution, writable sensitive paths, and excessive container capabilities.
- Monitor process creation from MaxKB services, including unexpected interpreters, outbound connections, file modifications, and privilege changes.
- Enforce CI policies that block unrestricted shell tools and require allowlisted command interfaces.
- Automated code and configuration review tools may help identify dangerous execution paths before deployment.
