CVE-2026-63639: 
Rocky Linux vulnerability analysis and mitigation

CVE-2026-63639 is a use-after-free vulnerability in Valkey's RESTORE command that can lead to remote code execution. The flaw exists in Valkey's stream consumer-group RDB deserialization logic, where a malformed RDB payload can assign a single Pending Entry List (PEL) NACK to multiple consumers, causing a use-after-free when one consumer is deleted while another still holds a reference to the shared NACK. All versions prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1 are affected. The vulnerability was reported by researchers z0v3r1n and Lifip, disclosed via GitHub Security Advisory on July 22, 2026, and published to NVD on August 18, 2026. It carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Feedly).

The root cause is a use-after-free (CWE-416) in src/rdb.c within the rdbLoadObject function. When loading a stream consumer group from an RDB payload, the loader assigns each NACK's consumer pointer without first verifying whether it had already been assigned to a different consumer. A crafted RDB payload can list the same message ID under multiple consumers' PELs, resulting in a shared streamNACK structure. When one consumer is subsequently deleted, the NACK is freed, but the other consumer's PEL still holds a dangling pointer to it — a classic use-after-free condition. The fix adds a check that nack->consumer is NULL before assignment; if already set to a different consumer, the RDB is rejected as corrupt via rdbReportCorruptRDB. Exploitation requires low-privilege authenticated access to issue the RESTORE command with a specially crafted payload (GitHub Advisory, GitHub PR #4073, Commit 06bc776).

Successful exploitation can result in arbitrary code execution within the Valkey server process, with full confidentiality, integrity, and availability impact. An attacker who achieves code execution on the Valkey instance could exfiltrate all stored key-value data, manipulate or destroy data, crash the service, or use the compromised server as a pivot point for lateral movement within the network. Given that Valkey is commonly used as a caching or session store, a breach could expose sensitive application data such as session tokens, credentials, or business-critical information (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Feedly). The NVD SSVC assessment classifies exploitation as "none" and the attack as not automatable, reflecting the requirement for low-privilege authentication. The EPSS score is approximately 0.0089 (less than 1%), indicating a currently low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Detection coverage is available via Nessus (plugins 331316, 331338, 331468, 331557, 332123) and Qualys (363410) (Feedly).

1. Gain authenticated access: Obtain low-privilege credentials to a vulnerable Valkey instance (any version before 7.2.14, 8.0.10, 8.1.9, 9.0.5, or 9.1.1) with permission to execute the RESTORE command.
2. Craft a malformed RDB payload: Construct a stream RDB dump in which a single message ID appears in the Pending Entry List (PEL) of two or more consumers within the same consumer group. This can be done by taking a valid DUMP output and replacing a consumer's PEL message ID bytes with those of another consumer's message ID (e.g., replacing the big-endian bytes of message ID 2-1 with those of 1-1 in the consumer2 PEL section).
3. Send the RESTORE command: Issue RESTORE <key> 0 <malformed_payload> to the target Valkey server, bypassing CRC checksum validation if necessary (e.g., using debug flags in a test environment, or crafting a payload with a valid checksum).
4. Trigger use-after-free: The server deserializes the corrupt RDB, assigning the same streamNACK pointer to multiple consumers. When one consumer is subsequently deleted (e.g., via XGROUP DELCONSUMER), the shared NACK is freed while the other consumer's PEL still holds a dangling reference.
5. Achieve code execution: Exploit the dangling pointer through memory corruption techniques to redirect execution flow and achieve arbitrary code execution within the Valkey process (GitHub Advisory, GitHub PR #4073).

• Network: Unexpected or anomalous RESTORE command traffic to Valkey ports (default 6379/tcp) from unusual source IPs or at unusual times; large binary payloads in RESTORE commands that do not match expected application patterns.
• Logs: Valkey server logs showing Bad data format errors on RESTORE commands (indicating attempted exploitation against patched versions); crash logs or core dumps from the Valkey process; unexpected XGROUP DELCONSUMER commands following RESTORE operations.
• Process: Valkey process crashing or restarting unexpectedly; unusual child processes spawned by the Valkey server process; unexpected outbound network connections from the Valkey host.
• File System: Unexpected files written to the Valkey working directory or system temp directories; new cron jobs or scheduled tasks created under the Valkey service account (GitHub Advisory, Feedly).

Upgrade Valkey to one of the patched versions: 7.2.14, 8.0.10, 8.1.9, 9.0.5, or 9.1.1, depending on the currently deployed branch. As a temporary workaround without patching, restrict access to the RESTORE command using Valkey ACLs (ACL SETUSER <user> -RESTORE) or by disabling/renaming the command in valkey.conf (e.g., rename-command RESTORE ""). Additionally, restrict network access to Valkey instances so that only trusted, authenticated clients can connect, reducing the attack surface (GitHub Advisory, SUSE Advisory).

SUSE issued security update advisories (SUSE-SU-2026:3427-1 and SUSE-SU-2026:3483-1) for affected Valkey packages, and openSUSE published corresponding security announcements (SUSE Advisory). Amazon Linux 2023 also released an advisory (ALAS2023-2026-2011). The vulnerability received coverage from Linux security news outlets and was tracked by multiple vulnerability intelligence platforms including VulDB, CVEFeed, and CIRCL. Community reaction has been measured, consistent with the absence of public exploit code and the relatively straightforward patch.