CVE-2026-86227: 
Valkey vulnerability analysis and mitigation

CVE-2026-86227 is an out-of-bounds read vulnerability in the kvstoreGetHashtable function (src/kvstore.c) of valkey-io Valkey, a high-performance distributed key-value database. It affects Valkey versions 9.0.0 through 9.0.5 and 9.1.0 through 9.1.1. The vulnerability arises when a crafted dump.rdb file containing an out-of-range slot import value is loaded during startup in cluster mode, causing a negative kvstore index access and server crash. It was disclosed on September 6, 2026, with a patch published the same day. The CVSS v3.1 base score is 3.1 (Low) and the CVSS v4.0 base score is 1.3 (Low) (GitHub Advisory, Feedly).

The root cause is improper bounds validation (CWE-119/CWE-125) in the RDB loading path for cluster slot import metadata. The function clusterRDBLoadSlotImport() reads start_slot and end_slot as uint64_t from the RDB file but stores them into slotRange struct fields typed as int without validating that values fall within the legal cluster slot range (0–16383). A crafted value such as 0x80000000 is accepted by the parser, then narrowed to -2147483648 when assigned to the signed integer field. This negative value is later passed as a didx argument to kvstoreSetIsImporting(), which only checked didx < kvs->num_hashtables (not didx >= 0), allowing the negative index to reach kvstoreGetHashtable() and trigger an out-of-bounds array access. 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 stored crafted RDB. A proof-of-concept RDB file was publicly released alongside the bug report (GitHub Issue #4222, GitHub Advisory).

Successful exploitation causes a reliable denial of service: the Valkey server crashes during startup before completing initialization, preventing the service from becoming available. There is no confidentiality or integrity impact — the vulnerability is limited to availability. Because the crash occurs at boot time when loading a malicious RDB, an attacker with the ability to plant a crafted dump.rdb can persistently prevent the cluster node from starting, potentially disrupting cluster availability if multiple nodes are affected (GitHub Issue #4222, Feedly).

A proof-of-concept crafted RDB file (RDB.zip) was publicly released by the original reporter alongside the bug report, making exploitation reproducible by anyone with access to the Valkey data directory or replication feed. The CVE status is "Deferred" by the Valkey maintainers, who closed the 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." There is no evidence of in-the-wild exploitation or threat actor attribution. The EPSS score is 0.321% (25th percentile), and the vulnerability is not listed in the CISA KEV catalog. Exploitation is rated high complexity due to the prerequisite of cluster mode and attacker-controlled RDB file placement (GitHub Advisory, Feedly).

1. Prerequisite — Cluster mode and RDB access: Confirm the target Valkey instance runs in cluster mode (cluster-enabled yes) and identify a path to place or influence the dump.rdb file — via write access to the data directory, control over a replication feed, or ability to inject a crafted RDB through another vector.
2. Craft a malicious RDB: Construct a dump.rdb file containing an RDB_OPCODE_SLOT_IMPORT opcode with an out-of-range slot value (e.g., start_slot = 0x80000000, end_slot = 0x80000000). The publicly released RDB.zip from the bug report can be used directly as a reference artifact.
3. Place the crafted RDB: Write the malicious dump.rdb to the Valkey data directory (e.g., /tmp/rdbneg/dump.rdb) and supply a matching valkey.conf pointing to that directory with cluster mode enabled.
4. Trigger server startup: Start (or restart) the Valkey server: ./valkey-server /tmp/rdbneg/valkey.conf. During RDB loading, clusterRDBLoadSlotImport() reads the crafted slot value, narrows it to a negative int, and passes it as a kvstore index.
5. Observe crash: The server crashes in kvstoreGetHashtable() due to a negative-index out-of-bounds array access, producing a signal 11 (SIGSEGV) and preventing successful startup — achieving a persistent denial of service at boot (GitHub Issue #4222, GitHub Advisory).

• File System: Unexpected or recently modified dump.rdb in the Valkey data directory; presence of external RDB files (e.g., rdbneg/dump.rdb) not generated by the running instance; nodes-<port>.conf files with anomalous slot range entries.
• Logs: Valkey startup log entries containing "Invalid slot import range in RDB: start=... end=..." (emitted by the patched version when detecting the malformed range); crash log entries referencing kvstoreGetHashtable, kvstoreSetIsImporting, or clusterRDBLoadSlotImport in the stack trace; signal 11 (SIGSEGV) crash reports during server startup.
• Process: valkey-server process terminating immediately after startup with a non-zero exit code; repeated failed restart attempts by init systems (systemd, supervisord) for the Valkey service (GitHub Issue #4222).

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 strengthens the assertion in kvstoreSetIsImporting() to check didx >= 0. Users should upgrade to a version containing this patch once released by the Valkey project. As interim workarounds: restrict write access to the Valkey data directory to trusted processes only; disable cluster mode (cluster-enabled no) if not operationally required; validate RDB files before loading them, especially in environments where replication feeds or data directories may be accessible to lower-privileged users (GitHub Commit, 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 high exploitation complexity and limited impact scope. The fix was nonetheless merged via PR #4229. The CVE was subsequently assigned and published by NVD with a Low severity rating, consistent with the maintainers' assessment. No significant broader media coverage or notable researcher commentary beyond the original bug report has been observed (GitHub Issue #4222, GitHub Advisory).