CVE-2026-88407 in FalkorDB
Summary
by MITRE • 09/22/2026
An out-of-bounds read in the node_token_count/relation_token_count component of FalkorDB (Redis module) v4.20.1 to v4.20.4 allows attackers to cause a Denial of Service (DoS) via a crafted input.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified as an out-of-bounds read within the node_token_count and relation_token_count components of FalkorDB, specifically affecting versions 4.20.1 through 4.20.4, represents a critical memory safety flaw in this Redis-compatible graph database module. This issue arises from improper validation or boundary checking when processing token counts associated with nodes and relations within the graph structure. In C-based systems like FalkorDB, which is built upon the Redis architecture, such errors typically occur during the parsing or internal representation of graph elements where the software fails to verify that a requested memory access falls within the allocated bounds for the respective data structures. When an attacker supplies crafted input containing malformed token counts, the application attempts to read from invalid memory addresses rather than handling the error gracefully or rejecting the request. This behavior is characteristic of CWE-125, which defines out-of-bounds read vulnerabilities where a program reads data past the end of a buffer or array.
The operational impact of this vulnerability is primarily centered on service availability and system stability. Because the flaw triggers an invalid memory access, it typically results in a segmentation fault or similar critical error that causes the FalkorDB process to crash immediately upon processing the malicious request. This leads directly to a Denial of Service condition where legitimate users are unable to interact with the graph database until the service is manually restarted. Unlike vulnerabilities that allow for arbitrary code execution, this specific flaw does not appear to provide direct control over program flow or memory contents in a way that facilitates remote code execution, but its ability to reliably crash the server makes it highly disruptive for production environments relying on continuous availability of graph data services. The attacker requires only the ability to send network requests to the FalkorDB instance, making this a remotely exploitable vulnerability if the service is exposed without adequate access controls.
From a threat intelligence perspective, this exploitation aligns with ATT&CK technique T1499, Endpoint Denial of Service, specifically under the sub-technique for resource exhaustion via application crashes or loops. The attack vector involves sending specially crafted network packets that trigger the memory violation within the database engine. While the immediate effect is a crash, repeated attempts could lead to significant downtime and potential data loss if automatic restart mechanisms are not configured with proper safeguards against rapid successive failures. Furthermore, in some contexts, out-of-bounds reads can leak sensitive information from adjacent memory locations, although the primary reported impact here is denial of service. The lack of robust input validation on token counts indicates a gap in the security development lifecycle for these specific versions, highlighting the need for stricter boundary checks during graph element parsing.
Mitigation strategies should focus primarily on upgrading to patched versions of FalkorDB where this issue has been resolved by implementing proper bounds checking before accessing memory associated with node and relation tokens. Until an upgrade is feasible, administrators can implement network-level controls such as firewall rules or Web Application Firewalls that inspect incoming requests for patterns indicative of malformed token counts or abnormal graph structure inputs. Rate limiting on the FalkorDB port can also help mitigate the impact by preventing rapid successive crash attempts from overwhelming system resources during recovery periods. Additionally, enabling core dump analysis and monitoring logs for segmentation faults can aid in early detection of exploitation attempts. It is crucial to treat this vulnerability with high priority due to its remote exploitability and direct impact on service availability, ensuring that all instances running versions 4.20.1 through 4.20.4 are updated or isolated from untrusted networks immediately.