CVE-2026-79919: MaxKB AI Assistant Privilege Escalation Flaw

CVE-2026-79919 Overview

MaxKB is an open-source AI assistant for enterprise environments. Versions prior to 2.10.6-lts contain a sandbox escape that lets authenticated workspace members bypass the LD_PRELOAD syscall blacklist. Function-library code can invoke ctypes.CDLL from an importlib.abc.MetaPathFinder callback, tricking the dlopen call-stack heuristic into observing a Python import frame. The attacker then uses unhooked dlsym with RTLD_NEXT to resolve glibc's real syscall symbol and issue arbitrary syscalls as the sandbox user. Successful exploitation allows file read and write, process execution, and network access outside the intended sandbox boundary. The issue is fixed in version 2.10.6-lts.

Critical Impact

An authenticated workspace member can escape the MaxKB Python sandbox and perform arbitrary file, process, and network operations as the sandbox user.

Affected Products

• MaxKB versions prior to 2.10.6-lts
• 1Panel-dev MaxKB open-source AI assistant
• Deployments using the LD_PRELOAD-based Python sandbox

Discovery Timeline

• 2026-09-21 - CVE-2026-79919 published to NVD
• 2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-79919

Vulnerability Analysis

MaxKB executes user-supplied function-library code inside a sandbox enforced by an LD_PRELOAD shared object. The preload hooks dlopen and blocks Python code from loading arbitrary dynamic libraries, and it wraps a set of dangerous syscalls with a blacklist. To distinguish legitimate CPython imports from user calls, the hook walks the return address stack using backtrace and dladdr, allowing the operation only when a symbol matching PyImport or _PyImport is observed. This heuristic is the pivot point of the bypass. An attacker registers an importlib.abc.MetaPathFinder and triggers ctypes.CDLL from inside its find_spec or find_module callback. Because the finder is invoked through the CPython import machinery, PyImport frames appear on the stack and the sandbox permits the load. Once ctypes is available, the attacker calls dlsym(RTLD_NEXT, "syscall") to obtain the unhooked glibc symbol and issues syscalls directly, bypassing the blacklist entirely [CWE-693].

Root Cause

The root cause is a protection-mechanism failure. The called_from_python_import helper in installer/sandbox.c treated any PyImport* frame in the call stack as evidence of a benign import, without validating the caller path. Additionally, dlsym was not hooked, so once ctypes was reachable the sandbox could not intercept syscall resolution via RTLD_NEXT.

Attack Vector

Exploitation requires an authenticated workspace member with permission to submit function-library code. The attacker submits Python code that installs a custom meta path finder and loads ctypes from within the finder callback, then resolves and invokes syscall through RTLD_NEXT. No user interaction is required beyond executing the crafted tool code inside MaxKB.

#  Vendor patch excerpt: apps/common/utils/tool_code.py
allow_dl_open = CONFIG.get("SANDBOX_PYTHON_ALLOW_DL_OPEN", "0")
allow_subprocess = CONFIG.get("SANDBOX_PYTHON_ALLOW_SUBPROCESS", "0")
allow_syscall = CONFIG.get("SANDBOX_PYTHON_ALLOW_SYSCALL", "0")
import _ctypes
ctypes_so_mode = os.stat(_ctypes.__file__).st_mode
# Remove sandbox-user read permission on the ctypes shared object when dlopen is disallowed
os.chmod(
    _ctypes.__file__,
    ctypes_so_mode & ~0o040 if allow_dl_open == "0" else ctypes_so_mode | 0o040,
)

Source: 1Panel-dev/MaxKB commit d4bd22a

// Vendor patch excerpt: installer/sandbox.c
// The stack-walking heuristic was removed; ctypes is now blocked outright
// when dlopen is disallowed.
static int is_allow_dl(const char *filename) {
    ensure_config_loaded();
    if (!filename || !*filename) return 1;
    if (!allow_dl_open && strstr(filename, "_ctypes")) {
        throw_permission_denied_err(true, "open dynamic link library");
    }
    if (!allow_dl_paths || !*allow_dl_paths) return 0;
    /* ... */
}

Source: 1Panel-dev/MaxKB commit d4bd22a

Detection Methods for CVE-2026-79919

Indicators of Compromise

• Sandbox-user processes spawning unexpected child processes such as /bin/sh, curl, or python outside the MaxKB tool runtime.
• Outbound network connections originating from the sandbox user account to destinations not tied to configured MaxKB integrations.
• File read or write activity by the sandbox user on paths outside the tool workspace, including /etc, /root, or mounted secrets.

Detection Strategies

• Hunt for MaxKB function-library code that imports or references ctypes, _ctypes, importlib.abc.MetaPathFinder, RTLD_NEXT, or dlsym.
• Monitor execve, connect, and openat syscalls attributed to the sandbox user via auditd or eBPF sensors.
• Alert on any attempt by the sandbox user to load shared objects outside the MaxKB-approved allow_dl_paths list.

Monitoring Recommendations

• Enable process and network telemetry on hosts running MaxKB and forward it to a centralized analytics platform for retention and correlation.
• Baseline normal MaxKB tool execution behavior and alert on deviations such as new outbound destinations or unusual binaries.
• Review MaxKB audit logs for workspace members submitting or modifying function-library code around suspected exploitation windows.

How to Mitigate CVE-2026-79919

Immediate Actions Required

• Upgrade MaxKB to version 2.10.6-lts or later on all deployments.
• Restrict workspace membership and revoke function-library submission rights from users who do not require them.
• Audit existing function-library code for references to ctypes, _ctypes, MetaPathFinder, or dlsym and remove suspicious entries.

Patch Information

The fix is delivered in MaxKB release v2.10.6-lts and implemented in commit d4bd22a. The patch removes the fragile PyImport stack-walking heuristic, blocks loading of the _ctypes shared object when SANDBOX_PYTHON_ALLOW_DL_OPEN is disabled, and strips the sandbox user's read permission from the _ctypes shared object on startup. See the GitHub Security Advisory GHSA-6h35-c779-4v37 for full disclosure details.

Workarounds

• Ensure SANDBOX_PYTHON_ALLOW_DL_OPEN, SANDBOX_PYTHON_ALLOW_SUBPROCESS, and SANDBOX_PYTHON_ALLOW_SYSCALL are set to 0 in the MaxKB configuration.
• Manually remove read access to the CPython _ctypes shared object for the sandbox user until the upgrade is applied.
• Isolate the MaxKB container or host at the network layer so a sandbox escape cannot reach sensitive internal services.

# Temporary hardening: strip sandbox-user read on _ctypes and enforce restrictive sandbox config
CTYPES_SO=$(python3 -c 'import _ctypes; print(_ctypes.__file__)')
chmod o-r "$CTYPES_SO"

# Ensure sandbox toggles are disabled in MaxKB configuration
export SANDBOX_PYTHON_ALLOW_DL_OPEN=0
export SANDBOX_PYTHON_ALLOW_SUBPROCESS=0
export SANDBOX_PYTHON_ALLOW_SYSCALL=0