CVE-2026-63639

Executive Summary

CVE-2026-63639 is a use-after-free (CWE-416) vulnerability in Valkey, a distributed in-memory key-value database. Prior to versions 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1, the RESTORE command accepts a malformed RDB stream payload in which a single Pending Entry List (PEL) NACK is referenced by multiple consumers during stream consumer-group deserialization; deleting one consumer while another retains a reference to the same NACK triggers the use-after-free, potentially leading to remote code execution. With a CVSS 3.1 score of 8.8 (High) and no public exploit observed at the time of writing (CISA KEV: not listed; EPSS: not yet scored), the primary risk is to authenticated or misconfigured-exposed Valkey instances used for caching, session storage, and streaming workloads.

Technical Analysis

Valkey is a distributed key-value database exposing a command-based network protocol. The RESTORE command reconstructs a key from a serialized value in RDB (Valkey's on-disk binary format), normally for backup recovery and data migration. The vulnerability is located in the deserialization path of the stream data type — specifically in the reconstruction of stream consumer groups.

In a valid stream encoding, each Pending Entry List (PEL) NACK entry tracks the state of a pending message (delivered but not yet acknowledged) and must belong to exactly one consumer. The flaw is an invariant violation during deserialization: a malformed RDB payload causes the parser to assign one NACK object to multiple consumers simultaneously, so two or more consumers hold pointers to the same heap-allocated NACK structure.

The use-after-free then follows the lifecycle mismatch. When one of the referencing consumers is deleted, the shared NACK is freed, but the remaining consumer still holds a dangling pointer to it. Any subsequent traverse of that consumer's PEL dereferences freed memory. Since the NACK structure includes pointers to stream entry metadata and consumer references, an attacker able to control heap layout can reclaim the freed chunk and convert the dangling dereference into an arbitrary read/write primitive within the Valkey server process, escalating the bug to potential remote code execution. At minimum, the condition produces a crash (denial of service) when the dangling pointer is accessed without successful heap grooming.

Attack surface: the RESTORE command is reachable over the network on exposed Valkey instances. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) indicates a network-reachable condition with low complexity that requires low privileges — in practice, valid credentials for an account permitted to execute RESTORE, or an instance where authentication has been disabled. No user interaction is required. Scope is unchanged, but confidentiality, integrity, and availability are all rated high.

Insufficient technical detail is available in the NVD description to name the specific RDB opcode, the exact malformed field layout, or a proof-of-concept payload. The analysis above is therefore derived from the described vulnerability class (deserialization-induced use-after-free in stream PEL/NACK handling) and from standard RDB/stream format knowledge; no specific function names, class names, or file paths are disclosed in the source data, so none are asserted in this report.

Exploitation Scenarios

No public PoC or exploit code is available for CVE-2026-63639 as of this writing. The attack chain below is inferred strictly from the vulnerability class described in the NVD entry and from general knowledge of the RESTORE/RDB mechanism.

1. Reconnaissance / target identification. The attacker identifies Valkey instances reachable over the network, typically by service-banner fingerprinting on the default TCP port commonly used by Valkey (6379) or by the server's response to status/handshake commands that disclose the version banner. Because the flaw requires low privileges (PR:L), the attacker additionally determines whether authentication is enforced and whether acceptable credentials are obtainable (weak or leaked credentials, a shared low-privileged service account, or a deliberately unauthenticated deployment).

2. Triggering the vulnerability class. The attacker authenticates and issues the RESTORE command with a crafted serialized value: an RDB-format byte stream representing a key of the stream data type. Within the stream consumer-group metadata, the payload is arranged so that a single PEL NACK is associated with more than one consumer. During deserialization, the parser accepts the duplicated reference and constructs an invalid consumer-group structure in which multiple consumers point to the same NACK object — violating the one-owner-per-NACK invariant. This stage requires a valid authenticated session and the RESTORE privilege, which matches the CVSS prerequisites.

3. Payload / execution method (vulnerability-class level). With the poisoned structure in place, the attacker deletes one of the referencing consumers, causing the shared NACK to be freed while the other consumer retains a dangling reference. A subsequent operation that reads or writes through that consumer's PEL dereferences the freed NACK. If the attacker can groom the heap so that the freed chunk is reallocated with attacker-controlled data, the resulting use-after-free can be turned into an arbitrary read/write and — in the worst case — code execution in the context of the Valkey server process. If heap manipulation is not achieved, the same access simply crashes the server, yielding denial of service.

