CVE-2026-107909: FalkorDB Heap-Based DoS Vulnerability

CVE-2026-107909 Overview

CVE-2026-107909 is a heap-based out-of-bounds write vulnerability [CWE-787] in FalkorDB versions before 4.20.0. The flaw resides in the ws_read_frame function in src/bolt/ws.c and the buffer_apply_mask function in src/bolt/buffer.c. A remote unauthenticated attacker can send a WebSocket frame with a 64-bit extended payload length to the Bolt port to trigger denial of service and potentially corrupt heap memory. The payload length is unbounded, and the only safety check in buffer_apply_mask is an ASSERT() that compiles out in release builds. Only deployments that explicitly enable the Bolt endpoint via BOLT_PORT are affected, as it is disabled by default.

Critical Impact
Unauthenticated remote attackers can corrupt heap memory and crash the FalkorDB process by sending a single malformed WebSocket frame to the Bolt port.

Affected Products

FalkorDB versions prior to 4.20.0
Deployments with the Bolt endpoint (BOLT_PORT) explicitly enabled
FalkorDB Bolt protocol WebSocket handler (src/bolt/ws.c, src/bolt/buffer.c)

Discovery Timeline

2026-10-09 - CVE-2026-107909 published to NVD
2026-10-15 - Last updated in NVD database

Technical Details for CVE-2026-107909

Vulnerability Analysis

FalkorDB implements the Neo4j Bolt protocol over WebSocket on an optional listening port. When a client sends a WebSocket frame, ws_read_frame parses the frame header and extracts the payload length. The protocol supports a 64-bit extended payload length field, which the implementation reads directly without clamping to the size of the receive buffer.

After length extraction, buffer_apply_mask performs the XOR unmasking step defined by RFC 6455. The function should validate that the declared payload length fits within the allocated buffer before writing. Instead, the sole check is an ASSERT() macro, which the compiler elides in release builds. The function then XORs attacker-controlled bytes against the mask key across memory beyond the end of the receive buffer, producing a controlled heap out-of-bounds write.

This primitive enables denial of service through heap corruption and may permit targeted modification of adjacent heap structures.

Root Cause

The root cause is missing bounds validation on an attacker-supplied length field combined with debug-only assertions that provide no protection in production. The buffer_apply_mask function trusts the WebSocket frame header length and iterates past the valid buffer region.

Attack Vector

An attacker establishes a TCP connection to the Bolt port and sends a WebSocket handshake. The attacker then transmits a WebSocket frame with a 64-bit extended payload length larger than the receive buffer and a chosen 4-byte mask key. The server reads the frame header, invokes buffer_apply_mask, and XORs memory beyond the buffer with the mask key. No authentication is required.

The upstream remediation removes the Bolt protocol support entirely rather than patching the parser.

// Patch excerpt: src/bolt/bolt_api.h removed in commit 0b11a00
-// listen to bolt port
-// add the socket to the event loop
-int BoltApi_Register
-(
-    RedisModuleCtx *ctx  // redis context
-);
-
-// free connected clients
-void BoltApi_Unregister
-(
-    void
-);
// Source: https://github.com/FalkorDB/FalkorDB/commit/0b11a00b34b25c4d4fdfe55f0a35c8a00593bd7d

Detection Methods for CVE-2026-107909

Indicators of Compromise

Unexpected FalkorDB process crashes or segmentation faults with stack traces referencing buffer_apply_mask or ws_read_frame.
Inbound TCP connections to the configured BOLT_PORT from untrusted networks.
WebSocket frames to the Bolt port containing a 64-bit extended payload length field exceeding reasonable message sizes.

Detection Strategies

Inspect FalkorDB configuration and container images to identify any deployment where BOLT_PORT is set.
Monitor process supervisor logs for repeated restarts of the FalkorDB or Redis module process.
Deploy network intrusion detection signatures that flag WebSocket frames with payload length values exceeding server buffer capacity on the Bolt port.

Monitoring Recommendations

Enable connection logging on the Bolt port and alert on connections from sources outside the expected application tier.
Track crash telemetry and core dumps for the FalkorDB process and correlate against inbound Bolt traffic timestamps.
Collect packet captures on the Bolt port in environments where the endpoint must remain reachable, retaining them for forensic review.

How to Mitigate CVE-2026-107909

Immediate Actions Required

Upgrade FalkorDB to version 4.20.0 or later, which removes the vulnerable Bolt protocol support.
Disable the Bolt endpoint by removing or unsetting the BOLT_PORT configuration variable on all FalkorDB instances pending upgrade.
Restrict network access to any exposed Bolt port using host firewalls or security groups to allow only trusted application hosts.

Patch Information

The upstream fix removes the Bolt protocol implementation from FalkorDB. Review the GitHub Pull Request #2170 and the GitHub Commit 0b11a00 for the full change set. Fixed binaries are available in the GitHub Release v4.20.0.

Workarounds

Do not enable BOLT_PORT; the Bolt endpoint is disabled by default and most deployments are unaffected.
Place a reverse proxy or WebSocket-aware gateway in front of FalkorDB that enforces maximum frame size limits.
Isolate FalkorDB instances on private network segments and require VPN or mTLS for client access.

bash

# Verify Bolt port is not configured in the FalkorDB module load line
grep -i 'BOLT_PORT' /etc/redis/redis.conf

# Confirm no process is listening on a Bolt port (default 7687)
ss -tlnp | grep -E ':7687|BOLT'

# Upgrade to patched version
docker pull falkordb/falkordb:v4.20.0