CVE-2026-107909 in FalkorDB
Summary
by MITRE • 10/09/2026
A heap-based out-of-bounds write in the ws_read_frame function (src/bolt/ws.c) and the buffer_apply_mask function (src/bolt/buffer.c) in FalkorDB before 4.20.0 allows a remote unauthenticated attacker to cause a denial of service and possibly corrupt heap memory by sending a WebSocket frame with a 64-bit extended payload length to the Bolt port. The payload length is not bounded, and the only bounds check in buffer_apply_mask is an ASSERT(), which is compiled out in release builds, so the function XORs memory beyond the end of the receive buffer with the attacker-supplied mask key. Only deployments that enable the Bolt endpoint (BOLT_PORT, disabled by default) are affected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified involves a critical heap-based out-of-bounds write within the FalkorDB database engine, specifically affecting versions prior to 4.20.0. This flaw resides in two distinct code paths: the ws_read_frame function located in src/bolt/ws.c and the buffer_apply_mask function found in src/bolt/buffer.c. The root cause of this vulnerability is a failure to properly validate input data regarding WebSocket frame payload lengths, which allows an attacker to manipulate memory allocation and access boundaries that should remain protected by standard heap management structures.
The technical mechanism exploits how FalkorDB handles the Bolt protocol over WebSockets. When a client sends a WebSocket frame containing a 64-bit extended payload length field, the server processes this value without enforcing strict upper bounds relative to the allocated receive buffer size. In the ws_read_frame function, the system prepares for data processing based on this unbounded length specification. Subsequently, when the buffer_apply_mask function is invoked to decrypt or transform the incoming data using a XOR mask key, it relies solely on an ASSERT macro for boundary checking. Because assertions are typically compiled out in production and release builds of software, this safety check effectively disappears during normal operation, leaving no runtime validation to prevent memory access violations.
As a result of these missing checks, if an attacker sends a WebSocket frame with a sufficiently large 64-bit extended payload length, the buffer_apply_mask function will proceed to XOR data beyond the end of the allocated receive buffer using the attacker-supplied mask key. This operation constitutes a heap-based out-of-bounds write, as it modifies memory locations that do not belong to the intended buffer structure. Such unauthorized writes can corrupt adjacent heap metadata or other critical in-memory structures, leading to unpredictable behavior within the database engine process.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service condition where the FalkorDB instance may crash due to memory corruption errors triggered by the out-of-bounds write. Beyond simple availability loss, heap corruption poses significant security risks including potential arbitrary code execution if an attacker can carefully craft subsequent allocations and writes to overwrite function pointers or control flow data within the heap layout. However, it is crucial to note that this vulnerability only affects deployments where the Bolt endpoint has been explicitly enabled via the BOLT_PORT configuration setting. By default, this feature is disabled in FalkorDB installations, which limits the attack surface for most standard configurations but remains a critical risk for users who have opted into using the Bolt protocol over WebSockets.
From an industry standards perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write, as it involves writing to memory outside of the intended buffer boundary due to insufficient validation of input data lengths. Additionally, the exploitation technique relates to CWE-20: Improper Input Validation, specifically regarding the failure to enforce constraints on numeric values derived from network inputs. In terms of attack patterns, this scenario is consistent with ATT&CK techniques involving resource exhaustion for denial of service and potentially memory corruption primitives that could lead to privilege escalation or remote code execution depending on the specific heap state at the time of exploitation.
To mitigate this risk, organizations running FalkorDB versions earlier than 4.20.0 must immediately apply the vendor-provided patch that updates these functions to include proper bounds checking independent of debug assertions. For deployments where upgrading is not immediately feasible, a temporary mitigation involves ensuring that the Bolt endpoint remains disabled by verifying that BOLT_PORT is not configured or enabled in the system settings. This effectively neutralizes the attack vector since the vulnerable code path will never be executed under normal operational conditions without explicit configuration enabling it. Regular security audits and penetration testing should also be conducted to verify that no other endpoints expose similar input validation weaknesses, ensuring comprehensive protection against heap corruption vulnerabilities.