CVE-2026-63639: Valkey Database RCE Vulnerability

CVE-2026-63639 Overview

CVE-2026-63639 is a use-after-free vulnerability [CWE-416] in Valkey, an open-source distributed key-value database and Redis fork. The flaw exists in the RESTORE command's stream consumer-group deserialization logic. A malformed RDB stream payload can assign a single Pending Entry List (PEL) NACK structure to multiple consumers. When one consumer is deleted, other consumers still reference the freed NACK, triggering memory corruption that may lead to remote code execution.

Critical Impact
An authenticated attacker with permission to issue RESTORE commands can trigger memory corruption via a crafted RDB stream payload, potentially achieving remote code execution on the Valkey server.

Affected Products

Valkey versions prior to 7.2.14
Valkey 8.x versions prior to 8.0.10 and 8.1.9
Valkey 9.x versions prior to 9.0.5 and 9.1.1

Discovery Timeline

2026-08-18 - CVE-2026-63639 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-63639

Vulnerability Analysis

Valkey supports stream data structures with consumer groups, where each consumer maintains a Pending Entries List (PEL) tracking messages that have been delivered but not acknowledged. Each PEL entry uses a NACK (Not-ACKnowledged) structure containing metadata and a pointer to the owning consumer.

During RDB deserialization, Valkey rebuilds the global PEL first, then walks each consumer's PEL and links its entries back to the shared NACK objects. The vulnerable code does not validate that a NACK is assigned to only one consumer. A crafted RDB payload can reference the same NACK from multiple consumer PELs, creating aliased ownership of a heap object.

When any consumer is subsequently deleted through commands such as XGROUP DELCONSUMER, Valkey frees the shared NACK. Any remaining consumer that still references it operates on freed memory, resulting in a classic use-after-free condition exploitable for code execution.

Root Cause

The root cause is missing validation in src/rdb.c during stream consumer-group loading. The deserialization loop assigns nack->consumer = consumer without first checking whether the NACK was already bound to a different consumer, allowing shared ownership of a structure whose lifecycle assumes single ownership.

Attack Vector

Exploitation requires network access and low privileges — specifically, permission to execute the RESTORE command or to influence RDB data ingested by the server (for example, via replication or module-driven loading). No user interaction is required. The attacker crafts a malformed RDB stream payload with duplicated NACK references across consumers, triggers RESTORE, then deletes one of the aliased consumers to free the shared NACK while dangling references remain.

                     /* Set the NACK consumer, that was left to NULL when
                      * loading the global PEL. Then set the same shared
                      * NACK structure also in the consumer-specific PEL. */
+                    if (nack->consumer && nack->consumer != consumer) {
+                        rdbReportCorruptRDB("NACK already assigned to a different consumer, "
+                                            "shared NACKs across consumers are not valid");
+                        decrRefCount(o);
+                        return NULL;
+                    }
                     nack->consumer = consumer;
                     if (!raxTryInsert(consumer->pel, rawid, sizeof(rawid), nack, NULL)) {
                         rdbReportCorruptRDB("Duplicated consumer PEL entry "

Source: GitHub Commit 06bc776. The patch rejects any RDB payload where a NACK is already bound to a different consumer and aborts loading with a corruption report.

Detection Methods for CVE-2026-63639

Indicators of Compromise

Valkey server crashes or unexpected restarts following RESTORE commands issued against stream keys.
Log entries containing rdbReportCorruptRDB messages, particularly referencing consumer PEL entries or NACK assignment.
Unexpected XGROUP DELCONSUMER operations issued shortly after RESTORE calls from the same client.

Detection Strategies

Inspect Valkey audit and command logs for RESTORE operations targeting stream keys, especially from low-privileged accounts.
Correlate RESTORE invocations with subsequent consumer-group modifications on the same key within a short time window.
Monitor process crash telemetry and core dumps on Valkey hosts for signals of heap corruption during stream operations.

Monitoring Recommendations

Enable Valkey ACL logging and forward events to a centralized analytics platform for correlation across command sequences.
Alert on any occurrence of RDB corruption messages emitted by the server, since these are rare under normal operation.
Track version inventory of Valkey deployments and flag any node not running a patched build.

How to Mitigate CVE-2026-63639

Immediate Actions Required

Upgrade Valkey to 7.2.14, 8.0.10, 8.1.9, 9.0.5, or 9.1.1 depending on your deployed branch.
Restrict RESTORE command permissions via Valkey ACLs so only trusted administrative accounts can invoke it.
Audit existing ACL policies and remove RESTORE from default or application-tier user roles.

Patch Information

The Valkey maintainers released fixes across all supported branches. Refer to the GitHub Security Advisory GHSA-mvcj-73cw-22m4 and the merged fix in GitHub Pull Request #4073. Patched releases are available at v7.2.14, v8.0.10, v8.1.9, v9.0.5, and v9.1.1.

Workarounds

Deny the RESTORE command in ACL rules for all non-administrative users until patching is complete.
Isolate Valkey instances behind network policies that block untrusted client access to the command port.
Disable or restrict replication and RDB loading paths from any source that is not fully trusted.

bash

# Restrict RESTORE via Valkey ACL for application users
ACL SETUSER appuser on >strongpassword ~* +@all -restore -debug -config

# Verify installed version is patched
valkey-cli INFO server | grep valkey_version