What this actually is.
Technical background, root cause, and affected surface.
A heap-based out-of-bounds write in ws_read_frame (src/bolt/ws.c) and buffer_apply_mask (src/bolt/buffer.c) in FalkorDB before 4.20.0 allows a remote unauthenticated attacker to corrupt heap memory by sending a WebSocket frame with a 64-bit extended payload length. The length is not bounded, and the only bounds check in buffer_apply_mask is an ASSERT that is removed in release builds, so the function walks past the end of the buffer's chunk array XORing memory with the attacker's mask key. Bolt is disabled by default (BOLT_PORT=-1); only deployments that set BOLT_PORT are exposed.
- Vendor
- FalkorDB
- Product
- FalkorDB
- Severity
- Critical
- CVSS Score
- 9.1
- Status
- Fixed (v4.20.0)
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
- CWE
- CWE-787
From one request
to root shell.
Reproduced in a sandboxed environment. Requires only LAN or WiFi adjacency.
s.sendall(header + payload) print("Frame sent. Expect crash / sanitizer report on the server.") time.sleep(0.3) try: print("Server bytes:", s.recv(4096)) except Exception as e: print("Recv error:", e) s.close()
The bug, and the fix.
// src/bolt/ws.c:185-203 (identical in master 835d06e): uint64_t payload_len = frame_header & 0x7F; if(payload_len == 126) { payload_len = ntohs(buffer_read_uint16(buf)); } else if(payload_len == 127) { payload_len = ntohll(buffer_read_uint64(buf)); // 2^64-1 max, NO upper bound } if(mask) { uint32_t masking_key = buffer_read_uint32(buf); buffer_apply_mask(*buf, masking_key, payload_len); // walks past allocation } // src/bolt/buffer.c:53: ASSERT(buffer_index_length(&buf) >= payload_len); // no-op in release
What an attacker does to you.
Post-exploitation outcomes mapped to CVSS impact metrics.
Pre-authentication heap corruption: the attacker chooses the 32-bit XOR mask and how far the walk runs past the buffer, giving a controlled-XOR write primitive and at minimum a crash of the redis-server process. Only deployments with BOLT_PORT configured are exposed. Assessed from source review; exploitation beyond a crash was not demonstrated.
C:N · I:H · A:H
CWE-787
Fix it. In this order.
A runbook, not a checklist. Sequence matters — assume compromise before you act.
Upgrade FalkorDB to 4.20.0 or later, where the Bolt/WebSocket endpoint has been removed (PR #2170), or move to 6.x. Interim for older versions: leave BOLT_PORT unset (default) or restrict the Bolt port to trusted networks.
disclose@securin.ioVendors moved in days.
Attackers in hours.
Reconstructed from vendor advisories, CISA bulletins, and Securin research records.
Source-level audit of FalkorDB v4.18.10; re-verified against upstream master 835d06e on 2026-06-24 (2026-04 to 2026-06-29)
Reported to FalkorDB security team (security@falkordb.com) as part of a 6-finding disclosure pack; vendor acknowledged receipt the same day
Vendor removed the Bolt subsystem (PR #2170, commit 0b11a00) - no advisory or credit
FalkorDB 4.20.0 released without Bolt support
90-day coordinated disclosure window ended with no further vendor response
FalkorDB 6.0.0 released (Rust engine; C code base not present)
Securin re-verified: Bolt code absent from 4.20.0, 4.20.7, 4.22.0 and 6.0.2 | CVE-2026-107909 assigned by Securin CNA
CVE-2026-107909 published to the CVE List by Securin CNA (NVD import pending)
Disclosed 9 days after discovery
Cite, verify, go deeper.
Primary sources — NVD, CISA KEV, and machine-readable IoC feed.