CVE-2026-5759: FalkorDB Double-Free in RDB Decoder Enables Remote Code Execution

Overview

A critical memory-corruption flaw has been disclosed in FalkorDB, the open-source graph database built as a Redis module and positioned as a successor to the now end-of-life RedisGraph. Tracked as CVE-2026-5759 with a CVSS 3.1 score of 9.8 (Critical), the bug is a double-free and use-after-free in the RDB decoder path that a remote, unauthenticated attacker can trigger simply by replaying a crafted replication stream at an exposed instance.

FalkorDB is widely deployed as the storage layer for GraphRAG and knowledge-graph workloads in generative-AI and agentic applications, as well as for fraud detection and recommendation engines — meaning this flaw sits directly in the data path of a growing number of AI infrastructure stacks.

Technical Details

How It Works

FalkorDB persists and replicates graph state using Redis's RDB format, extended with custom decoders for graph-specific entities. The RdbLoadDeletedNodes function reads a buffer of deleted-node identifiers from the incoming RDB stream and expects its length to be an exact multiple of sizeof(NodeID).

That expectation was enforced only by an ASSERT() call — a macro that compiles to a no-op in release builds. When a release build of FalkorDB receives a crafted RDB stream whose deleted-nodes buffer length is not a multiple of sizeof(NodeID), the length check silently passes, and execution continues past the point where the buffer has already been freed. The function then reads from and frees the buffer a second time, corrupting the heap.

Because FalkorDB runs as a loaded module inside the redis-server process, a successful double-free/UAF chain can be leveraged for denial of service at minimum, and potentially arbitrary code execution within redis-server with sufficient heap-grooming effort.

Attack Path

An attacker does not need valid credentials — they need only the ability to issue Redis replication protocol commands against the target. This is trivially achievable against any instance running with no password configured (a common default/misconfiguration for internal or containerized Redis/FalkorDB deployments), or against any instance reachable on the replication port without network-level restrictions.

Impact Assessment

Who Is At Risk

• Self-hosted FalkorDB deployments on versions earlier than 4.18.1
• Instances with no requirepass/AUTH configured, especially those exposed on internal Docker/Kubernetes networks that are assumed — incorrectly — to be "trusted"
• GraphRAG, agentic-AI, and knowledge-graph backends where FalkorDB is reachable from application tiers without strict network segmentation

Potential Consequences

1. Denial of Service — A single malformed RDB stream can crash the redis-server process hosting the graph data, interrupting every application depending on it.
2. Remote Code Execution — The double-free/UAF primitive gives an attacker control over heap metadata, which is a well-understood (if non-trivial) path to code execution inside the Redis process.
3. Blast Radius via Replication — Because the trigger rides on the replication protocol, any topology where FalkorDB instances replicate from an attacker-reachable source inherits the risk.

Mitigation

Immediate Actions

• Upgrade to FalkorDB 4.18.1 or later, which fixes the missing bounds validation (merged via PR #1843).
• Enable Redis AUTH (requirepass) on every FalkorDB instance — do not rely on network placement alone.
• Restrict network exposure of the replication port to only trusted replica/primary pairs via firewall rules or security groups.

Detection Opportunities

• Monitor for unexpected redis-server crashes or restarts correlating with inbound replication-protocol traffic from unfamiliar sources.
• Audit which hosts are permitted to reach FalkorDB's Redis port, particularly in multi-tenant or shared-cluster environments.

Defence-in-Depth

• Treat every data-layer service — including "internal-only" graph/vector databases backing AI pipelines — as requiring the same authentication rigor as internet-facing services.
• Keep release-build assumptions honest: ASSERT()-only bounds checks are stripped in production builds across many C/C++ codebases, not just FalkorDB's — this class of bug is worth hunting for in any self-hosted data infrastructure your team maintains.

Disclosure Timeline

The issue was reported to the FalkorDB maintainers on April 7, 2026, with a fix merged on April 10, 2026 and shipped in v4.18.1 on April 12, 2026. As of publication, no GitHub Security Advisory (GHSA) has been published for this CVE, and no public proof-of-concept exploit is known to be circulating — but the unauthenticated, network-reachable trigger path warrants prompt patching.

References

• NVD — CVE-2026-5759
• FalkorDB GitHub Repository
• VulDB — CVE-2026-5759