Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-18T15:16:56.627Z",
  "pubdate": "2026-08-18T15:16:56.627Z",
  "executiveSummary": "A use-after-free vulnerability exists in Valkey, a distributed key-value database, specifically within the stream consumer-group deserialization mechanism of the RESTORE command.\nThe vulnerability allows a remote attacker to supply a malformed RDB stream payload that assigns a single Pending Entry List (PEL) NACK object to multiple distinct consumers simultaneously.\nWhen one of the consumers is subsequently deleted, the shared NACK object is freed while remaining referenced by the other consumer, triggering a use-after-free condition.\nSuccessful exploitation of this flaw can lead to memory corruption and potentially allow remote code execution within the context of the Valkey server process.\nThe vulnerability affects Valkey prior to versions 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1.\nMitigation requires upgrading Valkey to the specified patched versions where the stream consumer-group deserialization logic safely handles PEL NACK object allocation and reference management.",
  "technicalDetails": "The root cause of the vulnerability resides in the stream consumer-group deserialization routine invoked during the processing of the Valkey RESTORE command.\nWhen parsing a specially crafted or malformed RDB stream payload containing stream consumer groups, the deserialization logic improperly assigns a single Pending Entry List (PEL) NACK data structure to multiple consumers concurrently instead of instantiating unique instances or correctly managing reference counts.\nThis design flaw introduces a memory management anomaly where multiple consumer entities point to the exact same heap memory allocation representing a PEL NACK.\nThe step-by-step attack flow begins with an authenticated client issuing a crafted RESTORE command containing the malicious RDB stream payload to the Valkey server.\nUpon ingestion, the Valkey database deserializes the stream data, constructs the consumer group structures, and populates the consumers with the malformed PEL references.\nSubsequently, when an administrative action, client interaction, or automated garbage collection routine deletes one of the referencing consumers, the underlying memory manager deallocates the shared PEL NACK object.\nHowever, the surviving consumer retains a dangling pointer to the now-freed memory address.\nA subsequent operation that interacts with or modifies the remaining consumer accesses the dangling pointer, resulting in a use-after-free condition.\nDepending on heap layout dynamics and subsequent memory re-allocations, this primitive can be leveraged by a sophisticated attacker to achieve arbitrary memory corruption, potentially leading to remote code execution on the target host running Valkey.\nThe vulnerable component is the RDB stream deserialization module handling consumer groups in the RESTORE command.\nAffected software versions include Valkey prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1."
}