Description

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."

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-09-06T23:17:38.150Z",
  "pubdate": "2026-09-06T23:17:38.150Z",
  "executiveSummary": "A memory safety vulnerability involving an out-of-bounds (OOB) read has been identified in Valkey, affecting versions up to 9.0.5 and 9.1.1. The vulnerability exists within the kvstoreGetHashtable function in src/kvstore.c, triggered by the manipulation of the didx argument.\nThe flaw allows for an OOB read condition, potentially leading to memory access violations. While the issue is primarily classified as a memory safety defect, it carries security implications under specific environmental conditions. Exploitation is categorized as having high complexity and requires specific prerequisites, including the activation of cluster mode and the availability of an attacker-controlled dump.rdb file during the application startup process.\nThe attack vector is limited, as it is not a traditional network pre-authentication exploit, but rather an attacker-positioned denial-of-service (DoS) condition at the time of system boot. The vulnerability requires an adversary to have access to the data directory, the ability to influence replication feeds, or the capacity to place a crafted RDB file on the target system. Despite the restricted exploitation path, the availability of public exploit information necessitates proactive remediation through patching.",
  "technicalDetails": "The vulnerability resides in the src/kvstore.c file within the kvstoreGetHashtable function. The root cause is an improper validation of the didx argument, which is used as an index for internal hashtable structures. When an attacker provides a manipulated didx value, the function fails to perform adequate bounds checking before performing a memory read operation, resulting in an out-of-bounds read.\nThe exploitation process is contingent upon the operational configuration of the Valkey instance. Specifically, the vulnerability requires the server to be running in cluster mode. The attack flow involves the following prerequisites: 1) The presence of a malicious or crafted dump.rdb file at the target directory during the server boot sequence. 2) The loading of this database file by the Valkey engine. 3) The subsequent processing of the malformed data by the kvstoreGetHashtable function when attempting to retrieve hashtable entries.\nBecause the exploit relies on the initial state of the database during startup, this is characterized as an attacker-positioned DoS condition. The attacker does not interact with the running service over a network socket in a traditional pre-auth sense; rather, the vulnerability is triggered during the data ingestion phase of the server lifecycle. Successful exploitation leads to an OOB read, which could result in a segmentation fault, process crash, or, in more severe configurations, potentially reveal sensitive information residing in adjacent memory segments.\nThe affected versions are all releases up to and including 9.0.5 and 9.1.1. The function kvstoreGetHashtable is invoked as part of the internal Valkey key-space management. When the index provided for the database access (didx) exceeds the allocated capacity of the underlying arrays, the pointer arithmetic evaluates to an memory address outside the intended memory region. The lack of strict range enforcement allows the function to return or dereference data that the caller does not expect to be within the bounds of the active hashtable.\nMitigation of this vulnerability requires upgrading to a secure version that implements correct bounds checking for the didx variable, ensuring that all access to the hashtable array is guarded by validated, index-compliant logic that respects the maximum size of the data structure. System administrators must also ensure that data directories are protected against unauthorized file replacement to prevent the ingestion of malicious RDB files."
}