CVE-2026-86227

Executive Summary

CVE-2026-86227 is an out-of-bounds (OOB) read vulnerability in Valkey, an open-source in-memory data structure store, affecting versions up to 9.0.5 and up to 9.1.1. The flaw resides in the kvstoreGetHashtable function within src/kvstore.c and is triggered by a crafted didx argument, enabling an attacker-positioned denial of service (DoS) during startup when cluster mode is enabled and an attacker-controlled dump.rdb file is loaded. The vulnerability requires non-trivial preconditions (cluster mode plus RDB write access or replication feed) and is rated CVSS 3.1 with a score of 3.1 (Low severity). No public PoC, exploit code, or CISA KEV listing exists; the issue was triaged by the project as worth fixing for memory-safety reasons but below the security-disclosure bar.

Technical Analysis

The vulnerability is classified under CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer), specifically manifesting as an out-of-bounds read. The affected code path is in src/kvstore.c, within the function kvstoreGetHashtable. This function accepts a didx (dictionary index) argument. When the argument is corrupted or intentionally crafted to be out of range, the function performs a read operation outside the valid memory boundaries of an internal array of hash tables.

Valkey’s kvstore (key-value store) abstraction maintains multiple hash tables for sharding data across dictionary slots when running in cluster mode. The didx parameter is used to index into this array. If the value in the persisted RDB file references a dictionary index that lies outside the allocated bounds, the read operation fetches memory beyond the end of the array. Because the RDB file is parsed at startup and the indices are carried into the kvstoreGetHashtable call, an attacker who can influence the content of the RDB file can deterministically control the out-of-bounds offset.

Attack complexity is classified as High in the CVSS vector, and the description explicitly states "exploitability is difficult." This difficulty stems from the layered preconditions required to exploit the flaw. First, the target Valkey instance must run in cluster mode. Second, the attacker needs one of:

1. Write access to the data directory (data-dir), enabling them to place a crafted RDB file that will be loaded on restart.
2. Control over a replication feed, where the attacker acts as a master and feeds a malicious RDB snapshot to a replica.
3. Pre-existing ability to persist a crafted RDB through legitimate write commands (e.g., via a previous compromise of an application that writes to Valkey).

Crucially, the flaw is not a network pre-auth vulnerability. The vector string indicates the attack requires Low privileges (PR:L), consistent with needing some prior foothold (e.g., an application account that can issue write commands and trigger BGSAVE, or filesystem access to the data directory).

The crash outcome is a denial of service (A:L — Low availability impact). The OOB read does not leak data to the attacker (C:N/I:N), as the result is not exfiltrated; rather, the process likely terminates when reading unmapped memory, causing a startup-time crash and preventing the server from coming online.

Notably, the project’s own triage closed the issue, stating the bug is "worth fixing for the sake of memory safety… but I don't think it meets our bar for a security disclosure." This framing does not diminish the technical validity of the OOB read — it merely indicates the project assessed the real-world exploitability and impact thresholds as low. Security teams should still track this CVE because DoS at boot can be economically damaging and because the code path is in core data-loading logic.

Exploitation Scenarios

A complete, validated attack chain cannot be constructed from public information because no PoC or exploit code is available, and insufficient technical detail exists about the exact layout of the kvstore index array. However, the following scenario-accurate chain is inferred strictly from the NVD description and data provided.

Step 1 — Reconnaissance / Target Identification. The attacker identifies a Valkey instance running version <= 9.0.5 or <= 9.1.1. Credible discovery vectors include scanning TCP port 6379 (the default Valkey/Redis data port) via Shodan or masscan, and fingerprinting the banner (INFO command). The attacker further verifies that the instance runs in cluster mode (e.g., via a leaked config file, the CLUSTER INFO reply on an exposed port, or prior reconnaissance of the deployment architecture). Relevant Shodan queries: product:"Valkey" port:"6379" or historical Redis footprints: product:"Redis" port:"6379".

Step 2 — Triggering the Flaw. With cluster mode confirmed, the attacker must get a crafted RDB file onto the target. Three primary vectors exist, all matching the preconditions in the NVD description:

• Data-dir write access: If the attacker has filesystem-level access to the server (e.g., through a compromised container, misconfigured volume mount, or an adjacent application vulnerability), they can write a malicious dump.rdb into the configured data directory and trigger a server restart.
• Replication feed: If the target Valkey is a replica, the attacker-controlled master can send a crafted RDB payload during the full-sync handshake. This is a legitimate protocol feature, requiring the attacker to impersonate a master (REPLICAOF command directed at an attacker-controlled node).
• Stored crafted RDB: A prior compromise or an insider with legitimate write access uses standard commands (SET, HSET, etc.) to populate keys with values designed to influence the serialized didx field, then triggers persistence (BGSAVE/SAVE). On the subsequent restart, the RDB loader reconstructs an out-of-range index.

Step 3 — Execution at the Vulnerability Class Level. The crafted RDB contains a key entry whose metadata references a didx value outside the valid range of the kvstore’s internal hash-table array. When Valkey processes this entry during the RDB load, the call chain eventually reaches kvstoreGetHashtable(didx), which performs an out-of-bounds read on the array. The precise memory-displacement mechanics (whether the read hits unmapped pages causing a SIGSEGV, or garbled pointers cause a subsequent invalid dereference) are implementation-dependent and not disclosed; at the class level, this is a deterministic memory-safety violation triggered by corrupting a multi-byte integer field in the persisted snapshot format.

Step 4 — Post-Exploitation Impact. The process crashes during the RDB load phase, before the server finishes initializing and begins accepting client connections. The result is a denial of service: the Valkey node fails to come online, affecting all applications (caches, session stores, real-time feed readers, lock services) that depend on it. In a clustered deployment, the failure can cascade if the cluster cannot form a quorum. The attack requires access to restart the server (e.g., the container orchestrator or systemd auto-restart loop), meaning the DoS can be repeated indefinitely if the malicious RDB persists at the load path. If the attacker only has a one-shot replication push, they may cause a single failed startup; subsequent valid snapshots would recover the node.

Note: No public PoC or exploit code exists for this CVE, and the exploitability rating is "difficult." The attack chain above is an inference from the vulnerability class and the preconditions stated in the NVD description; specific offsets, values, and payload byte layouts are unknown.

Impact Assessment

Business Impact. The primary business impact is a denial-of-service condition that prevents a Valkey node from starting or joining a cluster. This translates directly into application downtime: any service that reads or writes to the affected Valkey instance (API caches, rate-limit counters, session state, job queues, feature-flag stores) will fail or degrade when the store is unreachable. For organizations running Valkey as the backbone for low-latency data services, an inability to restart a node (e.g., after a routine maintenance reboot) creates an availability gap that may be measured in hours if the engineering team cannot reconstruct a clean RDB.

Affected Systems. All Valkey deployments running versions <= 9.0.5 or <= 9.1.1 with cluster mode enabled. Single-instance (non-cluster) deployments are not implied to be vulnerable because the kvstore dictionary-index abstraction is predominantly exercised in sharded/cluster configurations — but this boundary is not explicitly confirmed in the NVD data, so teams running standalone nodes in these versions should still track the CVE.

Blast Radius. The CVSS v3.1 vector AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L confirms network reachability, high attack complexity, low privilege requirement before the attack can be staged, no user interaction, no scope change, no confidentiality or integrity impact, and low availability impact. The low availability score reflects the narrow blast radius: one process crashes at boot, but no data is corrupted, no secrets are exfiltrated, and no code is executed. In a clustered deployment, however, the effective blast radius expands because cluster availability depends on member nodes; orchestrators such as Kubernetes may repeatedly restart the crashing pod, generating noise and consuming cluster scheduling resources. The CISA KEV database does not list this CVE, and no known threat-actor campaigns using this flaw have been identified.

Detection Guidance

Sigma Rule

title: Valkey CVE-2026-86227 - Crash on Malicious dump.rdb Loading
id: 44c5905e-8b2f-4a9c-b8be-4a53bb8e2a2d
status: experimental
description: Detects Valkey server process crashes that occur during startup while loading an RDB file, potentially indicating an attempted out-of-bounds read via kvstoreGetHashtable.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-86227
author: Valtersit Threat Intelligence
date: 2026/05/14
logsource:
    category: process_creation
    product: linux
detection:
    selection_server_start:
        Image|endswith:
            - '/valkey-server'
            - '/redis-server'
        CommandLine|contains: '--cluster-enabled yes'
    selection_crash_exit:
        # High exit codes common for SIGSEGV; also check for immediate restart loops.
        ExitCode:
            - 139      # SIGSEGV (128+11)
            - 134      # SIGABRT (128+6)
    selection_crash_message:
        # Auditd or syslog alternatives would capture the kernel OOPS signature
        # This field is contingent on logsource having command-line output.
        CommandLine|contains: 'dump.rdb'
    condition: selection_server_start and (selection_crash_exit or selection_crash_message)
    level: high
falsepositives:
    - Legitimate Valkey crashes caused by hardware faults or corrupted memory.
    - Restart loops induced by full disks (RDB write failure) rather than OOB reads.
tags:
    - attack.t1190
    - cve.2026.86227

YARA Rule

rule CVE_2026_86227_Valkey_Crafted_RDB {
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects keys or metadata patterns in RDB files that may correspond to a crafted didx value triggering kvstoreGetHashtable OOB read in Valkey <= 9.0.5 / 9.1.1."
        date = "2026-05-14"
        cve = "CVE-2026-86227"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-86227"
        score = 40

    strings:
        // RDB file magic header "REDIS" or "VALK" variant
        $rdb_magic = "REDIS"
        $rdb_magic_v2 = "VALK"

        // Opcode for a hash/dictionary metadata section in Redis RDB format (0xFC - RDB_OPCODE_SLOT_INFO
        // varies; using generic high-opcode patterns typically present in entry metadata)
        $slot_opcode = { FC }  // RDB_OPCODE_SLOT_INFO (opcode 252)

    condition:
        uint32(0) == 0x53494445 or uint32(0) == 0x4B4C4156   // "REDIS" or "VALK"
        and (
            ($slot_opcode at 0x08 or $slot_opcode at 0x10)
            or (#slot_opcode > 3)  // many slot-info records present — suspicious for crafted dict indices
        )
        and filesize < 100MB
}

Suricata IDS Rule

alert tcp any any -> $VALKEY_SERVERS 6379 (msg:"CVE-2026-86227 Valkey KVStore OOB Read Attempt via Replication Feed"; flow:established,to_server;
content:"PSYNC"; nocase; content:"|0a|"; within: 50;
pcre:"/^[A-Fa-f0-9]{40}\.(0|[1-9][0-9]*)\r\n/m";
reference:cve,2026-86227;
classtype:attempted-dos;
sid:10086227; rev:1;)

Elastic Detection

// Detect repeated crash loops of the valkey-server process potentially loading crafted RDB files.
sequence by host.name with maxspan=5m
  [process where event.type == "start" and
     process.name : ("valkey-server", "redis-server") and
     process.args : "*cluster-enabled*"]
  [process where event.type == "end" and
     process.name : ("valkey-server", "redis-server") and
     process.exit_code in (134, 139)]
  [file where event.type == "creation" and
     file.name == "dump.rdb" and
     file.path : "*valkey*"]

Splunk SPL Query

index=main sourcetype="linux:audit" OR sourcetype="syslog"
| search "valkey-server" OR "redis-server"
| rex field=_raw "(?i)signal\s+(?<signal>\w+)"
| rex field=_raw "(?i)core dumped.*pid\s+(?<pid>\d+)"
| where signal="SIGSEGV" OR signal="SIGABRT"
| stats count by host, pid, _time, signal
| where count > 1
| eval alert_kind = "Possible CVE-2026-86227 crash loop"
| table _time, host, pid, signal, count
| sort - _time

Wazuh OSSEC Rule

<group name="valkey,">

  <rule id="100862" level="12">
    <if_sid>100001</if_sid>
    <match>valkey-server|redis-server</match>
    <regex>Segmentation fault|SIGSEGV|SIGABRT|core dumped</regex>
    <description>CVE-2026-86227: Potential Valkey OOB read crash during dump.rdb load.</description>
    <group>vulnerability,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

</group>

Mitigation & Patch Guidance

Patch confidence is 0/4 — no tracked source reports an official patch or version containing the fix. The NVD description mentions a patch name/commit hash (4691888e7fab3df128f0bde5750c9fde2ae552fa), which likely exists in the upstream Valkey repository, but it has not been verified in any release, backport stream, or advisory. Until the commit is confirmed in a tagged release, CVE-2026-86227 should be treated as unpatched in the wild.

1) Immediate Mitigations (Defense in Depth)

• Disable cluster mode on any Valkey instance that does not strictly require it. The NVD description explicitly scopes exploitation to cluster mode; standalone instances loading RDB files do not exercise the vulnerable code path (per the description), although insufficient detail exists to fully exclude the risk.
• Restrict write access to the data directory. Ensure that the user running valkey-server cannot have its data-dir overwritten by lower-privileged processes. Mount data directories as read-only where persistence is not being actively used.
• Block untrusted replication feeds. If a Valkey node is a replica, ensure the master address is pinned to known, trusted infrastructure. Use requirepass/ACL restrictions so that only authorized accounts can issue REPLICAOF.
• Firewall ingress to port 6379: Restrict exposure to only trusted application servers and admin networks. This limits the ability of remote attackers to stage any interaction with the server.
• Monitor for crash loops. Deploy the Sigma/Splunk rules above so that a single-node crash pattern triggers a security alert rather than being lost among routine process restarts.

2) Patch / Upgrade Steps

• Subscribe to the upstream Valkey GitHub repository and monitor for a release containing commit 4691888e7fab3df128f0bde5750c9fde2ae552fa or newer (likely versions > 9.1.1). Do not deploy the raw commit onto production without QA validation.
• Until a fixed release is available, consider pinning to a version believed stable, but understand that 9.0.5 and 9.1.1 are the highest affected versions — meaning even the latest available 9.x releases may be affected.
• After applying any future patch, validate the RDB load path with regression tests: load a known-good snapshot, then test an intentionally corrupt one to confirm graceful failure instead of a crash.

3) Long-Term Hardening

• Enable Valkey’s ACLs and rename-command features to restrict system commands like BGSAVE, SAVE, SLAVEOF/REPLICAOF only to dedicated admin accounts.
• Segregate Valkey cluster nodes into isolated network segments, limiting which hosts can connect at all.
• Apply regular RDB integrity verification before loading; if snapshots can be externally tampered with, validate checksums or file ownership/presence with an out-of-band integrity monitor.
• Track the CVE in your vulnerability management platform, and reassess the EPSS score once FIRST.org publishes one; the current absence of an EPSS score means no automated prioritization is happening.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-86227 — Official CVE record with CVSS vector and CWE classification.
2. Valkey GitHub Repository: https://github.com/valkey-io/valkey — Source of src/kvstore.c and the referenced patch commit 4691888e7fab3df128f0bde5750c9fde2ae552fa.
3. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-86227 is NOT listed (verified: no KEV entry).
4. FIRST.org EPSS: https://www.first.org/epss/ — CVE-2026-86227 has not yet been assigned an EPSS score; re-check regularly.
5. RedHat CVE Database / Mitre CVE List: https://www.cve.org/CVERecord?id=CVE-2026-86227 — Cross-referenced data source for affected versions and CNA attribution.

Threat Actor Campaign Evidence: None. No exploitation in the wild has been reported, and CISA KEV does not list this CVE. The project’s issue was closed as below the security-disclosure bar, indicating that maintainers assess exploit likelihood as low. However, the public release of the vulnerability details and patch commit hash lowers the barrier for a determined adversary with the requisite preconditions (RDB write access or replication control) to develop a working crash payload.