CVE-2026-39418
Sandbox Bypass via MSG_FASTOPEN in MaxKB AI Assistant
Publication date: 2026-04-14
Last updated on: 2026-04-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| maxkb | maxkb | to 2.8.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an authenticated user with tool-editing permissions to bypass sandbox network protections and access internal services that are explicitly blocked. Such unauthorized access could potentially lead to exposure or misuse of sensitive data.
While the CVE description and resources do not explicitly mention compliance with standards like GDPR or HIPAA, the ability to bypass network restrictions and access internal services may increase the risk of data breaches or unauthorized data access, which could impact compliance with data protection regulations.
The vulnerability has a moderate severity score (CVSS 5.0) with low impact on confidentiality, integrity, and availability, suggesting limited but non-negligible risk.
Can you explain this vulnerability to me?
CVE-2026-39418 is a Server-Side Request Forgery (SSRF) vulnerability in MaxKB, an open-source AI assistant for enterprise. In versions 2.7.1 and below, the sandbox environment uses LD_PRELOAD to hook the connect() function to block connections to banned IP addresses. However, the vulnerability arises because the sandbox does not properly intercept the sendto() system call when used with the MSG_FASTOPEN flag. On Linux, sendto() with MSG_FASTOPEN can establish TCP connections directly through the kernel without calling connect(), bypassing the sandbox's IP validation and allowing connections to internal services that should be blocked.
This bypass occurs because although sendto is listed in a syscall wrapper, glibc invokes the kernel syscall directly rather than routing through the hooked syscall() function, making the sandbox's protections ineffective against this method. The issue was fixed in MaxKB version 2.8.0 by extending the sandbox's network call interception to include sendto(), sendmsg(), and sendmmsg() functions.
How can this vulnerability impact me? :
This vulnerability allows an authenticated user with tool-editing permissions to bypass sandbox network restrictions and reach internal services that are explicitly blocked by the sandbox's banned hosts configuration. This can lead to unauthorized access to internal network resources that should be protected.
The impact is considered moderate with a CVSS v3.1 base score of 5.0, indicating that while the attack complexity is high and privileges required are low, the confidentiality, integrity, and availability impacts are low. Nonetheless, it can enable attackers to perform SSRF attacks within the sandbox environment, potentially exposing sensitive internal services.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves bypassing sandbox network protections by using the sendto() system call with the MSG_FASTOPEN flag, which is not intercepted by the sandbox's connect() hook. Detection involves monitoring for unusual use of sendto() with MSG_FASTOPEN, especially from authenticated users with tool-editing permissions.
You can detect attempts to exploit this vulnerability by monitoring system calls related to sendto() with MSG_FASTOPEN flag usage or by auditing network connections that bypass the usual sandbox restrictions.
- Use Linux audit framework (auditd) to monitor sendto syscalls with MSG_FASTOPEN flag.
- Example audit rule to log sendto calls with MSG_FASTOPEN: auditctl -a exit,always -S sendto -F a0&0x20000000!=0
- Use strace on the MaxKB process to observe sendto() calls with MSG_FASTOPEN flag.
- Check network connections from sandboxed users to banned IPs that should be blocked by the sandbox.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade MaxKB to version 2.8.0 or later, where this vulnerability has been fixed by extending sandbox network call interceptions to include sendto(), sendmsg(), and sendmmsg() system calls.
If upgrading immediately is not possible, consider restricting tool-editing permissions to trusted users only, as exploitation requires authenticated users with such permissions.
Additionally, monitor and restrict network access at the OS or network level to prevent unauthorized connections to banned IP addresses from sandboxed environments.
Apply the patch that intercepts and validates sendto(), sendmsg(), and sendmmsg() calls to block connections to banned IPs and Unix domain sockets, as described in the security patch.