Summary
FalkorDB contains an improper authentication flaw in the Bolt endpoint that can cause unauthenticated clients to be treated as authenticated when Redis returns certain errors. An attacker may then execute graph queries without valid credentials when the Bolt endpoint is enabled and the underlying Redis state produces a non-WRONGPASS error.
FalkorDB contains an improper authentication flaw in the Bolt endpoint that can cause unauthenticated clients to be treated as authenticated when Redis returns certain errors. An attacker may then execute graph queries without valid credentials when the Bolt endpoint is enabled and the underlying Redis state produces a non-WRONGPASS error.
Affected context
The vulnerability occurs in FalkorDB deployments that enable the Bolt endpoint through BOLT_PORT, which is disabled by default. The affected authentication decision relies on an empty Redis AUTH request and can be influenced by operational states such as dataset loading, replication failover, or memory pressure.
The vulnerability occurs in FalkorDB deployments that enable the Bolt endpoint through BOLT_PORT, which is disabled by default. The affected authentication decision relies on an empty Redis AUTH request and can be influenced by operational states such as dataset loading, replication failover, or memory pressure.
Exploit preconditions
- Attack surface: The remotely reachable FalkorDB Bolt endpoint
- Required access: Network access to an enabled Bolt endpoint; valid credentials are not required
- Trigger point: Authentication handling in
is_authenticatedwithinsrc/bolt/bolt_api.c - Why exploitation is possible: Errors other than
WRONGPASSmay be interpreted as evidence that authentication is unnecessary, allowing the client to proceed as authenticated
- Attack surface: The remotely reachable FalkorDB Bolt endpoint
- Required access: Network access to an enabled Bolt endpoint; valid credentials are not required
- Trigger point: Authentication handling in
is_authenticatedwithinsrc/bolt/bolt_api.c - Why exploitation is possible: Errors other than
WRONGPASSmay be interpreted as evidence that authentication is unnecessary, allowing the client to proceed as authenticated
Why this happens
The authentication logic uses an error-specific check to determine whether a password is required. It recognizes only WRONGPASS as an authentication failure and treats other Redis errors as successful authentication conditions. This fail-open behavior maps to CWE-287, Improper Authentication, because an operational error is incorrectly converted into proof of identity.
The authentication logic uses an error-specific check to determine whether a password is required. It recognizes only WRONGPASS as an authentication failure and treats other Redis errors as successful authentication conditions. This fail-open behavior maps to CWE-287, Improper Authentication, because an operational error is incorrectly converted into proof of identity.
Potential impact
- An unauthenticated attacker may execute graph queries
- Sensitive graph data could be disclosed
- Data may be modified, deleted, or otherwise manipulated through permitted query operations
- Application integrity and downstream decisions could be affected
- Availability may be impacted if unauthorized queries consume substantial resources
- An unauthenticated attacker may execute graph queries
- Sensitive graph data could be disclosed
- Data may be modified, deleted, or otherwise manipulated through permitted query operations
- Application integrity and downstream decisions could be affected
- Availability may be impacted if unauthorized queries consume substantial resources
General mitigation guidance
Mitigation generally centers on fail-closed authentication and reducing
exposure of optional administrative or database interfaces.
Common defensive patterns include:
- Treating all authentication errors and ambiguous backend responses as authentication failures
- Separating credential validation from availability, loading, replication, and resource-state errors
- Keeping the Bolt endpoint disabled unless it is explicitly required
- Restricting enabled Bolt endpoints with network policy, segmentation, and authenticated gateways
- Applying least privilege to database users and limiting query capabilities
- Avoiding unauthenticated fallback behavior in security decision paths
- Recording authentication outcomes and backend errors without exposing sensitive details
Mitigation generally centers on fail-closed authentication and reducing
exposure of optional administrative or database interfaces.
Common defensive patterns include:
- Treating all authentication errors and ambiguous backend responses as authentication failures
- Separating credential validation from availability, loading, replication, and resource-state errors
- Keeping the Bolt endpoint disabled unless it is explicitly required
- Restricting enabled Bolt endpoints with network policy, segmentation, and authenticated gateways
- Applying least privilege to database users and limiting query capabilities
- Avoiding unauthenticated fallback behavior in security decision paths
- Recording authentication outcomes and backend errors without exposing sensitive details
How teams detect issues like this
Detection approaches may include:
- Static analysis for authentication branches that treat unexpected errors as success
- Code review checks for fail-open logic and boolean decisions based on incomplete error comparisons
- Tests that exercise loading, failover, unavailable-service, and resource-exhaustion states during authentication
- Monitoring for graph queries from unauthenticated clients or unexpected source networks
- Policy enforcement requiring authentication and network controls for every enabled Bolt endpoint
- Automated security review tools that flag improper authentication and error-handling patterns
Detection approaches may include:
- Static analysis for authentication branches that treat unexpected errors as success
- Code review checks for fail-open logic and boolean decisions based on incomplete error comparisons
- Tests that exercise loading, failover, unavailable-service, and resource-exhaustion states during authentication
- Monitoring for graph queries from unauthenticated clients or unexpected source networks
- Policy enforcement requiring authentication and network controls for every enabled Bolt endpoint
- Automated security review tools that flag improper authentication and error-handling patterns
