Skip to main content

MaxKB CVE-2025-66419

CRITICAL
Race Condition (CWE-362)
2025-12-11 security-advisories@github.com
10.0
CVSS 3.1 · NVD
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate / gain tool-execution access
  2. Delivery
    Submit malicious tool code
  3. Exploit
    Race concurrent ToolExecutor init
  4. Execution
    Escape sandbox to host user
  5. Impact
    Execute code with elevated privileges

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires that MaxKB's tool/code-execution sandbox is in use (CONFIG SANDBOX enabled, which maps execution to a restricted 'sandbox' user) and that the attacker can submit or trigger custom Python code through the tool module (tool_node, tool_lib_node, ai_chat_step_node, or MCP request paths shown in the diff). Exploitation further requires meeting 'certain concurrent conditions' - i.e., winning a race in ToolExecutor initialization - which limits reliability and rules out trivial single-shot exploitation. Limiting factors: the race-condition timing dependency (not AC:L in practice), the need for tool-module access that in typical deployments is authenticated, and the requirement that the sandbox feature path be active. If the sandbox is not enabled, the sandbox-escape premise does not apply in the same way.

Impact

Signals conflict sharply here. The input CVSS is a maximal 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), but the other evidence does not support treating this as a top-tier emergency. EPSS is only 0.31% (22nd percentile), there is no CISA KEV listing (exploitation status: no public exploit identified at time of analysis), and no public POC is referenced - only the vendor patch, release tag, and GitHub advisory. Two internal contradictions weaken the 10.0: (1) the CVSS encodes AC:L, yet both the description ('under certain concurrent conditions') and the CWE-362 Race Condition classification indicate exploitation depends on winning a timing window, which is realistically AC:H and reduces reliability; (2) the CVSS encodes PR:N (unauthenticated), yet the vulnerability lives in MaxKB's tool/code-execution module, and the commit diff shows the flaw is a sandbox-escape in ToolExecutor - abusing it requires the ability to run tool/function code, which in MaxKB deployments is typically an authenticated capability, so PR:N likely overstates reachability (verify auth model with vendor). Net: a genuinely serious sandbox-escape-to-host privilege escalation worth prompt patching for anyone running MaxKB <=2.3.1 with the sandbox enabled, but the low EPSS, absence of KEV/POC, and race-condition prerequisite make it a patch-on-schedule issue rather than a drop-everything, high-CVSS-but-realistically-conditional risk.

Exploit ScenarioDerived

An actor who can submit or trigger execution of custom Python tool/function code inside MaxKB (<=2.3.1) repeatedly invokes the tool module to race the ToolExecutor sandbox initialization. By exploiting the concurrent-condition window, the code executes outside the intended 'sandbox' user context and runs with the host application user's privileges, yielding code execution on the MaxKB server. No public exploit or POC is identified at time of analysis; reliability depends on winning the race condition.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 07, 2026

Sandbox escape and privilege escalation in MaxKB 2.3.1 and earlier allow an attacker who can submit or trigger custom Python tool code to break out of the platform's tool-execution sandbox and operate with elevated privileges, but only when a race condition during ToolExecutor/sandbox initialization is won under concurrent requests. NVD scores the issue 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), while the independent assessment revises it to AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H because tool-module access in typical deployments is authenticated and the exploit depends on a timing race - so practical exploitability is materially lower than the headline score even though the impact once the race succeeds is complete (all three CIA impacts High with Scope:Changed). Exploitation status: no public exploit identified at time of analysis, and EPSS is low at 0.31% (22nd percentile); MaxKB 2.4.0 is the vendor-released fix.

RemediationAI

Vendor-released patch: upgrade to MaxKB 2.4.0 (release v2.4.0) or cherry-pick commit f8ada9a110c4dbef8c3c2636c78847ecd621ece7, which moves sandbox state to module-level constants and initializes the sandbox directory once at import time, eliminating the initialization race; see the advisory at https://github.com/1Panel-dev/MaxKB/security/advisories/GHSA-f9qm-2pxq-fx6c for confirmation. Because the commit renames SANDBOX_PYTHON_PROCESS_TIMEOUT_SECONDS to SANDBOX_PYTHON_PROCESS_LIMIT_TIMEOUT_SECONDS, verify custom timeout settings after upgrading or they will silently revert to the 3600-second default. If immediate upgrade is not possible, compensating controls are limited and each has trade-offs: disable custom tool/Python code execution entirely (removes AI tool features that depend on code execution) and, where tools must stay enabled, restrict tool authoring and trigger rights to fully trusted administrators only - the assessed vector is PR:L, so removing untrusted authenticated access removes the realistic attack path - and place the MaxKB UI/API behind an authenticating reverse proxy that blocks unauthenticated chat and flow endpoints; note that enabling SANDBOX without the patched initialization only partly mitigates, since the race can still leave a partially initialized sandbox, and disabling the sandbox is not a safe workaround because it runs tool code as the MaxKB service user.

Affects your stack

Find out whether the stacks and servers you run are on an affected version.

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

