Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed Bolt WebSocket port
-
DeliverySend frame with oversized 64-bit payload length
-
ExploitBypass ASSERT bounds check (release build)
-
Executionbuffer_apply_mask XORs past heap buffer
-
ImpactHeap corruption and denial of service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, write limits
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the target FalkorDB deployment has explicitly enabled the Bolt protocol endpoint via BOLT_PORT, which is disabled by default - so default installations are not exposed. When enabled and network-reachable, no authentication or user interaction is needed (PR:N/UI:N): the attacker simply sends a WebSocket frame using the 64-bit extended payload length field with an unbounded length value to the Bolt port. A secondary enabling factor is that the product is built as a release binary, where the ASSERT() bounds check in buffer_apply_mask is compiled out; a debug build would abort at the assertion instead. The practical limiting factor is the non-default Bolt configuration plus network exposure of that port. |
| Impact | Signals are moderately strong but qualified. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms a network-reachable, low-complexity, unauthenticated trigger, and the impact profile (VI:H/VA:H, VC:N) matches the described heap out-of-bounds write causing denial of service and possible memory corruption without confidentiality loss - consistent with CWE-787. No EPSS score, no CISA KEV listing, and no public exploit were provided, so exploitation status is 'no public exploit identified at time of analysis'; the vulnerability is not known to be actively exploited. The single most important mitigating factor is that only deployments that explicitly enable the Bolt endpoint (BOLT_PORT, disabled by default) are affected, which sharply reduces the real-world attack surface despite the network vector. This is therefore a genuine priority for the subset of operators who have turned on Bolt and exposed the port, but a low-urgency issue for the default-configured majority. The write primitive is an attacker-controlled XOR of the mask key beyond the receive buffer, which realistically yields reliable crashes (DoS); escalation to code execution is described as only 'possibly' achievable and is not demonstrated. Net: patch-worthy and clearly real, but gated by a non-default configuration rather than a universally exposed flaw. |
| Exploit ScenarioDerived | An attacker who can reach a FalkorDB instance that has the Bolt endpoint enabled sends a crafted WebSocket frame declaring a 64-bit extended payload length far larger than the receive buffer. Because the only bounds check in buffer_apply_mask is an ASSERT() compiled out of release builds, the server XORs memory past the end of the heap buffer with the attacker-supplied mask key, corrupting heap memory and crashing the process. No public exploit code was identified, and no authentication is required per the PR:N vector. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 09, 2026
Heap-based out-of-bounds write in FalkorDB's Bolt/WebSocket handling (all versions before 4.20.0) allows a remote unauthenticated attacker to crash the server and potentially corrupt heap memory by sending a WebSocket frame with a 64-bit extended payload length to the Bolt port. The flaw spans ws_read_frame in src/bolt/ws.c and buffer_apply_mask in src/bolt/buffer.c, where the only length check is an ASSERT() that is compiled out of release builds, so the masked XOR operation runs past the end of the receive buffer. Impact is limited to deployments that explicitly enable the Bolt endpoint via BOLT_PORT, which is disabled by default; no public exploit code has been identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to FalkorDB 4.20.0 (release tag v4.20.0, https://github.com/FalkorDB/FalkorDB/releases/tag/v4.20.0), which incorporates the fix from PR #2170 and commit 0b11a00b34b25c4d4fdfe55f0a35c8a00593bd7d that bounds the WebSocket frame payload length and hardens the masking routine. If immediate upgrading is not possible, the highest-value compensating control is to leave the Bolt endpoint disabled (do not set BOLT_PORT) - this removes the attack surface entirely, at the cost of losing Bolt/Neo4j-driver compatibility for any clients relying on it. Where Bolt must stay enabled, restrict network access to the Bolt port with firewall rules, security groups, or bind-to-loopback plus a trusted proxy, and treat the port as untrusted/internet-exposed only in a last resort; these measures reduce but do not eliminate risk because any client that can reach the port is unauthenticated at the protocol layer. Operating a debug build of FalkorDB would cause the ASSERT() to abort the process instead of corrupting the heap, but this converts a memory-corruption bug into a trivial remote denial of service and is not a substitute for patching. Since the crash is triggered by a single malformed frame, monitor and rate-limit or drop anomalous Bolt connections as a detection and containment measure.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability is a CWE-787 out-of-bounds write in FalkorDB's Bolt protocol implementation, a binary protocol (Neo4j-compatible) served over WebSocket. In ws_read_frame (src/bolt/ws.c), the frame parser reads the 64-bit extended payload length field without enforcing an upper bound on the announced length. That unbounded length is then passed to buffer_apply_mask in src/bolt/buffer.c, which unmasks the payload by XORing the receive buffer with the client-supplied 4-byte mask key. The only guard protecting this XOR loop is an ASSERT() on the buffer length, and because FalkorDB ships release binaries where assertions are compiled out, the loop happily writes past the end of the heap-allocated receive buffer - an attacker-controlled, mask-key-driven write past the allocation boundary. A debug build would abort at the assertion rather than corrupt memory, which is why release deployments are the exposed ones. The affected component tree corresponds to CPE cpe:2.3:a:falkordb:falkordb:*:*:*:*:*:*:*:* (all versions prior to 4.20.0); the vulnerable code path is only reachable when the Bolt endpoint is compiled in and enabled at runtime through BOLT_PORT.
Know when Falkordb gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Unauthenticated network trigger via a single crafted frame gives AV:N/AC:L/PR:N/UI:N; heap corruption and DoS give I:H/A:H with no data disclosure (C:N) and no scope change.
Primary rating from Vendor (securin).
CVSS VectorVendor: securin
DescriptionCVE.org
A heap-based out-of-bounds write in the ws_read_frame function (src/bolt/ws.c) and the buffer_apply_mask 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 buffer_apply_mask 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 (BOLT_PORT, disabled by default) are affected.
Executive ViewAI
FalkorDB, an open-source graph database, contains a heap memory corruption flaw in its Bolt/WebSocket endpoint that could let a remote attacker crash a database server and potentially corrupt memory. Exposure is conditional: the Bolt interface is disabled by default and only affected deployments that have explicitly enabled it via BOLT_PORT are at risk, though for those teams this is both an availability and a data-integrity concern. No public exploit code has been identified at time of analysis, and a vendor fix is available.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Memory corruption occurs when a program writes data beyond the boundaries of allocated memory regions or accesses memory in unintended ways, violating the integrity of the process's address space.
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
FalkorDB instances that explicitly enable the optional Bolt wire-protocol endpoint can be crashed, and possibly have arb
Remote attackers who can issue Redis replication commands to a FalkorDB instance before 4.18.1 can trigger a double-free
Stack-based buffer overflow in FalkorDB versions before 4.18.4 allows remote attackers who can issue Redis replication c
Authentication bypass in the FalkorDB Bolt endpoint (src/bolt/bolt_api.c) affects all releases before 4.20.0 and lets a
Heap memory disclosure and denial of service in FalkorDB before 4.18.4 stem from an out-of-bounds read in the RDB deseri
A crafted, attacker-controlled serialized graph payload processed by FalkorDB 4.20.1 through 4.20.4 overflows a buffer i
Type confusion in FalkorDB versions before 4.20.0 allows an authenticated client that can issue GRAPH.QUERY to crash the
Denial of service in FalkorDB v4.20.1, the Redis-module graph database, where the GRAPH.EFFECT replication handler in sr
A stack overflow in the _ValidateUnion_Clauses routine of FalkorDB (a Redis graph module) versions 4.20.1 through 4.20.4
Missing write-command registration for graph.UDF in the FalkorDB Redis module versions 4.20.1 through 4.20.4 allows a cl
Authenticated denial of service in the FalkorDB Redis module versions 4.20.1 through 4.20.4 allows a user with query acc
A crafted bulk-insert payload triggers an integer overflow in FalkorDB's _BulkInsert_ReadProperty parser (/bulk_insert.c
EUVD-2026-95486
GHSA-x67x-q5pm-p9h7
NVD
CVE.org
EPSS
Exploit-DB