CVE-2026-86227: 
Valkey vulnerability analysis and mitigation

CVE-2026-86227 is an out-of-bounds read vulnerability in valkey-io Valkey affecting versions 9.0.0 through 9.0.5 and 9.1.0 through 9.1.1. The flaw resides in the kvstoreGetHashtable function in src/kvstore.c, where manipulation of the didx argument — derived from an unchecked slot range in a crafted RDB file — can produce a negative kvstore index, causing an out-of-bounds memory access and server crash during startup. Disclosed on September 6, 2026, the vulnerability carries a CVSS v3.1 base score of 3.1 (Low) and a CVSS v4.0 base score of 1.3 (Low) (GitHub Advisory).

The root cause is improper bounds validation (CWE-119/CWE-125) in the RDB loading path for cluster mode. When Valkey loads RDB_OPCODE_SLOT_IMPORT data, clusterRDBLoadSlotImport() reads start_slot and end_slot as uint64_t values but stores them into slotRange fields typed as int without validating they fall within the legal cluster slot range (0–16383). A crafted value such as 0x80000000 narrows to -2147483648 when assigned to the signed int field. This negative value is then passed as a kvstore hashtable index (didx) to kvstoreSetIsImporting(), which only checked didx < kvs->num_hashtables — trivially satisfied by any negative number — before calling kvstoreGetHashtable(), which performs kvs->hashtables[didx], resulting in a ~16 GiB backward out-of-bounds pointer computation and a crash. Exploitation requires cluster mode to be enabled and the attacker to control the dump.rdb file at startup via data-directory write access, replication feed manipulation, or a pre-stored crafted RDB (GitHub Issue #4222, Patch Commit).

Successful exploitation causes a reliable server-side denial of service: the Valkey server crashes during startup before completing initialization, preventing service availability. The impact is limited to availability (no confidentiality or integrity loss), and only affects cluster-mode deployments where an attacker can influence the RDB file loaded at startup. There is no evidence of lateral movement potential or data exfiltration risk from this vulnerability (GitHub Advisory, GitHub Issue #4222).

A proof-of-concept crafted RDB file (RDB.zip) has been made publicly available by the original reporter, demonstrating reliable crash reproduction on stock Valkey 9.1.0 with and without AddressSanitizer (GitHub Advisory). There is no evidence of in-the-wild exploitation or threat actor attribution at this time. The CVSS v4.0 exploit maturity is rated "Proof of Concept." The vulnerability is not listed in the CISA KEV catalog. Exploitation complexity is rated High, as it requires cluster mode plus attacker-controlled RDB file placement — the Valkey maintainers closed the original issue noting it "is worth fixing for the sake of memory safety… but I don't think it meets our bar for a security disclosure" (GitHub Issue #4222).

1. Precondition — Cluster mode and RDB access: Confirm the target Valkey instance runs in cluster mode (cluster-enabled yes) and identify a means to place or influence the dump.rdb file in the configured data directory (e.g., via write access to the data directory, control over a replication feed, or ability to store a crafted RDB through a connected replica).
2. Craft malicious RDB: Construct a dump.rdb file containing an RDB_OPCODE_SLOT_IMPORT opcode with an out-of-range slot value such as 0x80000000 (2147483648) for start_slot and/or end_slot. A working example RDB is publicly available (GitHub Advisory).
3. Place the crafted RDB: Write or replace the dump.rdb in the Valkey data directory, or inject it via a replication feed so it is loaded at the next server startup.
4. Trigger server startup: Cause the Valkey server to restart (e.g., via a legitimate restart, failover, or node reboot). During startup, rdbLoad() calls clusterRDBLoadSlotImport(), which reads the crafted slot values without validation.
5. Crash occurs: The negative slot index is passed to kvstoreSetIsImporting() and then kvstoreGetHashtable(), producing an out-of-bounds array access. The server crashes with signal 11 (SIGSEGV) before completing startup, resulting in a denial of service (GitHub Issue #4222, Patch Commit).

• Logs: Valkey server log entries showing valkey-server crashed by signal: 11 or similar crash messages during startup; log lines referencing kvstoreGetHashtable, kvstoreSetIsImporting, or clusterRDBLoadSlotImport in crash stack traces; after patching, log warnings such as Invalid slot import range in RDB: start=<value> end=<value>.
• File System: Unexpected modification timestamp on dump.rdb in the Valkey data directory; dump.rdb file size or content inconsistent with expected cluster state; presence of externally supplied RDB files (e.g., rdbneg/dump.rdb) in the data directory.
• Process: Valkey server process terminating immediately after startup with exit code indicating signal 11 (SIGSEGV); repeated failed restart attempts of the valkey-server process in cluster mode.

Apply patch commit 4691888e7fab3df128f0bde5750c9fde2ae552fa, which adds validation in clusterRDBLoadSlotImport() to reject any slot import range where start_slot >= CLUSTER_SLOTS, end_slot >= CLUSTER_SLOTS, or start_slot > end_slot, and also adds a lower-bound check (didx >= 0) in kvstoreSetIsImporting() as defense-in-depth (Patch Commit). As a workaround, restrict write access to the Valkey data directory to trusted processes only, disable cluster mode if not required, and validate RDB files before loading. Implement access controls to prevent unauthorized modification of replication feeds or stored RDB files (GitHub Advisory).

The Valkey maintainers closed the original bug report (Issue #4222) without treating it as a formal security disclosure, stating the issue "is worth fixing for the sake of memory safety… but I don't think it meets our bar for a security disclosure," reflecting the view that the required attacker preconditions (cluster mode plus RDB file control) significantly limit real-world risk (GitHub Issue #4222). Despite this, the fix was merged and the CVE was assigned, indicating the broader security community considered it worth tracking formally.