CVE-2026-86227: Valkey Out-of-Bounds Read DOS Vulnerability

CVE-2026-86227 Overview

CVE-2026-86227 is an out-of-bounds read vulnerability in Valkey, the open-source in-memory data store forked from Redis. The flaw resides in the kvstoreGetHashtable function in src/kvstore.c and affects Valkey versions up to 9.0.5 and 9.1.1. Manipulation of the didx argument triggers reads beyond allocated bounds, producing a denial-of-service condition. Exploitation requires cluster mode and an attacker-controlled dump.rdb file at startup, achieved through data directory write access, replication feed, or a crafted stored RDB. The Valkey maintainers characterized the issue as worth fixing for memory safety but not meeting their bar for a security disclosure.

Critical Impact

An attacker with the ability to plant or feed a crafted RDB file to a Valkey node running in cluster mode can trigger an out-of-bounds read at boot, causing process crash and service disruption.

Affected Products

• Valkey 9.0.0 through 9.0.5
• Valkey 9.1.0 through 9.1.1
• Valkey deployments operating in cluster mode with attacker-influenced RDB persistence files

Discovery Timeline

• 2026-09-06 - CVE-2026-86227 published to NVD
• 2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86227

Vulnerability Analysis

The vulnerability is classified under [CWE-119] (Improper Restriction of Operations within the Bounds of a Memory Buffer). Valkey's kvstore abstraction manages an array of hashtables indexed by didx (database index). The kvstoreIsImporting function called an assert(didx < kvs->num_hashtables) check that only validated the upper bound and omitted a lower-bound check on didx. When Valkey runs in cluster mode and loads an RDB file containing slot import ranges, the slot values are read via rdbLoadLen without validation against CLUSTER_SLOTS. A crafted RDB supplying out-of-range slot values propagates into didx, allowing the runtime to dereference memory outside the hashtable array. The result is a read of unintended memory and process termination.

Root Cause

The root cause is missing input validation on values deserialized from persisted RDB data. The src/cluster_migrateslots.c loader accepted start_slot and end_slot from the RDB stream without enforcing bounds against CLUSTER_SLOTS or verifying start_slot <= end_slot. Downstream, kvstoreIsImporting and kvstoreGetHashtable trusted the didx argument and only asserted an upper bound, permitting negative or attacker-controlled indices to reach memory accessors.

Attack Vector

Exploitation is not network pre-authentication. The attacker must occupy a position that allows placement of a crafted dump.rdb at Valkey startup. Valid positions include write access to the data-dir, control of a replication feed pushing RDB payloads to a replica, or the ability to substitute the persisted RDB file. Once Valkey boots in cluster mode and parses the crafted RDB, the out-of-bounds read triggers, crashing the process. The attack complexity is rated high, and the impact is confined to availability.

// Patch: src/cluster_migrateslots.c - validate slot ranges from RDB
        uint64_t end_slot;
        if ((start_slot = rdbLoadLen(rdb, NULL)) == RDB_LENERR) goto err;
        if ((end_slot = rdbLoadLen(rdb, NULL)) == RDB_LENERR) goto err;
+       if (start_slot >= CLUSTER_SLOTS || end_slot >= CLUSTER_SLOTS || start_slot > end_slot) {
+           serverLog(LL_WARNING, "Invalid slot import range in RDB: start=%llu end=%llu",
+                     (unsigned long long)start_slot, (unsigned long long)end_slot);
+           goto err;
+       }

        slotRange *slot_range = zmalloc(sizeof(slotRange));
        slot_range->start_slot = start_slot;

// Patch: src/kvstore.c - enforce lower bound on didx
int kvstoreIsImporting(kvstore *kvs, int didx) {
-   assert(didx < kvs->num_hashtables);
+   assert(didx >= 0 && didx < kvs->num_hashtables);
    return hashtableFind(kvs->importing, (void *)(intptr_t)didx, NULL);
}

Source: GitHub Commit 4691888

Detection Methods for CVE-2026-86227

Indicators of Compromise

• Unexpected Valkey process crashes or SIGSEGV events during startup on cluster-mode nodes
• Modification timestamps on dump.rdb that do not correlate with legitimate BGSAVE or replication events
• Log entries containing Invalid slot import range in RDB on patched builds indicating rejected malicious RDBs
• Unauthorized writes to the Valkey data-dir or unexpected replication sources initiating full RDB syncs

Detection Strategies

• Monitor filesystem integrity on the Valkey data directory and alert on modifications from unexpected user contexts
• Correlate Valkey crash events with recent RDB file changes and preceding replication or restore operations
• Inspect replication topology for unauthorized replica or master relationships that could deliver crafted RDB payloads

Monitoring Recommendations

• Enable audit logging on the Valkey data-dir and forward events to a centralized SIEM for correlation
• Track Valkey process uptime and restart frequency; repeated crashes on the same node after RDB load are a strong signal
• Alert on serverLog warnings referencing slot import validation on patched Valkey builds

How to Mitigate CVE-2026-86227

Immediate Actions Required

• Upgrade Valkey to a build containing commit 4691888e7fab3df128f0bde5750c9fde2ae552fa from the Valkey repository
• Restrict filesystem permissions on the Valkey data-dir so only the Valkey service account can write to it
• Audit replication configuration and remove any unauthenticated or untrusted replica-master relationships
• Validate the integrity of existing dump.rdb files against known-good backups before restart

Patch Information

The fix is delivered in commit 4691888e7fab3df128f0bde5750c9fde2ae552fa, merged via Pull Request #4229 and tracked in Issue #4222. The patch adds bounds validation on start_slot and end_slot against CLUSTER_SLOTS during RDB load and adds a lower-bound assertion on didx in kvstoreIsImporting. Additional context is available at VulDB CVE-2026-86227.

Workarounds

• Disable cluster mode on Valkey deployments where clustering is not required, as the vulnerability is only reachable in cluster mode
• Enforce strict access controls on the data-dir using OS-level permissions and mandatory access control (SELinux, AppArmor)
• Require authenticated and TLS-protected replication using masterauth and tls-replication yes to prevent injection of crafted RDB payloads

# Configuration example: harden Valkey against RDB tampering
# valkey.conf
dir /var/lib/valkey                    # restrict to 0700 owned by valkey user
requirepass <strong-shared-secret>
masterauth  <strong-shared-secret>
tls-replication yes
tls-cert-file /etc/valkey/tls/valkey.crt
tls-key-file  /etc/valkey/tls/valkey.key
tls-ca-cert-file /etc/valkey/tls/ca.crt

# Filesystem hardening
chown -R valkey:valkey /var/lib/valkey
chmod 700 /var/lib/valkey
chmod 600 /var/lib/valkey/dump.rdb