Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-10-09T05:16:45.150Z",
  "pubdate": "2026-10-09T05:16:45.150Z",
  "executiveSummary": "A heap-based out-of-bounds (OOB) read vulnerability exists in FalkorDB versions prior to 4.18.4, specifically within the BufferSerializerIOv2_ReadBuffer function.\nThe vulnerability stems from insufficient bounds checking when processing RDB (Redis Database) streams, leading to a critical security flaw.\nAn unauthenticated remote attacker capable of issuing Redis replication commands can trigger this flaw by submitting a maliciously crafted RDB stream containing an invalid sub-buffer length field.\nSuccessful exploitation allows for a denial-of-service (DoS) condition or the unauthorized disclosure of sensitive heap memory, potentially exposing information residing in adjacent memory segments.\nThe risk is exacerbated by the use of an ASSERT() statement for safety checks, which is stripped during standard release builds, leaving the application without runtime protection against malformed input.\nThis vulnerability highlights a critical failure in input validation for binary protocol parsing, necessitating immediate attention to maintain the confidentiality and availability of the database instance.",
  "technicalDetails": "The vulnerability is located in the BufferSerializerIOv2_ReadBuffer function within src/serializers/serializer_io.c. The root cause of this heap-based out-of-bounds read is an improper validation mechanism for the length field associated with sub-buffers within an RDB stream.\nWhen the FalkorDB serialization component parses incoming RDB data, it reads a length field from the stream and uses it to perform a memory copy operation. The implementation relies on an ASSERT() macro to verify that the length provided in the stream does not exceed the size of the allocated heap buffer.\nIn production/release builds, the ASSERT() macro is optimized out by the compiler, effectively nullifying the only boundary check performed prior to the copy operation. Consequently, if an attacker provides a crafted sub-buffer length that exceeds the bounds of the actual heap allocation, the underlying memcpy() operation continues reading beyond the legitimate memory range.\nThe attack flow initiates when an attacker interacts with a FalkorDB instance through Redis replication commands. If the instance is misconfigured—such as lacking password authentication or having public network exposure—the attacker can initiate a replication handshake.\nDuring the replication process, the attacker injects a malformed RDB stream payload. The parser processes this input, reads the manipulated length field, and ignores the boundary check due to the lack of runtime enforcement. The memcpy() function then executes, reading memory starting from the end of the intended heap buffer into adjacent heap memory.\nThe impact of this read includes two primary outcomes. First, the memory read operation may access unmapped memory, resulting in an immediate segmentation fault and a subsequent denial-of-service. Second, if the memory is mapped but contains sensitive data, the attacker may be able to leak the contents of this adjacent memory via the response mechanisms used in the replication protocol or through other side channels that return serialized data to the client.\nThis vulnerability demonstrates a critical deficiency in handling externally supplied length fields. The absence of a persistent, production-ready boundary check turns a common parsing task into a vector for memory corruption and data leakage, particularly concerning when the system is exposed to potentially untrusted or partially authorized remote entities."
}