CVE-2026-79919 in MaxKB
Summary
by MITRE • 09/22/2026
MaxKB is an open-source AI assistant for enterprise. Prior to version 2.10.6-lts, function-library code running under the LD_PRELOAD sandbox can invoke ctypes.CDLL from an importlib.abc.MetaPathFinder callback so the dlopen call-stack heuristic sees a Python import frame, then use unhooked dlsym with RTLD_NEXT to resolve glibc's real syscall and bypass the sandbox syscall blacklist. An authenticated workspace member can consequently read or write files, execute processes, or access networks as the sandbox user. This issue is fixed in version 2.10.6-lts.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MaxKB prior to version 2.10.6-lts represents a critical failure in process isolation mechanisms designed to restrict untrusted code execution within an enterprise AI assistant environment. The core of the issue lies in the implementation of the LD_PRELOAD sandbox, which is intended to intercept and control system calls made by function-library code running under restricted permissions. This security model relies on heuristics that inspect the call stack during dynamic library loading operations to determine whether a request originates from trusted or untrusted contexts. Specifically, the mechanism attempts to detect Python import frames within the dlopen call-stack heuristic to distinguish between legitimate application behavior and potential malicious activity originating from sandboxed function libraries.
The technical flaw exploits the interaction between Python's import system and the dynamic linker. An authenticated workspace member with access to create custom functions or plugins can leverage a crafted MetaPathFinder callback registered via importlib.abc.MetaPathFinder. When this callback is triggered during an import operation, it invokes ctypes.CDLL, which in turn triggers dlopen within the sandboxed environment. Because the LD_PRELOAD hooking mechanism inspects the call stack and identifies Python frames as part of normal application behavior rather than malicious bypass attempts, it fails to apply the necessary restrictions. Consequently, the attacker can utilize unhooked versions of dlsym with the RTLD_NEXT flag to resolve real glibc functions directly, effectively circumventing the sandbox's syscall blacklist. This allows the execution of system calls that were previously blocked by the security policy.
The operational impact of this vulnerability is severe, as it grants an authenticated user full control over the underlying operating system resources accessible to the sandboxed process. By bypassing the syscall restrictions, an attacker can read sensitive files from the server filesystem, write malicious data or scripts to disk, execute arbitrary processes with the privileges of the sandbox user, and establish network connections to external hosts. This effectively nullifies the isolation guarantees provided by the LD_PRELOAD mechanism, turning a restricted execution environment into one that is functionally equivalent to an unrestricted shell for any authenticated workspace member who can inject such code. The risk is particularly acute in enterprise settings where multiple users share workspaces or where less privileged users might have been granted excessive permissions within specific project contexts.
This vulnerability aligns with CWE-250, which describes execution with unnecessary privileges, and CWE-693, Protection Mechanism Failure, as the security control designed to limit actions was bypassed through a logic error in its detection heuristic. From an ATT&CK perspective, this technique relates to T1055, Process Injection, specifically via dynamic-link library hijacking or manipulation of system call interception mechanisms, and potentially T1620, Reflective Code Loading, if the attacker uses memory-resident techniques facilitated by the bypassed dlsym. The exploitation path also touches upon T1059, Command and Scripting Interpreter, as Python is used to orchestrate the initial trigger for the system call bypass.
To mitigate this vulnerability, organizations must immediately upgrade MaxKB to version 2.10.6-lts or later, where the developers have addressed the flaw in the LD_PRELOAD sandbox logic. Until upgrading is possible, administrators should rigorously audit workspace permissions and restrict who can create custom function libraries or plugins within the application. It is also advisable to implement additional layers of defense such as mandatory access control systems like SELinux or AppArmor at the operating system level to limit what even a compromised process with bypassed sandbox restrictions can do on the host file system and network stack. Regular security assessments should include testing for similar heuristic-based bypasses in any custom isolation mechanisms deployed within AI-driven enterprise applications.