CVE-2026-107908 in FalkorDB
Summary
by MITRE • 10/09/2026
A heap-based out-of-bounds write in the BoltReadHandler function (src/bolt/bolt_api.c) in FalkorDB before 4.20.0 allows a remote unauthenticated attacker to cause a denial of service and possibly execute arbitrary code by sending a Bolt RESET message with an attacker-chosen chunk size to the Bolt port. The handler checks the size only with ASSERT(), which is compiled out in release builds, then computes a destination pointer from the wire-supplied 16-bit size and moves buffered data up to about 64 KiB backwards past the start of the read buffer. Only deployments that enable the Bolt endpoint (BOLT_PORT, disabled by default) are affected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in FalkorDB versions prior to 4.20.0 represents a critical heap-based out-of-bounds write flaw located within the BoltReadHandler function found in the source file src/bolt/bolt_api.c. This security defect arises from an improper validation of input data received via the Bolt protocol, which is commonly used for database communication. The core issue stems from the handler's reliance on ASSERT macros to verify the size parameter provided by the client during a RESET message exchange. In software development practices, assertions are typically intended for debugging and are often stripped out or disabled in optimized release builds to improve performance. Consequently, when FalkorDB is deployed with default production settings where these checks are absent, the application fails to validate whether the chunk size supplied by the attacker exceeds safe boundaries before proceeding with memory operations.
The technical mechanism of exploitation involves an unauthenticated remote actor sending a specifically crafted Bolt RESET message containing a maliciously chosen 16-bit chunk size value. Upon receiving this payload, the vulnerable handler computes a destination pointer based on this wire-supplied integer and subsequently attempts to move buffered data backwards by up to approximately sixty-four kilobytes past the start of the allocated read buffer. This operation results in writing memory contents into heap regions that do not belong to the current allocation context. Such out-of-bounds writes corrupt adjacent heap metadata or overwrite critical application structures, leading directly to a denial of service through process crashes or segmentation faults. More severely, if an attacker can carefully control the data written and the surrounding heap layout, this memory corruption may be leveraged to achieve arbitrary code execution with the privileges of the FalkorDB process.
From a classification perspective, this vulnerability aligns closely with CWE-787: Out-of-bounds Write, as it involves writing to a memory location outside the bounds of an allocated buffer. It also exhibits characteristics of CWE-20: Improper Input Validation due to the failure to adequately sanitize or verify user-supplied input before processing. In terms of offensive security frameworks, this attack vector corresponds to ATT&CK technique T1498: Network Denial of Service for the impact aspect and potentially T1203: Exploitation for Client Execution if arbitrary code execution is successfully achieved through heap exploitation techniques such as heap spraying or metadata corruption. The vulnerability specifically targets deployments that have explicitly enabled the Bolt endpoint, known internally as BOLT_PORT. It is important to note that this port is disabled by default in standard configurations, which limits the immediate attack surface but does not eliminate risk for organizations that require Bolt protocol connectivity for specific application integrations.
Mitigation strategies must prioritize updating the FalkorDB installation to version 4.20.0 or later, where the underlying code has been patched to include proper bounds checking independent of debug assertions. For environments unable to upgrade immediately due to compatibility constraints, network-level controls should be implemented to restrict access to the Bolt port exclusively from trusted IP addresses using firewall rules or security groups. Additionally, enabling strict input validation at any proxy layer in front of the database can help filter out malformed packets before they reach the vulnerable handler. Security teams should also monitor for anomalous memory usage patterns or unexpected process terminations that may indicate an attempted exploitation of this heap corruption flaw. Regular vulnerability scanning and adherence to secure coding standards that mandate explicit bounds checking rather than reliance on debug-only assertions are essential preventive measures against similar classes of vulnerabilities in network-facing services.