CVE-2026-77521: MaxKB Command Execution

What Happened, in Brief

CVE-2026-77521 is a critical MaxKB command execution vulnerability affecting the open-source platform from 1Panel-dev. MaxKB is used to build enterprise AI assistants and agents. The vulnerability involves assistants configured with a tool, MCP tool, skill, or sub-application that uses SandboxShellBackend. In affected releases, the shell execute operation remained available and was not included in the approval-interruption configuration.

That combination can allow untrusted natural-language input or ingested knowledge-base content to cause operating-system command execution. The impact depends on deployment mode. Source deployments with MAXKB_SANDBOX disabled may execute commands directly as the MaxKB application user. The official root container also used a string-based gosu wrapper in which shell metacharacters could escape the intended sandbox boundary.

The CVSS score is severe, but defenders should not infer missing vector components from the 10.0 score. The NVD record retrieved for this assessment did not include the vector string, so the precise network, complexity, privileges, user-interaction, scope, and impact components require confirmation against the live record.

What’s the Root Cause?

The root cause is inadequate control over a high-impact shell-execution capability. MaxKB exposed the execute operation for affected assistant configurations, but the operation was omitted from interrupt_on. Execution that should have required human approval could therefore proceed automatically.

The issue is also deployment-sensitive. When MAXKB_SANDBOX is disabled in a source installation, commands can run as the MaxKB application user rather than inside a meaningful isolation boundary. In the official root-container deployment, the string-based gosu wrapper could interpret shell metacharacters in a way that allowed commands to break out of the intended sandbox behavior.

Analyst’s Take: Treat this first as a command-execution exposure, not as a prompt-filtering problem. The affected path includes chat, knowledge-base content, MCP responses, and assistant components, while detection should focus on process lineage and container activity rather than one exploit string.

This matters for AI assistant deployments because the input path is broader than a conventional web form. User prompts, documents imported into a knowledge base, retrieved content, MCP responses, and skill or sub-application output may all influence tool invocation. Treat those sources as untrusted until the affected deployment is patched and reviewed.

Technical Notes

The vulnerable execution path can be summarized as:

Untrusted chat or ingested content
        |
        v
MaxKB assistant using SandboxShellBackend
        |
        v
execute operation available and not interrupted for approval
        |
        v
Operating-system command execution

The exact command syntax and exploit payload are not established by the supplied research. Defenders should not rely on blocking one prompt pattern. Detection should focus on the resulting process activity, command lineage, container escapes, and unexpected outbound connections.

Who Needs to Act?

All MaxKB installations running a version prior to 2.10.5-lts should be treated as affected and upgraded. The available NVD information does not provide a more granular version range. The relevant affected functionality includes assistants configured with SandboxShellBackend, tools, MCP tools, skills, and sub-applications.

Risk is highest where assistants can invoke shell-capable functionality and where the deployment has disabled MAXKB_SANDBOX. Root-container deployments require additional scrutiny because commands escaping the intended gosu wrapper may execute with elevated container privileges. A deployment without an exposed shell-capable assistant may have a lower practical attack surface, but version status still determines whether the vulnerable code is present.

Why This CVSS Score?

The reported CVSS base score is 10.0, which is the maximum critical score. That rating is consistent with a vulnerability that can convert untrusted assistant-controlled input into operating-system command execution, potentially affecting confidentiality, integrity, and availability. The consequences may include data access, modification or deletion, credential theft, persistence, and follow-on attacks against reachable services.

However, the exact CVSS vector was not present in the retrieved NVD record. The precise values for attack vector, attack complexity, privileges required, user interaction, scope, and the confidentiality, integrity, and availability impact components cannot therefore be responsibly stated here. The quick-reference table records those fields as unknown rather than inventing a vector.

The practical severity can also vary by deployment. A narrowly scoped, unprivileged process inside a well-configured container has a different blast radius from a root container with mounted host paths, cloud credentials, or access to internal services. Those environmental differences do not reduce the need to patch; they determine incident priority, containment requirements, and the extent of post-upgrade investigation.

Has It Been Exploited?

There is no confirmed in-the-wild exploitation reported in the supplied research. CVE-2026-77521 is not currently listed in the CISA Known Exploited Vulnerabilities catalog, so there is no CISA date added, remediation deadline, required action, or ransomware-use flag for this CVE.

No confirmed public proof-of-concept repository was identified in the sources queried. That does not prove that no private exploit, informal demonstration, or undisclosed incident exists. Defenders should describe the current status as exploitation not confirmed and public PoC not confirmed, while still treating the vulnerability as high risk because the affected functionality reaches command execution.

Organizations should not use the absence of KEV status or a public PoC as a reason to defer remediation. AI assistant inputs and knowledge-base content are often supplied by multiple users and integrations, making accidental or malicious triggering possible even without a specialized exploit kit.