4. Post-exploitation impact. On successful exploitation, the attacker gains the ability to read, modify, and delete any data held in the Valkey instance, including all tenants' keys, cached secrets, sessions, and stream state, and to corrupt or destroy stream consumer-group data. Code execution within the server process additionally enables host-level compromise under the privileges of the service account, allowing lateral movement to adjacent systems and persistence in the environment.

Impact Assessment

CVE-2026-63639 carries a CVSS 3.1 base score of 8.8 (High) with severity distributed across all three core metrics (C:H/I:H/A:H). The low-privilege requirement (PR:L) is meaningful: in a properly configured deployment, the attacker must already hold a database account, but in multi-tenant platforms where low-privileged tenants share an instance, any tenant that can execute RESTORE becomes a potential path to full data compromise. Deployments that expose Valkey without authentication turn the primitive into an effectively unauthenticated remote compromise.

Business impact:

• Availability: the easiest observable outcome is a crash-based denial of service on a production cache, session store, or stream-processing backend.
• Confidentiality/integrity: in the code-execution scenario, the attacker can exfiltrate cached application data (PII, tokens, business state) and silently modify the data plane.
• Supply/operational risk: Valkey instances used as queue/orchestration backends can be manipulated to disrupt downstream workers.

Blast radius is limited to the affected server process in the default configuration (scope unchanged), but is amplified by Valkey's typical role as a shared infrastructure component: one compromised instance can invalidate sessions globally, poison caches, and become a beachhead for host and network pivoting. The absence of an EPSS score, a CISA KEV listing, and public exploit code means that the threat is currently theoretical but carries a high CVSS that warrants proactive remediation planning.

Detection Guidance

Detection of CVE-2026-63639 is challenging because the malicious artifact is a binary RDB payload and no byte-level signature has been publicly documented. The rules below focus on observable behaviors: execution of the RESTORE command, abnormally large serialized values traversing the network, and the crash signature that follows a use-after-free (segmentation fault) in the Valkey server process. Log sources will vary by deployment; rules that depend on command logging require an audit or slow-query logging layer that records executed commands.

Sigma Rule

title: Valkey RESTORE Command with Potential Malformed RDB Stream Payload
id: 6a3c3f0e-5d2f-4c7a-9a1e-2f7e6a8a4b10
status: experimental
description: Detects invocation of the RESTORE command against a Valkey server. RESTORE is the trigger for CVE-2026-63639, a use-after-free in stream consumer-group deserialization reachable via a malformed RDB payload. Requires a command-audit or slow-log source.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-63639
author: Valtersit Threat Intelligence
date: 2026-02-10
logsource:
    product: valkey
    service: server
detection:
    selection:
        - EventID: "SLOWLOG"
          Command|contains: "RESTORE"
        - EventID: "COMMAND"
          Command|contains: "RESTORE"
    condition: selection
falsepositives:
    - Legitimate backup-restore and migration workflows that intentionally use RESTORE
level: high

YARA Rule

rule CVE_2026_63639_Valkey_RESTORE_Stream_Heuristic
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Heuristic detection of scripts, PCAPs, or RDB artifacts that reference RESTORE together with stream consumer-group indicators used by CVE-2026-63639."
        cve = "CVE-2026-63639"
        cwe = "CWE-416"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-63639"
        date = "2026-02-10"
    strings:
        $cmd = "RESTORE" ascii wide
        $stream = "stream" ascii wide nocase
        $cg = "consumer-group" ascii wide nocase
        $pel = "pending" ascii wide nocase
    condition:
        $cmd and (#stream >= 1 or #cg >= 1 or #pel >= 1) and filesize < 10MB
}

Note: this is a heuristic rule. The binary RDB payload itself has no disclosed fixed byte pattern; positives must be validated by inspecting the surrounding context for RESTORE/RDB activity.

Suricata IDS Rule

alert tcp any any -> any 6379 (msg:"CVE-2026-63639 potential Valkey RESTORE exploit attempt"; flow:established,to_server; content:"RESTORE"; nocase; pcre:"/(?i)\$[0-9]{6,}\r\n/"; classtype:attempted-admin; sid:2026639; rev:1; metadata:cve CVE-2026-63639;)

Explanation: the rule matches the RESTORE keyword in the server-bound TCP stream followed by a RESP bulk-string header of at least 100,000 bytes ($ plus six or more digits), consistent with a large RDB serialized payload carrying stream consumer-group data. The default port 6379 is assumed and should be adapted to the monitored deployment. Because the malformed NACK structure is binary and undocumented, deeper payload inspection is not feasible in signature form.

Elastic Detection

