CVE-2026-79918 in MaxKB
Summary
by MITRE • 09/22/2026
MaxKB is an open-source AI assistant for enterprise. Prior to version 2.10.6-lts, the ToolExecutor LD_PRELOAD sandbox hooks execve, execvpe, and execveat to prevent subprocess creation but does not hook fexecve. An authenticated attacker able to execute tool code can call fexecve to start a process outside the sandbox's intended subprocess policy. This issue is fixed in version 2.10.6-lts.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MaxKB prior to version 2.10.6-lts represents a significant security flaw within its tool execution environment, specifically concerning the mechanism used to restrict process creation. MaxKB functions as an open-source AI assistant designed for enterprise use, where it processes user inputs and executes various tools or scripts to generate responses. To mitigate risks associated with arbitrary command injection or unauthorized system access when executing these tools, the application employs a sandboxing strategy that leverages the LD_PRELOAD environment variable. This technique allows the interception of dynamic library calls at runtime without modifying the original binary code. In this specific implementation, the security controls were configured to hook into critical execution functions such as execve, execvpe, and execveat. These hooks are designed to inspect incoming system calls for subprocess creation and block those that violate predefined safety policies, thereby preventing malicious actors from spawning arbitrary processes within the context of the AI assistant's operation.
Despite these protective measures, a technical oversight resulted in an incomplete coverage of execution vectors. The sandboxing mechanism failed to hook fexecve, which is another standard POSIX function used to execute programs based on file descriptors rather than file paths. While execve and its variants are commonly targeted by attackers seeking to run commands via path-based arguments, fexecve offers a distinct pathway for process initiation that bypasses the intended restrictions if left unmonitored. This gap in the LD_PRELOAD hooking strategy creates an exploitable condition where the security boundary is effectively breached through alternative system call interfaces. The flaw stems from a lack of comprehensive enumeration and interception of all available execution entry points within the operating system's API surface, highlighting a common challenge in application-level sandboxing where developers may focus on primary execution methods while neglecting less frequently used but equally potent alternatives like fexecve.
The operational impact of this vulnerability is severe for any organization relying on MaxKB to handle sensitive tasks or execute untrusted tool code. An authenticated attacker who has the capability to inject and execute arbitrary tool commands within the application can exploit this oversight by invoking fexecve instead of the hooked functions. By doing so, the attacker can initiate processes that operate outside the sandbox's intended subprocess policy. This effectively nullifies the protective layer designed to contain malicious activity, allowing for potential remote code execution, data exfiltration, or lateral movement within the host environment depending on the privileges under which MaxKB is running. The ability to bypass these restrictions undermines the integrity of the AI assistant and poses a direct threat to the confidentiality and availability of enterprise systems connected to it.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command, specifically reflecting a failure to handle all input vectors or execution paths adequately within a security control mechanism. It also relates to CWE-250 Execution Required with Unrestrictedly Controlled Input, as the attacker must have authenticated access and the ability to trigger tool execution. From a tactical perspective, this exploit technique corresponds to ATT&CK T1059 Command and Scripting Interpreter, where an adversary uses system utilities or APIs to execute commands on a target host. The specific use of fexecve to bypass sandbox restrictions can be categorized under techniques that involve manipulating file descriptors for privilege escalation or evasion purposes, emphasizing the need for defense-in-depth strategies rather than relying solely on single-point mitigations like LD_PRELOAD hooks.
To mitigate this risk and prevent similar issues in future versions, it is imperative to ensure comprehensive coverage of all execution-related system calls within sandboxing implementations. Developers should audit their use of dynamic library interception techniques to include fexecve alongside execve, execvpe, and other variants such as posix_spawn or fork combined with subsequent execution functions. Additionally, implementing stricter input validation and least-privilege principles for the processes running MaxKB can reduce the blast radius if a bypass is attempted. Upgrading to version 2.10.6-lts resolves this specific flaw by extending the sandbox hooks to cover fexecve, thereby closing the gap in subprocess control. Organizations currently using earlier versions of MaxKB should prioritize immediate patching and review their authentication controls to ensure that only trusted users have access to tool execution features, minimizing the attack surface available for exploitation.