SECURITYCRITICALCVE-2026-107909

CVE-2026-107909: Heap Out-of-Bounds Write in FalkorDB's WebSocket Bolt Transport

A crafted WebSocket frame with an oversized payload length corrupts heap memory in FalkorDB's Bolt endpoint, risking DoS and RCE.

Dylan H.

Security Team

October 9, 2026
4 min read
CVE-2026-107909: Heap Out-of-Bounds Write in FalkorDB's WebSocket Bolt Transport

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • FalkorDB before 4.20.0 (with Bolt protocol enabled)

Overview

CVE-2026-107909 is the second of two heap-corruption vulnerabilities disclosed together in FalkorDB's Bolt protocol implementation, rated CVSS 3.1 9.1 (Critical). Where its companion flaw, CVE-2026-107908, targets Bolt's RESET-message handling directly, this one hits the WebSocket transport that carries Bolt traffic — and like that flaw, it requires no authentication whatsoever.

Both were fixed the same way: FalkorDB's maintainers removed Bolt protocol support entirely in version 4.20.0 rather than attempt to patch the parser in place.


Technical Details

FieldValue
CVE IDCVE-2026-107909
SeverityCritical (CVSS 3.1: 9.1, CVSS 4.0: ~8.8)
CWECWE-787 (Out-of-Bounds Write)
Attack VectorNetwork
AuthenticationNone Required
Affected Componentsws_read_frame (src/bolt/ws.c) and buffer_apply_mask (src/bolt/buffer.c)
Affected VersionsFalkorDB before 4.20.0, with the Bolt endpoint enabled
Fixed Version4.20.0 (Bolt protocol removed)

How It Works

FalkorDB's Bolt endpoint can accept connections over WebSocket framing in addition to raw TCP. ws_read_frame parses incoming WebSocket frames, including a variant that declares its payload length via a 64-bit extended length field per the WebSocket spec. That length value was accepted without any upper-bound validation.

The frame is then handed to buffer_apply_mask, which XOR-decodes the WebSocket payload against the client-supplied masking key — writing the unmasked bytes back into the buffer for the length the attacker declared. Because that length was never validated against the actual allocated buffer size, an attacker-controlled 64-bit length causes buffer_apply_mask to XOR and write well beyond the end of the receive buffer, corrupting adjacent heap memory. The underlying root cause is the now-familiar pattern across FalkorDB's 2026 disclosures: a bounds check expressed only as a compiled-out ASSERT().

Important Caveat

Exploitation requires the target to have the Bolt endpoint enabled — it ships disabled by default and FalkorDB's own documentation labels it "experimental, not recommended for production." Deployments that enabled it purely for Neo4j-driver compatibility during a migration are the ones at risk, and for them the lack of any authentication requirement means the only barrier is network reachability.


Impact Assessment

Who Is At Risk

  • FalkorDB instances with Bolt protocol enabled over WebSocket transport, running a version earlier than 4.20.0
  • Any such instance reachable from an untrusted network segment

Potential Consequences

  1. Denial of Service — A single oversized WebSocket frame can crash the FalkorDB process.
  2. Heap Memory Corruption / Possible RCE — The masking XOR write gives an attacker fine-grained control over what gets written past the buffer boundary, which in principle extends to code execution, though public sources have not confirmed a working RCE exploit chain for this specific bug.

This CVE was disclosed alongside CVE-2026-107908 (Bolt RESET-message overflow) and two further Bolt-related issues from the same batch: an authentication bypass (CVE-2026-107910, CVSS 8.1) and a type-confusion flaw (CVE-2026-107911, CVSS 7.5) — all resolved by the same 4.20.0 release.


Mitigation

Immediate Actions

  • Upgrade to FalkorDB 4.20.0 or later, which removes the Bolt protocol implementation entirely (PR #2170), closing this and the related Bolt-transport bugs at the root.
  • If immediate upgrade isn't possible, disable the Bolt listener or restrict its port to trusted hosts only — there is no in-protocol fix available for earlier versions.

Detection Opportunities

  • Identify any FalkorDB deployment with the Bolt/WebSocket listener active and audit its network exposure.
  • Watch for process crashes correlating with WebSocket traffic on the Bolt port.

Defence-in-Depth

  • Where legacy Neo4j-driver compatibility is no longer needed post-migration, remove the dependency on Bolt entirely rather than leaving an experimental feature enabled "just in case."

Disclosure Timeline

Reported June 29, 2026; embargo ended September 27, 2026; CVE published October 9, 2026 — the fix had already shipped on July 13, 2026 as part of FalkorDB 4.20.0. No GitHub Security Advisory (GHSA) has been published for this CVE.


References