Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-10-09T06:17:10.777Z",
  "pubdate": "2026-10-09T06:17:10.777Z",
  "executiveSummary": "A critical heap-based out-of-bounds (OOB) write vulnerability exists in FalkorDB versions prior to 4.20.0 within the Bolt protocol handler. This vulnerability is triggered when the Bolt endpoint is explicitly enabled, allowing an unauthenticated remote attacker to perform unauthorized memory operations.\nThe flaw stems from insufficient input validation in the BoltReadHandler function, where the system relies on ASSERT() macros that are omitted in production release builds. By sending a maliciously crafted Bolt RESET message with a specific chunk size, an attacker can influence pointer arithmetic to write buffered data outside the intended heap buffer boundaries.\nThe potential impact includes a denial-of-service (DoS) condition due to memory corruption or the execution of arbitrary code with the privileges of the database process. Because the attack vector is network-reachable for deployments with the Bolt port exposed, this poses a significant risk to data integrity and system availability. Successful exploitation requires no authentication, making the vulnerability particularly dangerous in environments where the Bolt port is accessible to external or untrusted internal networks.",
  "technicalDetails": "The vulnerability is located within the BoltReadHandler function in src/bolt/bolt_api.c. The root cause is an improper reliance on C-preprocessor ASSERT() statements to validate the size of data chunks provided via the Bolt protocol. In production environments, these assertions are compiled out, leaving the application without runtime bounds checking on the 16-bit size values provided by the client.\nDuring the processing of a Bolt RESET message, the application receives a user-supplied chunk size. The handler utilizes this wire-supplied value to compute a destination memory address for a data move operation. Because the size is not properly sanitized, the computation can result in a pointer offset that resides prior to the base address of the allocated heap buffer.\nThe attack flow proceeds as follows: First, the attacker establishes a connection to the Bolt endpoint (BOLT_PORT). Second, the attacker transmits a specially crafted Bolt RESET packet containing a malicious chunk size field. Third, the application's handler, lacking the defensive validation originally intended for the development phase, proceeds to execute a memory copy operation using the attacker-supplied size. This operation performs a heap-based OOB write, enabling the attacker to overwrite memory segments preceding the read buffer by up to approximately 64 KiB.\nExploitation allows for the corruption of heap metadata, function pointers, or application-specific objects residing in the memory adjacent to the buffer. If an attacker successfully overwrites critical control-flow structures, they may achieve arbitrary code execution. If the memory corruption targets non-critical data or leads to immediate segmentation faults, it results in a denial-of-service.\nThe vulnerability affects FalkorDB prior to version 4.20.0. It is contingent upon the configuration of the Bolt port (BOLT_PORT), which is disabled by default. If enabled, the system is exposed to remote, unauthenticated attackers who can craft protocol messages to trigger the invalid memory reference. This is a classic case of unsafe pointer arithmetic exacerbated by the failure to implement rigorous input validation outside of debug-only assertions."
}