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
| Field | Value |
|---|---|
| CVE ID | CVE-2026-107909 |
| Severity | Critical (CVSS 3.1: 9.1, CVSS 4.0: ~8.8) |
| CWE | CWE-787 (Out-of-Bounds Write) |
| Attack Vector | Network |
| Authentication | None Required |
| Affected Components | ws_read_frame (src/bolt/ws.c) and buffer_apply_mask (src/bolt/buffer.c) |
| Affected Versions | FalkorDB before 4.20.0, with the Bolt endpoint enabled |
| Fixed Version | 4.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
- Denial of Service — A single oversized WebSocket frame can crash the FalkorDB process.
- 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
- NVD — CVE-2026-107909
- FalkorDB GitHub Repository
- FalkorDB Bolt Support Documentation
- VulDB — CVE-2026-107909