CVE-2026-7826: FalkorDB Heap Buffer Over-Read DoS Vulnerability

CVE-2026-7826 Overview

CVE-2026-7826 is a heap-based out-of-bounds read [CWE-125] in the BufferSerializerIOv2_ReadBuffer function located in src/serializers/serializer_io.c of FalkorDB before version 4.18.4. A remote attacker who can issue Redis replication commands against a vulnerable instance can trigger the flaw by supplying a crafted RDB stream whose sub-buffer length field exceeds the remaining buffer size. The only bounds check in the vulnerable code is an ASSERT() macro, which is removed from release builds. As a result, memcpy() reads past the end of the heap allocation, enabling denial of service or disclosure of heap memory contents.

Critical Impact
Unauthenticated remote attackers who reach a FalkorDB instance with no password configured can crash the service or leak heap memory contents via crafted RDB replication streams.

Affected Products

FalkorDB versions prior to 4.18.4
Deployments exposing the Redis replication protocol without authentication
Any application embedding FalkorDB that accepts untrusted replication streams

Discovery Timeline

2026-10-09 - CVE-2026-7826 published to NVD
2026-10-15 - Last updated in NVD database

Technical Details for CVE-2026-7826

Vulnerability Analysis

FalkorDB is a graph database built as a Redis module. During replication, the server deserializes an RDB stream using the BufferSerializerIOv2_ReadBuffer function. This function reads a length-prefixed sub-buffer from an in-memory BufferedIO structure and copies the bytes using memcpy().

The pre-patch implementation relied on an ASSERT() to validate that the length field did not exceed the remaining buffer capacity. In release builds, assertions are compiled out, so the length value flows directly into memcpy() without any runtime check. An attacker who controls the sub-buffer length field can force the copy to read past the end of the heap allocation.

The read primitive provides two outcomes. First, reads that cross unmapped memory boundaries crash the FalkorDB process, resulting in denial of service. Second, successful out-of-bounds reads can expose adjacent heap data to the attacker through subsequent protocol responses.

Root Cause

The root cause is the use of debug-only assertions as a substitute for runtime input validation. Length values parsed from an attacker-controlled RDB stream were trusted implicitly in production builds, violating the principle of validating all external input.

Attack Vector

Exploitation requires network access to the Redis replication interface. Instances configured without requirepass or exposed to untrusted networks accept replication commands from any client. The attacker issues REPLICAOF or equivalent replication commands and streams a crafted RDB payload whose sub-buffer length field exceeds the available buffer size.

// Patch excerpt from src/serializers/serializer_io.c
// fix(serializer): add runtime bounds checks in BufferSerializerIOv2_ReadBuffer
	BufferedIO *buffer = (BufferedIO*) io ;

	ASSERT (buffer->count <= buffer->cap) ;

	// load buffer if depleted
	if (unlikely (buffer->count == buffer->cap)) {
		_load_buffer (buffer) ;
	}

	ASSERT (buffer->cap > 0) ;

	// ensure at least 1 byte available for the type field
	if (buffer->count >= buffer->cap) {
		RedisModule_Log (NULL, "warning",
			"BufferSerializer ReadBuffer: no bytes available for type field "
			"(count: %zu, cap: %zu)", buffer->count, buffer->cap) ;
		RedisModule_Assert (false) ;
	}

	// find the type
	uint8_t info_type ;

Source: FalkorDB commit 55d986f

The fix adds unconditional runtime checks that log a warning and abort via RedisModule_Assert(false) when insufficient bytes remain for the type field, preventing the out-of-bounds memcpy().

Detection Methods for CVE-2026-7826

Indicators of Compromise

Unexpected REPLICAOF or SLAVEOF commands directed at FalkorDB instances from unknown sources
FalkorDB process crashes or segmentation faults correlated with inbound replication traffic
Anomalous RDB stream payloads with sub-buffer length fields that exceed stream size

Detection Strategies

Inspect FalkorDB and Redis logs for abnormal termination of the replication thread or repeated restart cycles
Monitor network flows to TCP port 6379 (or configured Redis port) for replication commands originating outside the expected replica set
Deploy host-based identification for process crashes affecting the FalkorDB module within the Redis server

Monitoring Recommendations

Alert on connections to Redis replication ports from IP ranges not in an allowlist of authorized replicas
Baseline FalkorDB memory usage and crash counts, then alert on deviations
Capture Redis MONITOR output in a controlled environment to identify unauthorized replication command sequences

How to Mitigate CVE-2026-7826

Immediate Actions Required

Upgrade FalkorDB to version 4.18.4 or later, which contains the runtime bounds check in BufferSerializerIOv2_ReadBuffer
Configure requirepass on all FalkorDB and Redis instances to require authentication for replication commands
Restrict network access to the Redis port using firewall rules or network policies so that only trusted replicas can connect

Patch Information

The fix is included in FalkorDB Release v4.18.4 and merged via GitHub Pull Request #1972. The code change is available in commit 55d986f. The patch replaces the debug-only assertion with runtime checks that validate buffer capacity before every read and abort cleanly if insufficient bytes remain.

Workarounds

Set a strong requirepass value and enable aclfile-based access control to block unauthenticated replication commands
Bind FalkorDB to loopback or a private management interface using the bind directive in redis.conf
Use the rename-command directive to disable or rename REPLICAOF and SLAVEOF on instances that do not require replication

bash

# Example redis.conf hardening for FalkorDB
bind 127.0.0.1 10.0.0.5
requirepass <strong-random-secret>
rename-command REPLICAOF ""
rename-command SLAVEOF ""
protected-mode yes