Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-10-09T06:17:12.303Z",
  "pubdate": "2026-10-09T06:17:12.303Z",
  "executiveSummary": "A heap-based out-of-bounds write vulnerability exists in the WebSocket frame handling implementation of FalkorDB versions prior to 4.20.0. The flaw resides within the Bolt protocol processing logic, specifically triggered when the system parses incoming WebSocket frames containing 64-bit extended payload lengths.\nThe vulnerability is characterized by a failure to perform adequate input validation on payload length fields. Because the critical bounds check relies solely on an ASSERT() statement, which is removed during release build compilation, the system is susceptible to memory corruption. An unauthenticated remote attacker can exploit this by crafting malicious WebSocket frames sent to the Bolt port, provided the service has been explicitly enabled via BOLT_PORT.\nSuccessful exploitation allows for arbitrary heap memory modification, leading to service denial of service or potential remote code execution through heap grooming. Since the Bolt endpoint is disabled by default, the risk is concentrated in deployments where this feature has been manually activated. Security teams should prioritize patching to version 4.20.0 or higher to ensure the implementation of robust, production-level bounds checking.",
  "technicalDetails": "The vulnerability originates in the interaction between ws_read_frame (src/bolt/ws.c) and buffer_apply_mask (src/bolt/buffer.c). The ws_read_frame function is responsible for parsing WebSocket frames, including those specifying a 64-bit extended payload length. The root cause is an insufficient validation of the length parameter relative to the allocated buffer size in the heap.\nWhen a frame is received with a 64-bit payload length, the buffer_apply_mask function attempts to XOR the incoming data with a provided mask key. The logic within this function employs an ASSERT() to verify buffer boundaries. In production (release) builds, the C preprocessor strips these assertions entirely, leaving the pointer arithmetic unchecked. Consequently, if an attacker specifies a payload length exceeding the actual allocated buffer size, the pointer offset in buffer_apply_mask will move beyond the intended memory region.\nThe attack flow proceeds as follows: First, the attacker initiates a connection to the Bolt port. Second, the attacker transmits a crafted WebSocket frame where the payload length header is set to an arbitrary 64-bit value that significantly exceeds the capacity of the allocated receive buffer. Third, the ws_read_frame function processes the header and passes control to buffer_apply_mask without verifying that the total length falls within the allocated heap segment.\nAs buffer_apply_mask executes the XOR operation, it performs an out-of-bounds write to adjacent heap memory locations. Because the attacker provides the mask key, they exert influence over the specific bits being XORed into the memory regions adjacent to the target buffer. This capability facilitates the corruption of heap metadata (such as chunk headers or pointers), which can be leveraged to divert program control flow. The impact is significant: besides immediate service instability resulting in a crash (DoS), the memory corruption primitives can be chained to achieve remote code execution, depending on the heap layout and the proximity of sensitive structures.\nThis vulnerability affects FalkorDB versions prior to 4.20.0. It requires no authentication and is remotely exploitable over the network, contingent upon the BOLT_PORT being active. The lack of runtime bounds checking in release builds makes this a critical security flaw for any deployment utilizing the Bolt endpoint."
}