CVE-2026-107909: Pre-authentication heap out-of-bounds write in FalkorDB Bolt WebSocket frame handling via unbounded payload length
A heap-based out-of-bounds write in the wsreadframe function (src/bolt/ws.c) and the bufferapplymask function (src/bolt/buffer.c) in FalkorDB before 4.20.0 allows a remote unauthenticated attacker to cause a denial of service and possibly corrupt heap memory by sending a WebSocket frame with a 64-bit extended payload length to the Bolt port. The payload length is not bounded, and the only bounds check in bufferapplymask is an ASSERT(), which is compiled out in release builds, so the function XORs memory beyond the end of the receive buffer with the attacker-supplied mask key. Only deployments that enable the Bolt endpoint (BOLTPORT, disabled by default) are affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
FalkorDBto a version that resolves this vulnerability.Fixed in 4.20.0
Event History
Frequently Asked Questions
Which deployments are exposed?
Only FalkorDB deployments with the Bolt endpoint enabled through BOLT_PORT are affected. BOLT_PORT is disabled by default, so deployments that have not enabled it are not exposed through this issue.
What does an attacker need to exploit this?
An attacker can be remote and unauthenticated and needs network access to the Bolt port. Exploitation involves sending a WebSocket frame that uses a 64-bit extended payload length and an attacker-controlled masking key.
Why does this affect release builds?
The relevant bounds check in buffer_apply_mask is an ASSERT(). Because ASSERT() is compiled out in release builds, masking can proceed beyond the receive buffer and write to heap memory.
What can be done if upgrading is not immediately possible?
Disable the Bolt endpoint by ensuring BOLT_PORT is not enabled. If the endpoint must remain enabled, restrict network access to the Bolt port to trusted clients until the deployment can be updated.