How Do I Know If I’m Hit?

Start by inventorying every MaxKB instance, its version, deployment mode, container privilege level, and configured assistants. Identify assistants using SandboxShellBackend, shell-capable tools, MCP tools, skills, or sub-applications. Pay particular attention to instances where MAXKB_SANDBOX is disabled or where the MaxKB process runs with elevated privileges.

Then review application, container, host, and network telemetry for unexpected child processes created by MaxKB. Useful indicators include shells launched by the MaxKB process, commands that access credential files, archive or transfer utilities, attempts to contact unusual external addresses, and processes that modify startup files or persistence locations. The supplied research does not provide a vendor-specific log event ID, so process and container telemetry should be treated as the primary detection source.

For broader endpoint monitoring guidance, see our explanation of MDR, EDR, and XDR differences.

Technical Notes

A Linux auditd rule can provide a starting point for monitoring execution by the MaxKB service account. Replace maxkb with the actual service account and validate the rule in a test environment:

sudo auditctl -a always,exit -F arch=b64 \\
  -S execve -F auid>=1000 -F auid!=4294967295 \\
  -k maxkb-command-execution

Query resulting events for shell and transfer utilities:

sudo ausearch -k maxkb-command-execution -i \\
  | grep -E '(/bin/sh|/bin/bash|/bin/zsh|curl|wget|nc|socat|python|perl|chmod|chown|/etc/passwd|authorized_keys)'

If auditd attribution is not available, a SIEM or EDR query should look for a MaxKB process spawning a shell or network utility. A generic process-lineage pattern is:

parent_process contains ("maxkb" OR "gunicorn" OR "uvicorn")
AND child_process in ("/bin/sh", "/bin/bash", "curl", "wget", "nc", "socat", "python", "perl")

Also inspect container events and outbound connections around the same timestamps. An unexpected shell child, a command running as UID 0, or access to host-mounted paths is a high-priority indicator, but none of these signals alone proves exploitation.

For context on another vulnerability investigation, see our coverage of CVE-2026-53994.

What Do I Do About It?

Upgrade every affected installation to MaxKB 2.10.5-lts or later. The fixed release is documented by the project as v2.10.5-lts. Because deployment methods differ, confirm the active version after the upgrade rather than assuming that updating a source tree or image changed the running service.

For a source checkout managed from the project repository, the release can be fetched and checked out as follows, subject to the project’s documented build and restart procedure:

git fetch --tags origin
git checkout v2.10.5-lts
# Run the deployment's documented dependency, migration, and restart steps.

Do not use this command against an installation that is not managed from the MaxKB Git repository. Container and packaged deployments should use the project’s documented 2.10.5-lts image or package update process, then recreate or restart the service and verify the running version.

Technical Notes

Until the upgrade is complete, remove or disable shell-capable tools and assistants that use SandboxShellBackend. Disable unnecessary MCP tools, skills, and sub-applications that can invoke commands. Require human approval for any remaining high-risk operation, but do not treat approval alone as a complete fix because the vulnerable execute operation and wrapper behavior are the underlying concerns.

Where MAXKB_SANDBOX is disabled, restore an effective sandbox configuration according to the project’s deployment documentation and test it before returning the service to production. Avoid running MaxKB as root, remove unnecessary host mounts, restrict container capabilities, and prevent access to cloud metadata services and sensitive host sockets. These are compensating controls, not substitutes for upgrading.

After patching, review shell and process telemetry for at least the period since the last trusted deployment. Rotate credentials that may have been accessible to the MaxKB process or container, including API keys, database credentials, cloud tokens, and integration secrets. Organizations that need a password manager for securely storing replacement credentials can evaluate Try 1Password →.

If suspicious command execution is found, preserve container and host evidence before rebuilding and follow the organization’s incident-response process.

Where This Comes From

The primary references are the NVD record, the MaxKB project’s security advisory, the vendor patch commit, and the fixed release. The NVD record supplied for this assessment reports a 10.0 score but did not include the CVSS vector, so the live record should be checked before publishing or operationally scoring the issue.

CISA’s KEV catalog is also relevant for exploitation-status validation. As of the supplied lookup, CVE-2026-77521 was not listed. That status should be rechecked during triage because catalog membership can change independently of the vendor release.

• NVD: CVE-2026-77521
• MaxKB security advisory: GHSA-f36j-f34j-h3rx
• MaxKB patch commit
• MaxKB v2.10.5-lts release
• MaxKB project repository
• CISA Known Exploited Vulnerabilities Catalog

Upgrade to MaxKB 2.10.5-lts or later first, while disabling unnecessary command-execution features during the change. Then investigate process activity in deployments that handled untrusted content with shell-capable assistants; the absence of confirmed exploitation does not resolve the exposure in affected versions.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.