Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-09-21T21:17:12.777Z",
  "pubdate": "2026-09-21T21:17:12.777Z",
  "executiveSummary": "A sandbox escape vulnerability exists in MaxKB prior to version 2.10.6-lts due to an incomplete hook implementation within the ToolExecutor component. The sandbox utilizes LD_PRELOAD to intercept standard process creation system calls, specifically execve, execvpe, and execveat, to enforce security policies and prevent unauthorized subprocess execution. However, the omission of the fexecve system call allows an authenticated attacker to bypass these security controls.\nBy leveraging this flaw, an attacker with the ability to execute tool code can invoke fexecve to spawn processes that remain outside the intended sandbox restrictions. This vulnerability poses significant risk to enterprise deployments, as it permits arbitrary code execution beyond the defined security boundaries. The exploitation requires authenticated access to the application’s tool execution environment. The vulnerability has been addressed in version 2.10.6-lts, which updates the hooking mechanism to include the missing system call, effectively closing the bypass vector.",
  "technicalDetails": "The vulnerability originates from a restricted sandbox implementation in MaxKB's ToolExecutor component, which relies on the LD_PRELOAD mechanism to mediate system calls related to process creation. In Linux environments, the exec family of functions facilitates the execution of new programs. The sandbox implementation specifically hooks execve, execvpe, and execveat to intercept and inspect or block process initialization attempts by user-supplied tool code.\nThe root cause is an incomplete system call coverage. While the developers successfully identified and intercepted the standard exec system calls, the fexecve function was overlooked. The fexecve system call performs the same fundamental operation as execve, but it accepts a file descriptor referring to the executable rather than a path string. Because the security policy enforcement logic is tethered strictly to the hooked functions, an attacker can bypass the policy entirely by utilizing the fexecve system call.\nThe attack flow proceeds as follows: First, an attacker must obtain authenticated access to the MaxKB platform and gain the ability to execute arbitrary tool code. Second, instead of invoking blocked functions like execve, the attacker crafts a payload that opens a target executable file to obtain a file descriptor. Third, the attacker calls fexecve using this file descriptor. Since the ToolExecutor’s LD_PRELOAD hooks do not monitor the fexecve entry point, the system call is executed directly by the kernel without triggering the sandbox's security enforcement layer.\nThis allows the spawned process to operate with the privileges of the underlying MaxKB application process but without the operational constraints intended by the sandbox policy. The impact of this vulnerability is a complete bypass of the process execution whitelist or restriction policy. A successful exploit enables the attacker to initiate unauthorized processes, facilitating lateral movement, further exploitation of the host environment, or information gathering. Because the sandbox is intended to provide a security boundary between user-defined tools and the host operating system, the failure to secure the fexecve vector invalidates the isolation guarantees provided by the ToolExecutor, allowing for privilege escalation or sandbox escape, depending on the host configuration."
}