CVE-2026-5759 in FalkorDB
Summary
by MITRE • 10/09/2026
A double free and use-after-free vulnerability in the RdbLoadDeletedNodes function of the RDB graph decoders (src/serializers/decoders/*/decode_graph_entities.c) in FalkorDB before 4.18.1 allows a remote attacker who can issue Redis replication commands (for example, against an instance with no password configured) to cause a denial of service or execute arbitrary code in the redis-server process by supplying a crafted RDB stream whose deleted-nodes buffer length is not a multiple of sizeof(NodeID). The length check relies on ASSERT(), which is compiled out in release builds, so the function continues after freeing the buffer, reading it and freeing it a second time.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in FalkorDB versions prior to 4.18.1 represents a critical memory management flaw within the RDB graph decoders, specifically located in the RdbLoadDeletedNodes function found in the source files under src/serializers/decoders/*/decode_graph_entities.c. This issue stems from an improper handling of buffer lengths during the deserialization process for Redis replication streams. The core technical defect involves a double free and use-after-free condition that arises when processing crafted RDB data where the deleted-nodes buffer length is not aligned to a multiple of sizeof(NodeID). In such scenarios, the application fails to properly validate input constraints before proceeding with memory operations, leading to severe instability within the redis-server process.
The operational mechanism of this exploit relies on the reliance of the vulnerability's trigger condition on an ASSERT() macro for validation checks. While assertions are useful during development and testing phases to catch logical errors early, they are typically compiled out in release builds to optimize performance and reduce binary size. Consequently, when FalkorDB is deployed in production environments using standard release binaries, this critical length check is absent. An attacker who can issue Redis replication commands against an instance that lacks authentication protection or has weak credentials can supply a specially crafted RDB stream. By manipulating the deleted-nodes buffer length to be misaligned with the expected NodeID size structure, the application proceeds past the point where validation should have occurred, allowing malicious data structures to influence memory allocation and deallocation routines incorrectly.
The impact of this vulnerability is severe, encompassing both denial of service and potential remote code execution. The double free condition occurs because the function frees a buffer that has already been freed or attempts to access memory after it has been released by another part of the system logic triggered by the malformed input. This use-after-free scenario allows an attacker to corrupt heap metadata or overwrite adjacent data structures in memory. Such corruption can lead to immediate crashes, resulting in a denial of service for all users relying on the database instance. More critically, if the memory layout permits it, the attacker may achieve arbitrary code execution by controlling the contents of the freed memory region before it is reallocated and used by the application logic. This transforms a simple data processing error into a high-severity security breach capable of compromising the entire server infrastructure hosting the Redis service.
From a classification perspective, this vulnerability aligns with CWE-415 Double Free, which describes errors where an object is freed more than once, potentially leading to heap corruption and arbitrary code execution. It also maps closely to CWE-416 Use After Free, as the application continues to reference memory that has been returned to the system or reused for other purposes. In terms of attack vectors, this falls under ATT&CK technique T1059 Command and Scripting Interpreter if the attacker leverages the execution environment further, but primarily it represents a remote code execution vector via input validation failure (CWE-20) combined with memory safety violations. The requirement for replication access indicates that the initial attack surface is limited to authenticated or unauthenticated network-accessible instances, highlighting the importance of securing Redis endpoints against unauthorized replication requests.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements. The primary remediation is to upgrade FalkorDB to version 4.18.1 or later, where this specific validation logic has been corrected to ensure that buffer lengths are properly checked regardless of build configuration. For environments unable to immediately update, implementing network-level access controls such as firewalls to restrict replication traffic to trusted IP addresses only can significantly reduce the attack surface. Additionally, enforcing strong authentication on all Redis instances is essential to prevent unauthorized actors from issuing replication commands in the first place. Developers should also review other areas of the codebase that rely on ASSERT() for security-critical validations and replace them with explicit conditional checks that remain active in release builds to ensure consistent behavior across development and production environments.