MaxKB CVE-2026-79919

Requires an authenticated MaxKB workspace member who can create and execute function-library (tool) code that runs inside the LD_PRELOAD syscall sandbox - this code-authoring capability is the primary prerequisite and gate. The target must be running MaxKB prior to 2.10.6-lts with the LD_PRELOAD sandbox enforcing a syscall blacklist (the default protection being bypassed). Exploitation depends on the sandbox's dlopen protection using the removed backtrace call-stack heuristic (called_from_python_import) and on _ctypes remaining loadable by the sandbox user; the fix both replaces the heuristic and, when dlopen is disallowed, strips the sandbox user's read permission on the ctypes shared object. Escaped capabilities are limited to whatever the low-privilege sandbox OS user can access (files, processes, network), not root, which bounds real-world impact.

This is a sandbox-escape / protection-mechanism failure (CWE-693) in MaxKB's LD_PRELOAD-based syscall sandbox, not a conventional remote code-execution flaw. The vendor CVSS of 6.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) is driven down by the low per-impact ratings and the PR:L authentication requirement. However, that scoring understates the outcome: the entire purpose of the exploit is to defeat the syscall blacklist and regain arbitrary file read/write, process execution, and network access - capabilities the sandbox exists to prevent - hence my independent assessment raises the impact metrics. AV:N is technically correct because the attacker interacts over the network as an authenticated workspace member, but exploitation is really a code-authoring/config-adjacent action (writing function-library code that runs in the sandbox), so PR:L is essential and PR:N would be wrong. No EPSS score, KEV listing, or POC is present in the input, so there is no signal of active or automated exploitation - this is a real but pre-exploitation issue whose realistic priority is bounded by (a) needing an authenticated workspace member who can author/run function-library code and (b) the escaped capabilities being confined to the low-privilege sandbox OS user. It is a genuine security-boundary break worth patching, but not a mass-exploitation, high-urgency emergency absent evidence of exploitation. Note the impact-severity disagreement between vendor (C:L/I:L/A:L) and this analysis (see assessed vector) - verify against the vendor advisory GHSA-6h35-c779-4v37.

An authenticated MaxKB workspace member authors function-library (tool) code that runs inside the LD_PRELOAD sandbox. The code registers an importlib.abc.MetaPathFinder whose callback invokes ctypes.CDLL, so the sandbox's dlopen call-stack heuristic sees a legitimate-looking Python import frame; it then uses unhooked dlsym with RTLD_NEXT to resolve glibc's real syscall entry point, bypassing the syscall blacklist to read/write files, spawn processes, and reach the network as the sandbox user. No public exploit identified at time of analysis, though the fix commit and advisory disclose the technique in enough detail to reconstruct it.