CVE-2026-63639 in Valkey
Summary
by MITRE • 08/18/2026
Valkey is a distributed key-value database. Prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1, Valkey's RESTORE command accepts a malformed RDB stream payload that assigns one Pending Entry List NACK to multiple consumers during stream consumer-group deserialization, causing a use-after-free when one consumer is deleted while another still references the shared NACK and potentially allowing remote code execution. This issue is fixed in versions 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
Valkey, a distributed key-value database derived from Redis, contains a critical memory safety vulnerability within its RESTORE command implementation that affects versions prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1. The core of the issue lies in how the database handles stream consumer-group deserialization when processing a malformed Redis Database (RDB) stream payload. Specifically, the vulnerability arises during the parsing of Pending Entry List Negative Acknowledgments, commonly referred to as NACKs. In this flawed logic, a single NACK entry is incorrectly assigned or shared among multiple consumers within the same consumer group rather than being isolated per consumer instance. This structural error in memory allocation and reference management creates an inconsistent state where internal pointers do not accurately reflect the actual ownership of resources.
The operational impact of this flaw manifests as a use-after-free condition, which is classified under CWE-416: Use After Free. When one consumer within the affected group is deleted or removed from the system, the underlying memory associated with its NACK entries may be freed by the garbage collection mechanism. However, because other consumers in the same group still hold references to this now-freed shared NACK data structure, any subsequent operation that accesses these stale pointers results in undefined behavior. The application attempts to dereference memory addresses that have already been released back to the operating system or reused for other purposes. This discrepancy between logical consumer state and physical memory management is a classic precursor to severe security breaches.
From an offensive perspective, this use-after-free vulnerability presents a significant risk of remote code execution if Valkey is configured to accept connections from untrusted networks without adequate authentication or network segmentation controls. An attacker can craft a malicious RDB payload that exploits the deserialization logic to trigger the double-free or dangling pointer scenario. By carefully manipulating memory layout and timing, an adversary may be able to overwrite function pointers or control flow data structures within the Valkey process space. This aligns with ATT&CK technique T1203: Exploitation for Client Execution, as it involves leveraging a software vulnerability in a server-side application to execute arbitrary code on the host system. The ability to achieve remote code execution through deserialization flaws is particularly dangerous because it bypasses many traditional input validation defenses that focus solely on command injection or SQL-like attacks.
The severity of this issue is compounded by its potential impact on data integrity and availability, in addition to confidentiality. Beyond the immediate risk of arbitrary code execution, triggering a use-after-free can cause segmentation faults leading to service crashes, resulting in denial-of-service conditions for other clients relying on the Valkey instance. Furthermore, if memory corruption leads to partial overwrites of critical database structures, it could result in data loss or corruption within the key-value stores managed by the system. This highlights the importance of treating deserialization inputs as untrusted and subjecting them to strict validation before processing.
To mitigate this vulnerability, organizations running Valkey must upgrade immediately to version 7.2.14, 8.0.10, 8.1.9, 9.0.5, or 9.1.1, where the deserialization logic has been corrected to ensure that NACK entries are properly isolated per consumer and memory is managed safely during deletion operations. In environments where immediate patching is not feasible due to operational constraints, defensive measures should include restricting access to Valkey ports via firewall rules to only trusted IP addresses or subnets. Additionally, enabling authentication mechanisms such as requirepass can prevent unauthenticated attackers from sending the malicious RESTORE commands required to trigger this exploit. Monitoring logs for unusual patterns of stream consumer group modifications and RDB restoration attempts may also aid in detecting potential exploitation activities before they result in a successful compromise.