CVE-2026-7826 in FalkorDB
Summary
by MITRE • 10/09/2026
A heap-based out-of-bounds read in the BufferSerializerIOv2_ReadBuffer function (src/serializers/serializer_io.c) in FalkorDB before 4.18.4 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 disclose heap memory by supplying a crafted RDB stream whose sub-buffer length field exceeds the remaining buffer size. The only bounds check is an ASSERT(), which is compiled out in release builds, so memcpy() reads past the end of the heap allocation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified as CVE-2024-something involves a critical memory safety flaw within the FalkorDB database engine, specifically located in the BufferSerializerIOv2_ReadBuffer function found in the source file src/serializers/serializer_io.c. This issue manifests as a heap-based out-of-bounds read, which poses significant risks to system integrity and confidentiality. The root cause of this vulnerability lies in insufficient validation of input data during the deserialization process for Redis replication streams. When FalkorDB processes an RDB stream, it relies on length fields provided by the sender to determine how much data to copy into a buffer. In versions prior to 4.18.4, the implementation fails to rigorously verify that the specified sub-buffer length does not exceed the actual remaining size of the allocated heap memory. This lack of strict boundary checking allows an attacker to craft malicious RDB streams where the declared length is artificially inflated beyond the bounds of the available buffer space.
The operational impact of this vulnerability is severe, primarily enabling two distinct attack vectors: denial of service and information disclosure. Because the only existing safeguard against out-of-bounds access was an ASSERT macro, which is typically stripped out during compilation for release builds to optimize performance, the application proceeds with a standard memcpy operation even when the input data is malformed. This results in reading memory locations that lie outside the intended allocation boundaries. If this erroneous read triggers a segmentation fault or causes undefined behavior within the database engine, it leads directly to a denial of service by crashing the server process and disrupting availability for legitimate users. Alternatively, if the out-of-bounds read successfully retrieves data without immediately crashing the application, it can lead to heap memory disclosure. This allows an attacker to extract sensitive information stored in adjacent memory regions, potentially including other user data, authentication tokens, or internal system states, thereby compromising confidentiality.
From a technical perspective, this vulnerability aligns with CWE-125, which describes out-of-bounds read errors where software reads past the end of a buffer. The exploitation scenario requires specific conditions to be met by an attacker. Specifically, the target instance must allow remote replication commands, and ideally, it should not have password authentication enabled or otherwise lack strong access controls for these administrative operations. This highlights the importance of network segmentation and strict access control policies in database deployments. An attacker who can establish a connection and issue Redis replication commands can send the crafted RDB stream to trigger this flaw. The attack leverages the trust placed in incoming data streams by the serializer component, exploiting the assumption that input lengths are always valid relative to buffer capacities.
To mitigate this risk, organizations running FalkorDB must immediately upgrade to version 4.18.4 or later, where these bounds checking mechanisms have been corrected and hardened against such exploitation attempts. For environments where upgrading is not immediately feasible, defensive measures should include restricting network access to replication ports using firewalls or security groups to ensure that only trusted hosts can initiate replication streams. Additionally, enforcing strong authentication for all Redis commands, including those related to replication, significantly reduces the attack surface by preventing unauthorized actors from sending crafted payloads. Monitoring logs for unusual patterns in RDB stream processing and implementing intrusion detection systems capable of identifying malformed serialization data can also provide an additional layer of defense against exploitation attempts targeting this specific vulnerability.