CVE-2026-86227: valkey-io valkey kvstore.c kvstoreGetHashtable out-of-bounds
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."
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
valkey-io valkeyto a version that resolves this vulnerability.Patch 4691888e7fab3df128f0bde5750c9fde2ae552fa
Event History
Frequently Asked Questions
What conditions are required to exploit this issue?
The affected Valkey instance must run in cluster mode and load an attacker-controlled dump.rdb at startup. The attacker needs a position that allows them to influence stored RDB data, such as write access to the data directory, control of a replication feed, or a previously stored crafted RDB file.
Is this exploitable as an unauthenticated network attack against a running server?
No. Although the issue can be initiated remotely in some deployment paths, it is not a pre-auth network attack against a running instance; it requires attacker-controlled RDB content during startup.
What is the expected impact?
The described outcome is an out-of-bounds read that can cause a denial of service at boot. The supplied scoring indicates no confidentiality or integrity impact and limited availability impact.
What should operators do if they cannot patch immediately?
Prevent untrusted parties from writing to the Valkey data directory, injecting replication data, or placing RDB files that may be loaded at startup. Avoid starting cluster-mode instances with untrusted or unverified dump.rdb files.
How can I determine whether an instance is exposed?
Review whether the deployment uses cluster mode and whether its startup RDB can be modified through data-directory access, replication feeds, or stored RDB artifacts. Versions identified as affected are Valkey up to 9.0.5 and 9.1.1; the provided patch is 4691888e7fab3df128f0bde5750c9fde2ae552fa.