CVE-2026-107908: Unauthenticated Heap Overflow in FalkorDB's Bolt Protocol

Overview

FalkorDB has disclosed CVE-2026-107908, a CVSS 3.1 9.8 (Critical) heap-based out-of-bounds write affecting the database's experimental Bolt protocol endpoint — the compatibility layer that lets Neo4j client drivers talk to FalkorDB. Unlike the replication-stream bugs disclosed earlier in 2026 (CVE-2026-5759, CVE-2026-7826), this flaw requires no authentication of any kind: any network client able to reach the Bolt port can trigger it directly.

The maintainers' response was unusually decisive — rather than patch the vulnerable parser, FalkorDB removed Bolt protocol support entirely in the fixing release.

Technical Details

How It Works

FalkorDB's Bolt support — introduced as an experimental feature back in v4.0.0-a1 to ease migration from Neo4j — exposes a separate listener (conventionally on port 7687) speaking Neo4j's binary Bolt wire protocol. BoltReadHandler processes a Bolt RESET message that carries an attacker-chosen 16-bit chunk-size field.

As with the other FalkorDB deserialization bugs disclosed this year, the only bounds validation on that chunk size was an ASSERT() — stripped from release builds. By supplying an oversized chunk-size value, a remote and completely unauthenticated attacker causes the handler to compute a destination pointer from the wire-supplied size and write or move buffered data up to roughly 64KiB before the start of the intended read buffer, corrupting adjacent heap memory.

This is not merely a crash primitive: a sufficiently large, controlled out-of-bounds write of this kind is a classic building block for arbitrary code execution.

Important Caveat

FalkorDB's documentation explicitly describes Bolt support as "experimental, not recommended for production," and the endpoint is disabled by default. The flaw is only reachable on deployments that have explicitly enabled the Bolt listener — but any deployment that did so for Neo4j-driver compatibility is directly exposed, with no authentication barrier at all.

Impact Assessment

Who Is At Risk

• FalkorDB instances with Bolt protocol explicitly enabled for Neo4j client/tooling compatibility, running a version earlier than 4.20.0
• Any such deployment reachable from an untrusted network — given the complete lack of authentication, "reachable" is the only precondition

Potential Consequences

1. Denial of Service — A single crafted RESET message can crash the hosting process.
2. Remote Code Execution — The controllable out-of-bounds write primitive provides an attacker a credible path to code execution inside the FalkorDB/Redis process, without ever needing credentials.

A closely related flaw, CVE-2026-107909, affects the WebSocket transport for the same Bolt endpoint and was disclosed and fixed alongside this one. Two additional Bolt-related issues from the same disclosure batch — an authentication bypass (CVE-2026-107910) and a type-confusion bug (CVE-2026-107911) — were also addressed in 4.20.0.

Mitigation

Immediate Actions

• Upgrade to FalkorDB 4.20.0 or later. The fix removes the Bolt protocol implementation entirely (merged via PR #2170), eliminating the vulnerable code path rather than patching around it.
• If you cannot upgrade immediately, disable the Bolt listener and/or firewall its port (commonly 7687) from all but fully trusted hosts — there is no partial in-protocol mitigation for versions before 4.20.0.
• Confirm whether your deployment ever enabled Bolt for Neo4j-driver migration purposes; if that migration is complete, there is no reason to re-enable it after upgrading.

Detection Opportunities

• Audit which FalkorDB instances have the Bolt port open and to which network segments.
• Monitor for unexpected crashes or restarts of the FalkorDB/Redis process correlating with traffic on the Bolt port.

Defence-in-Depth

• Treat experimental, non-default features — especially ones explicitly flagged "not recommended for production" by the vendor — as higher-risk surface area deserving extra scrutiny or outright avoidance unless there's a concrete migration need.

Disclosure Timeline

Reported to FalkorDB on June 29, 2026; the disclosure embargo ended September 27, 2026; the CVE was published October 9, 2026, alongside the 4.20.0 release (which had already shipped July 13, 2026, removing the vulnerable code ahead of public disclosure). No GitHub Security Advisory (GHSA) has been published for this CVE.

References

• NVD — CVE-2026-107908
• FalkorDB GitHub Repository
• FalkorDB Bolt Support Documentation
• VulDB — CVE-2026-107908

Related Reading

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