MaxKB SandboxShellBackend Flaw Enables Unauthenticated Shell Execution

Executive Summary

CVSS Score: 10.0 (Critical)

MaxKB, an open-source AI assistant platform for enterprise deployments from 1Panel-dev, contains a maximum-severity vulnerability tracked as CVE-2026-77521 (GHSA-f36j-f34j-h3rx, "Prompt-injectable agent can lead to command execution"). Any MaxKB assistant configured with a tool, MCP tool, skill, or sub-application routes its conversations through a deepagents-based agent built on SandboxShellBackend. That backend automatically exposes an execute shell tool alongside file-system helpers, and MaxKB neither adds execute to the assistant's excluded_tools list nor includes it in interrupt_on — the human-in-the-loop approval gate that already covers write_file, read_file, and edit_file. The result is that untrusted chat input, or content pulled in through retrieval-augmented generation, can silently trigger operating-system command execution with no authentication and no user interaction required.

Security researchers at Lasso Security reported the issue. On source deployments running with sandboxing disabled, commands execute directly as the application user. On the official containerized distribution, a string-based gosu wrapper used to drop privileges was found to mishandle shell metacharacters, allowing commands to escape the intended sandbox boundary entirely — in the worst case, reaching root on the underlying host.

Vulnerability Overview

Affected Versions

Any assistant that has a tool, MCP tool, skill, or sub-application attached is exposed, since that configuration is what routes the conversation through the vulnerable SandboxShellBackend-equipped agent. Public or embedded assistants that accept anonymous chat input, and multi-tenant deployments where one tenant's content can reach an agent serving others, carry the highest practical risk.

Attack Vector

The vulnerable path runs through MaxKB's agent orchestration layer rather than a single input field, which is what makes it reachable via indirect prompt injection as well as direct chat:

1. An assistant is created/configured with at least one of:
   - a tool
   - an MCP tool
   - a skill
   - a sub-application

2. MaxKB routes the assistant's conversations through a
   deepagents-based agent, instantiated with SandboxShellBackend.

3. SandboxShellBackend auto-registers several capabilities on the
   agent, including an `execute` shell tool. MaxKB does not list
   `execute` in excluded_tools, so it is available to the model
   by default.

4. The human-in-the-loop approval list (interrupt_on) only covers
   file operations: write_file, read_file, edit_file.
   `execute` is omitted, so no approval prompt is ever raised
   before a shell command runs.

5. An attacker supplies untrusted input through any surface the
   agent reads from — a chat message, or content ingested via
   RAG (a document, a scraped page, a ticket, etc.) — containing
   an instruction that induces the model to call the execute tool.

6. The shell command runs immediately:
   - Source deployments with MAXKB_SANDBOX disabled: runs directly
     as the application user on the host.
   - Official container images: an entrypoint gosu wrapper drops
     privileges via a string-built command; shell metacharacters
     in the injected payload can escape that wrapper, potentially
     reaching root inside (or, depending on mounts, outside) the
     intended sandbox.

No authentication, prior access, or direct user action is needed beyond the attacker's ability to place text somewhere the agent will read it — which is precisely the scenario prompt injection is designed for.

Impact of Successful Exploitation

Immediate Remediation

1. Upgrade to MaxKB 2.10.5-lts or later immediately. This is the vendor-confirmed fix and the only complete remediation; given the CVSS 10.0 rating and zero authentication requirement, treat this as an emergency patch, not a scheduled one.
2. If you cannot upgrade immediately:
   • Remove tools, MCP tools, skills, and sub-applications from any assistant that accepts untrusted or public input — this configuration is the precondition that routes conversations through the vulnerable agent path.
   • Ensure sandboxing is enabled (MAXKB_SANDBOX should not be disabled) so commands do not run directly as the host application user.
   • Where possible, run MaxKB containers with the shell-execution surface disabled entirely, and avoid relying on the container's privilege-drop wrapper as a security boundary until patched.
   • Restrict which users/tenants can create or edit assistants with tool/MCP/skill/sub-application attachments.
3. Add execute to the human-in-the-loop approval gate if your deployment exposes any configuration for interrupt_on — do not allow shell execution to bypass approval the way file writes already require it.
4. Audit existing assistants for tool/MCP/skill/sub-application attachments and treat any that accept public or multi-tenant input as high risk until patched.

Detection Indicators

Post-Remediation Steps

1. Confirm the running MaxKB version reports 2.10.5-lts or later after upgrade.
2. Review all assistants for tool/MCP/skill/sub-application attachments and re-validate that each is intentional and scoped to trusted input.
3. Rotate any credentials or secrets that were reachable from the MaxKB host or container filesystem, since the vulnerability allowed arbitrary command execution.
4. Review historical chat and RAG ingestion logs for signs of prompt-injection attempts predating the patch.
5. Re-enable or verify sandboxing (MAXKB_SANDBOX) and confirm the container's privilege-drop mechanism no longer accepts unsanitized input.
6. Add execute/shell actions to any human-in-the-loop approval configuration going forward, rather than relying on tool exposure alone.

References

• NVD — CVE-2026-77521
• GitHub Security Advisory — GHSA-f36j-f34j-h3rx (1Panel-dev/MaxKB)