MaxKB exposes a "tool" capability in its chat pipeline and flow engine (tool_node, tool_lib_node, ai_chat_step_node, and MCP request handling) that executes user-supplied Python through the ToolExecutor class in apps/common/utils/tool_code.py. When the SANDBOX option is enabled, execution is intended to be constrained by a Linux LD_PRELOAD-based library (sandbox.so), a dedicated unprivileged 'sandbox' user applied via os.setgid/os.setuid, a hardened sandbox home directory (chmod -R 550), and CPU/memory/time limits - the code paths shown in the fix diff. The root cause is CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization): ToolExecutor previously took the sandbox flag as a per-instance constructor argument (ToolExecutor(CONFIG.get('SANDBOX'))) and read related state from class attributes, while sandbox directory/library initialization and permission hardening could race against concurrent instantiations and code executions. The patched commit hoists sandbox configuration into module-level constants evaluated once at import (_enable_sandbox, _run_user, _sandbox_path, _process_limit_timeout_seconds, _process_limit_cpu_cores, _process_limit_mem_mb), calls init_sandbox_dir() once at module load inside a try/except with error logging, and drops the constructor parameter so every executor shares one consistently initialized sandbox context. In the vulnerable state, a racing request can execute tool code while the sandbox directory, permissions, or user-switching state is incompletely established, yielding escape from the intended restriction and privilege escalation. The patch also renames the timeout setting from SANDBOX_PYTHON_PROCESS_TIMEOUT_SECONDS to SANDBOX_PYTHON_PROCESS_LIMIT_TIMEOUT_SECONDS.

Know when Maxkb gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

NVD PRIMARY 10.0 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
vuln.today AI 8.5 HIGH

Race-condition timing makes AC:H; running tool code requires an authenticated account so PR:L; sandbox escape to host user crosses a trust boundary (S:C) giving full host-user code execution (C/I/A:H).

3.1 AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

DescriptionNVD

MaxKB is an open-source AI assistant for enterprise. In versions 2.3.1 and below, the tool module allows an attacker to escape the sandbox environment and escalate privileges under certain concurrent conditions. This issue is fixed in version 2.4.0.

Executive ViewAI

Why It Matters

MaxKB 2.3.1 and earlier contain a critical sandbox escape and privilege escalation flaw that could let an attacker with tool-code access gain elevated privileges and compromise the host or connected knowledge data. Although no public exploit has been identified and real-world exploitation likelihood is currently low, the potential for complete confidentiality, integrity, and availability loss makes this a priority for organizations running affected MaxKB deployments. MaxKB 2.4.0 resolves the issue and should be deployed promptly.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.3%
Top 78% exploitable
Prevalence
Low
niche open-source enterprise AI assistant, limited real-world production footprint
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

50
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +50
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).

Affected Products (CPE)NVD

cpe:2.3:a:maxkb:maxkb:*:*:*:*:-:*:*:*

More in Maxkb

View all
CVE-2025-48950 HIGH POC
8.8 Jun 03

MaxKB prior to version 1.10.8-lts contains an incomplete sandbox implementation that only blacklists binary execution in

CVE-2026-77521 CRITICAL
10.0 Sep 21

Command injection in MaxKB before 2.10.5-lts allows unauthenticated remote attackers to execute arbitrary shell commands

CVE-2026-56779 MEDIUM POC
5.3 Jun 25

Server-side request forgery in MaxKB before 2.10.0 allows any authenticated user holding the default workspace USER role

CVE-2026-79916 CRITICAL
9.1 Sep 21

Authenticated workspace members on MaxKB deployments prior to 2.10.5-lts can escalate to root-level command execution by

CVE-2025-64511 HIGH
8.8 Nov 13

Server-side request forgery in MaxKB (open-source AI assistant from 1Panel-dev) allows an authenticated user with permis

CVE-2026-54149 HIGH
8.8 Jul 10

OS command injection in MaxKB (1Panel-dev's open-source enterprise AI assistant) before 2.10.0-lts lets an authenticated

CVE-2025-66446 HIGH
7.5 Dec 11

Privilege escalation in MaxKB 2.3.1 and earlier allows an authenticated, low-privileged user to overwrite the built-in d

CVE-2026-44847 HIGH
7.5 May 26

Authentication bypass in MaxKB (1Panel-dev) versions prior to 2.9.0 allows remote unauthenticated attackers to invoke we

CVE-2026-77523 HIGH
7.4 Sep 21

Cross-workspace read and modification of model parameter defaults in MaxKB 2.10.3-lts and earlier is possible for an aut

CVE-2026-39423 MEDIUM
6.9 Apr 14

Stored Cross-Site Scripting (XSS) via Eval Injection in MaxKB's Markdown rendering engine allows authenticated users to

CVE-2026-39422 MEDIUM
6.9 Apr 14

Stored Cross-Site Scripting (XSS) in MaxKB 2.7.1 and below allows authenticated users to inject malicious JavaScript thr

CVE-2026-45413 MEDIUM
6.9 May 26

MaxKB, an open-source enterprise AI assistant by 1Panel-dev, stores user passwords as unsalted MD5 hashes, exposing all

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy