CVE-2026-86227 in valkey
Summary
by MITRE • 09/07/2026
A weakness has been identified in valkey-io valkey up to 9.0.5/9.1.1. This affects the function kvstoreGetHashtable of the file src/kvstore.c. This manipulation of the argument didx causes out-of-bounds read. It is possible to initiate the attack remotely. The attack is considered to have high complexity. It is indicated that the exploitability is difficult. The exploit has been made available to the public and could be used for attacks. Patch name: 4691888e7fab3df128f0bde5750c9fde2ae552fa. To fix this issue, it is recommended to deploy a patch. Exploitation requires cluster mode plus attacker-controlled dump.rdb at startup (data-dir write access, replication feed, or a stored crafted RDB) - an attacker-position DoS at boot, not network pre-auth. The issue report was closed stating it "is worth fixing for the sake of memory safety… but I don't think it meets our bar for a security disclosure."
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability identified in valkey-io versions up to 9.0.5 and 9.1.1 represents a critical memory safety flaw located within the kvstoreGetHashtable function found in the src/kvstore.c source file. This defect is classified as an out-of-bounds read, which corresponds directly to CWE-125 under the Common Weakness Enumeration standard. The root cause of this issue lies in improper validation or bounds checking of the didx argument passed during hashtable retrieval operations within the key-value store subsystem. When a crafted index value exceeds the allocated boundaries of the underlying data structure, the application attempts to read memory locations that are not part of the intended object. This type of error is particularly dangerous because it can lead to information disclosure if the out-of-bounds memory contains sensitive data, or potentially trigger undefined behavior and crashes depending on how the operating system handles invalid memory access patterns.
The operational impact of this vulnerability is significant due to its potential for remote exploitation, although the attack vector has specific constraints that limit immediate widespread abuse. The exploitability is characterized as difficult with high complexity, primarily because successful exploitation requires a very specific set of conditions. An attacker must have cluster mode enabled and possess control over dump.rdb files at startup time. This implies that the attacker needs write access to the data directory, the ability to manipulate the replication feed, or prior knowledge allowing them to store a crafted RDB file on the server before it initializes. Consequently, this is not a simple network-based pre-authentication attack but rather an exploitation scenario tied to system boot processes and administrative-level file manipulation capabilities. The presence of public exploit code increases the risk profile significantly, as threat actors can leverage these materials to test for vulnerability in environments where they might have achieved partial access or control over data persistence mechanisms.
From a strategic security perspective, this incident highlights the tension between rigorous memory safety standards and practical disclosure policies within open-source projects. The issue report was closed with a statement indicating that while fixing the flaw is worthwhile for general code quality and memory safety, it did not meet the project's threshold for formal security disclosure. This decision suggests that maintainers viewed the prerequisites for exploitation as too restrictive to constitute an immediate critical threat requiring public CVE tracking or urgent patching cycles. However, from a defensive standpoint, this does not negate the severity of the underlying flaw. The combination of out-of-bounds read capabilities and available exploit code means that any environment where cluster mode is active and data directory write permissions are loosely managed remains at risk. Attackers could potentially use this vulnerability to gather information about internal memory structures or cause denial of service conditions by crashing the valkey instance during startup, thereby disrupting availability for connected clients.
Mitigation strategies must focus on strict access control and configuration hardening rather than relying solely on software patches if immediate updates are not feasible. Administrators should ensure that write permissions to the data directory containing dump.rdb files are restricted exclusively to trusted system accounts or processes with legitimate backup responsibilities. In cluster deployments, it is crucial to validate all incoming replication feeds and prevent unauthorized nodes from injecting crafted RDB payloads into the synchronization process. Additionally, enabling memory protection features such as Address Space Layout Randomization (ASLR) can mitigate the impact of out-of-bounds reads by making it harder for attackers to predict memory layouts required for successful exploitation. Regular auditing of file system permissions around persistent data stores and limiting network exposure to replication ports are essential steps to reduce the attack surface associated with this vulnerability.