sequence by host.id with maxspan=10m
  [ network where network.transport == "tcp"
      and destination.port == 6379
      and process.name : "*valkey*" ]
  [ process where event.action == "end"
      and process.exit_code == 139
      and process.name : "*valkey*" ]

Rationale: exit code 139 indicates a segmentation fault. A TCP connection to the Valkey server process followed shortly by that process crashing is consistent with a use-after-free triggered through a malformed RESTORE payload. Tune the port and process-name patterns to the local environment; installations that run the server under a different process name require adjustment.

Splunk SPL Query

index=* (sourcetype="valkey*" OR source="*valkey*.log")
| rex field=_raw "RESTORE\s+[^\s]+\s+\d+\s+\$?(?<payload_size>[0-9]{6,})"
| search payload_size=*
| table _time host src dest Command payload_size
| sort - _time

Complementary crash-detection query:

index=* (sourcetype="valkey*" OR source="*valkey*.log")
| search "RESTORE" OR "SIGSEGV" OR "segmentation fault" OR "signal 11"
| table _time host source _raw
| sort - _time

The first query flags RESTORE invocations carrying bulk payloads of 100,000 bytes or more; the second correlates RESTORE activity with process-crash indicators. Both depend on Valkey command/slow-log data being forwarded to the SIEM.

Wazuh OSSEC Rule

<group name="valkey,">
    <rule id="100636" level="12">
        <decoded_as>json</decoded_as>
        <field name="command">RESTORE</field>
        <description>CVE-2026-63639: Valkey RESTORE command with possible malformed RDB stream payload (use-after-free)</description>
        <group>valkey,attacks,pci_dss_11.4,gdpr_IV_35.7.d,</group>
    </rule>

    <rule id="100637" level="10">
        <if_sid>100636</if_sid>
        <match>signal 11|SIGSEGV|segmentation fault|AddressSanitizer</match>
        <description>CVE-2026-63639: Valkey crash after RESTORE - suspected use-after-free</description>
        <group>valkey,attacks,</group>
    </rule>
</group>

The first rule alerts on RESTORE command activity; the second correlates a subsequent crash (SIGSEGV handler output or sanitizer report) with that earlier activity. Local rule IDs must be verified to avoid conflicts with existing Wazuh rules.

Mitigation & Patch Guidance

Patch confidence for this CVE is 0/4 — no patch evidence was identified from any tracked source, and no vendor fix record or workaround was provided. Note that the NVD description itself lists fixed versions (7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1). Until those releases are independently verified from the official Valkey distribution channel, treat affected systems as effectively unpatched.

1. Immediate mitigations:

   • Enforce authentication on all Valkey instances; do not expose the database port to untrusted networks. Apply firewall rules or VPN-only access for the port used by Valkey (commonly 6379).
   • If the deployment supports command-level access control or command renaming, restrict or disable the RESTORE command for low-privileged/untrusted principals. Before doing so, assess the impact on legitimate backup and migration jobs.
   • Deploy the detection rules above (command-level logging, crash correlation) to catch early exploitation attempts or crash events.
   • Prefer running Valkey in an isolated network segment with no direct internet exposure.

2. Patch/upgrade steps:

   • Plan an upgrade to the appropriate fixed version for your branch: 7.2.14, 8.0.10, 8.1.9, 9.0.5, or 9.1.1, once the release artifacts are confirmed from the official Valkey channel. Validate checksums, test in a staging environment with stream and consumer-group workloads, run regression tests, then roll out to production.
   • Until the upgrade is completed, audit the exposure of RESTORE-capable accounts and remove unnecessary credentials.

3. Long-term hardening:

   • Run the Valkey server under a least-privilege operating-system account; enable TLS for all client connections; enable core-dump and crash logging to support forensic analysis.
   • Establish a patch cadence that keeps the database within one or two releases of the latest branch, and subscribe to Valkey security advisories.
   • For multi-tenant environments, isolate tenants into separate instances or namespaces so that a low-privileged tenant cannot reach RESTORE on another tenant's data.

References

1. NVD — CVE-2026-63639: https://nvd.nist.gov/vuln/detail/CVE-2026-63639
2. MITRE CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-63639
3. CWE-416 Use After Free: https://cwe.mitre.org/data/definitions/416.html
4. CISA Known Exploited Vulnerabilities Catalog (CVE-2026-63639 is NOT listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
5. Valkey project — official release channel and security advisories (a direct vendor advisory URL was not included in the source data; verify fixed versions via the upstream project before deployment)

No threat-actor campaigns or exploit-in-the-wild evidence tied to CVE-2026-63639 are known as of this report. The FIRST.org EPSS score has not been published for this CVE; no EPSS value is asserted here.