MaxKB implements a sandbox that injects a shared object through LD_PRELOAD to monitor critical libc calls used by untrusted Python code executed via its Tool Debug API. In versions up to and including 2.7.1 the sandbox permits the /usr/bin/env utility for sandboxed users, and the env -i option clears all environment variables, including LD_PRELOAD. An authenticated user with tool execution privileges can therefore run env -i python to drop the sandbox hooks before the subprocess starts, giving the Python process unrestricted access to the host for file and network operations. This results in a remote code execution vulnerability that allows an attacker to execute arbitrary code and access network resources from within the MaxKB instance. The flaw is manifested as a misuse of a trusted component (CWE‑693) and an OS command‑introduction vector (CWE‑78).

The affected product is the open‑source AI assistant MaxKB developed by 1Panel‑dev. Any deployment using version 2.7.1 or earlier is vulnerable; the issue was patched in release 2.8.0.

The CVSS v3 score of 6.3 indicates a moderate-to-high severity. Exploitation requires the attacker to already have a privileged account that can invoke the Tool Debug API, so the risk is confined to compromised MaxKB instances. EPSS data is unavailable, but the vulnerability is not currently listed in CISA’s KEV catalog. The likely attack vector is local, through authenticated tool execution; post‑exploitation the attacker can launch arbitrary code or network connections from the host. Accordingly, organizations should treat this as a risk that can be mitigated by patching or by restricting the ability to execute env within the sandbox.