CVE-2026-107910 in FalkorDB
Summary
by MITRE • 10/09/2026
An improper authentication vulnerability in the is_authenticated function (src/bolt/bolt_api.c) in FalkorDB before 4.20.0 allows a remote unauthenticated attacker to execute graph queries without credentials through the Bolt endpoint. The function decides whether a password is required by issuing an empty AUTH command to Redis and treats only a WRONGPASS error as meaning that a password is required; any other error, such as LOADING while a dataset is being loaded, MASTERDOWN during replication failover, or OOM under memory pressure, causes the client to be treated as authenticated. Only deployments that enable the Bolt endpoint (BOLT_PORT, disabled by default) are affected.
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 in FalkorDB versions prior to 4.20.0 represents a critical failure in access control mechanisms within the database management system's authentication logic. Specifically, the flaw resides in the is_authenticated function located in the source file src/bolt/bolt_api.c. This component serves as the gatekeeper for incoming connections via the Bolt protocol endpoint, which by default is disabled but can be enabled through configuration settings such as BOLT_PORT. When this endpoint is active, an attacker who has network reachability to the service can exploit a logic error that bypasses credential verification entirely. The core of the issue lies in how the system determines whether authentication is required for a given connection attempt. Instead of relying on explicit configuration flags or secure state checks, the function attempts to validate credentials by issuing an empty AUTH command to the underlying Redis engine and interpreting the response code to decide if further authentication steps are necessary.
The technical flaw stems from an overly permissive interpretation of error responses returned during this preliminary check. The implementation logic assumes that only a WRONGPASS error indicates that a password is required, implying that any other type of error suggests the connection does not need credentials or has already passed authentication checks. This assumption fails to account for transient system states and operational errors that are unrelated to credential validity. For instance, if the database engine is undergoing data loading operations, it may return a LOADING error. Similarly, during replication failover events, the system might report MASTERDOWN, and under conditions of severe memory pressure, an OOM (Out Of Memory) error could be generated. In all these scenarios, the flawed logic incorrectly classifies the client as authenticated because the returned error is not specifically WRONGPASS. This creates a significant security gap where operational noise or temporary infrastructure states are misinterpreted as permission to proceed without authentication.
The operational impact of this vulnerability is severe for any deployment that has enabled the Bolt endpoint. A remote, unauthenticated attacker can exploit this condition by sending carefully crafted requests during periods when these specific error conditions are triggered. Once the system erroneously treats the connection as authenticated, the attacker gains the ability to execute graph queries against the database without providing valid credentials. This effectively results in a complete bypass of authentication controls, allowing unauthorized access to sensitive data and potentially enabling malicious modifications or deletions within the graph structure. The severity is compounded by the fact that this behavior occurs during common operational events such as startup loading phases, failover transitions, or resource exhaustion scenarios, making it difficult for administrators to predict when the system might be vulnerable based on static configuration alone.
From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, specifically involving misinterpretation of authentication states due to error handling flaws. It also relates to CWE-491, Public Clone Error, in contexts where public or unauthenticated access is granted due to incorrect state management. In terms of the MITRE ATT&CK framework, this behavior facilitates Initial Access through exploitation of software vulnerabilities and can be categorized under Tactic TA0001, with techniques such as Valid Accounts if the attacker leverages existing but improperly validated sessions, though in this case it is more accurately described as Unauthenticated Access via Logic Flaw. The attack vector is remote over a network protocol, making it exploitable by threat actors who do not require prior access to the host system.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary and most effective mitigation is to upgrade FalkorDB to version 4.20.0 or later, where this logic error has been corrected to properly handle all non-WRONGPASS errors as requiring authentication until valid credentials are provided. For environments that cannot immediately patch the software, disabling the Bolt endpoint by ensuring BOLT_PORT remains unset or disabled is a critical temporary control measure. Additionally, administrators should implement network-level access controls such as firewalls or security groups to restrict inbound traffic on the Bolt port exclusively to trusted IP addresses and subnets. Monitoring logs for unusual patterns of LOADING, MASTERDOWN, or OOM errors combined with high volumes of query attempts can help detect potential exploitation in real-time. Future development practices should emphasize defensive programming techniques that treat all non-successful authentication responses as failures until explicitly verified otherwise, ensuring that transient system states do not compromise security boundaries.