MaxKBypass - From Prompt Injection To Bypassing MaxKB Agent's Sandbox (CVE-2026-77521)

‍‍

MaxKB is an open-source enterprise "knowledge base plus agent" product from FIT2CLOUD, published under the 1Panel-dev organization. The platform is designed to help organizations deploy RAG (Retrieval-Augmented Generation) and LLM-based assistants, and it is one of the more widely adopted projects in its category: its Docker image has passed a million pulls, and the repository has gathered more than 22k stars since it first appeared in September 2023, with development still active.

‍

It ships primarily as a self-hosted Docker deployment, and the repository bills itself as "an open-source platform for building enterprise-grade agents".

‍

Using the product, a user creates an assistant, attaches capabilities to it (tools, MCP servers, skills, sub-applications), connects a knowledge base, and exposes the assistant either through an authenticated console or as a public, embeddable chat widget.

‍

‍

A knowledge base for the agent can be built from uploaded documents or from external websites which MaxKB crawls. That content is retrieved at answer time and placed in the model's context, and the maxKB URL can also be a public knowledge base that is based on other people’s content. Therefore - the set of people who can put text in front of the model is larger than the set of people who can chat with it, which in most cases is the user itself.

‍

‍

MaxKB Sandbox & Vulnerability 

‍

Command Injection

‍

MaxKB uses a sandbox they specifically built for it, and we found a way to escape it and run arbitrary commands. The sandbox is based on gosu utility and is applied by supplying the commands through env like that:

‍

# apps/application/flow/backend/sandbox_shell.py:70
command = f'env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so ... gosu sandbox {command}'
return super().execute(command=command)   # -> subprocess.run(command, shell=True), uid 0 

‍

The issue resides in sandbox_shell.py, when the gosu sandbox is applied to the last part of the string. In our attack we can send a long payload, with commands separated one after another by the character ;

‍

So eventually the gosu sandbox is applied only on the ‘whoami’ command:

‍

env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so PATH="$PATH" gosu sandbox ls; whoami; id

‍

So any ;, |, $(...), or > in the model-supplied command will run in the outer root shell.

‍

Here’s a clearer example when actually running the same lines and spawning the MaxKB & gosu sandbox:

‍

The ls command is blocked because of the gosu sandbox. However -  the whoami command isn’t blocked since the sandbox isn’t applied on it and you can add more and more commands afterwards, terminated by the character ;

‍

‍

The Attack Flow

‍

By combining the sandbox bypass below, we were able to run arbitrary code from an ordinary user question, simply by placing commands on a webpage and waiting for the victim's agent to crawl it, as following:

‍

‍

First - an attacker poisons the public knowledge base of the victim:

‍

‍

‍

This comment will enforce the agent to run the curl command silently. Afterwards - a victim creates an agent and assigns a knowledge base:

‍

‍

The victim asks a benign question:

‍

‍

And although the question was fired and legitimate answer was returned, we can still see that the execute tool was triggered:

‍

‍

And by observing the execution details, we can see the injected page’s content in red, and the benign victim’s prompt in blue:

‍

‍

The curl command was executed and a request to our (attacker’s) server was fired:

‍

‍

In this example, a simple ‘curl’ command was fired, but it can be substituted by other arbitrary commands as well.

‍

Cross-Tenant Reach

‍

MaxKB is deployed as a multi-tenant. Execution at the application user' privilege level sits underneath the tenancy model, so one tenant's chat can reach another tenant's data, along with application secrets and database credentials.

‍

An attacker who can affect a page that is indexed into the knowledge base can carry the instruction in the ingested content into other tenants as well and run commands in highest privileges.  Once commands run, the attacker can extract secrets on disk, the database, internal services reachable from that network position, and gain persistence.

‍

Impact

‍

By embedding a malicious payload into ingested content, an attacker can trigger command injection, bypass the user agent's sandbox, and execute arbitrary code to gain full control on the MaxKB container.

‍

Fix

• Committed as 594f50f2 on 2026-07-09, one day after our report
• The old code prepended env -i LD_PRELOAD=.../sandbox.so ... gosu sandbox once, to the whole model-supplied string. The new code parses that string before wrapping it.
•   _build_sandbox_command() applies the gosu sandbox prefix to every simple command, not just the first.

‍

Remediation Steps

• Upgrade MaxKB to `2.10.5-lts` or later
• Run only the docker version and make sure the sandbox is enabled

‍

The Wider Pattern

‍

This is not specific to MaxKB. Across the other agent projects we reviewed the same shape kept recurring where isolation is or opt-off unless explicitly enabled.

‍

If you deploy an agent with a shell tool, confirm the sandbox is actually engaged in the deployment mode you run, not just present in the repository. 

‍

On a final note, we are working through the rest of this class with the affected projects and with the framework maintainers, and will write up further cases as those disclosures complete.

‍

Timeline

‍

‍

We would like to thank the MaxKB team for their handling of this disclosure. A fix was committed one day after our private report and released in v2.10.5-lts on 6 August. The exchange ran entirely through their GitHub's private vulnerability reporting, and working with a vendor that maintains an active vulnerability reporting made the coordination straightforward and very efficient.