Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-56684

CVE-2026-56684: Valkey Use-After-Free Vulnerability

CVE-2026-56684 is a use-after-free vulnerability in Valkey distributed key-value database that can crash servers or enable remote code execution when TLS is enabled. This article covers technical details, affected versions, security impact, and mitigation strategies.

Published:

CVE-2026-56684 Overview

Valkey is a distributed key-value database derived from the Redis codebase. CVE-2026-56684 is a use-after-free vulnerability [CWE-416] in the tlsProcessPendingData function in src/tls.c. An authenticated client can issue a CLIENT KILL command while the server iterates the pending_list, causing connTLSClose to delete the iterator's cached next node. The dangling pointer can crash the server or potentially enable remote code execution when Transport Layer Security (TLS) is enabled. The issue affects Valkey versions prior to 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1.

Critical Impact

Authenticated attackers can trigger a use-after-free in TLS-enabled Valkey instances, resulting in server crashes or possible remote code execution.

Affected Products

  • Valkey versions prior to 7.2.14
  • Valkey versions prior to 8.0.10 and 8.1.9
  • Valkey versions prior to 9.0.5 and 9.1.1

Discovery Timeline

  • 2026-08-18 - CVE-2026-56684 published to the National Vulnerability Database (NVD)
  • 2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-56684

Vulnerability Analysis

The defect resides in the TLS I/O path of Valkey. The tlsProcessPendingData function walks pending_list using a listIter and dispatches each connection to tlsHandleEvent. Event handling can execute client commands synchronously on the same thread.

When an authenticated client issues CLIENT KILL targeting another connection, the control flow reaches freeClient and then connTLSClose, which calls listDelNode on the killed connection's node in pending_list. If the freed node is the iterator's cached next node, the subsequent listNext call dereferences freed memory.

The result is a classic use-after-free. On TLS-enabled deployments, the primitive is reachable by any authenticated client without special privileges, which broadens the exposure to any tenant with connection rights.

Root Cause

The root cause is iterator invalidation. listRewind and listNext from the intrusive linked list implementation cache the next node ahead of time. Any code path that removes list nodes during iteration violates that invariant. tlsHandleEvent reentrantly invokes command handlers that can free arbitrary connections, including nodes still referenced by the iterator.

Attack Vector

Exploitation requires network access to a TLS-enabled Valkey instance and authenticated credentials with permission to run CLIENT KILL. The attacker opens a connection with pending TLS data, triggers command dispatch, and issues CLIENT KILL against a peer connection queued on pending_list. The freed node is then reused when iteration continues, producing memory corruption.

c
// Security patch in src/tls.c - Fix use-after-free in tlsProcessPendingData()
// on CLIENT KILL (PR #4234)

static int tlsProcessPendingData(void) {
    listNode *ln;

    int processed = 0;
    /* Pop each connection off the list before handling it. A handler may
     * synchronously free another pending connection (e.g. CLIENT KILL ->
     * freeClient -> connTLSClose -> listDelNode), so we must not hold an
     * iterator into a node that could be freed out from under us.
     *
     * Connections with buffered data re-add themselves to the tail, so the
     * length captured on entry bounds the loop and guarantees termination. */
    unsigned long remaining = listLength(pending_list);
    while (remaining-- > 0 && (ln = listFirst(pending_list)) != NULL) {
        tls_connection *conn = listNodeValue(ln);
        listDelNode(pending_list, ln);
        conn->pending_list_node = NULL;
        tlsHandleEvent(conn, AE_READABLE);
        processed++;
    }
    return processed;
}

Source: GitHub Commit 7cd5bcb. The fix removes iterator-based traversal and instead pops the head of pending_list on each iteration, capturing the initial length to bound the loop.

Detection Methods for CVE-2026-56684

Indicators of Compromise

  • Unexpected valkey-server process crashes or SIGSEGV entries in system logs on TLS-enabled instances.
  • Repeated CLIENT KILL commands issued from a single authenticated client in a short window, visible in Valkey command logs or slowlog.
  • Abnormal patterns of TLS connections that establish, buffer data, and terminate rapidly.

Detection Strategies

  • Enable Valkey command auditing and forward logs to a central data lake to identify sequences of CLIENT KILL correlated with server restarts.
  • Monitor process supervision systems (systemd, Kubernetes) for valkey-server restart loops.
  • Inspect running Valkey versions via the INFO server command and flag any release below the fixed versions listed above.

Monitoring Recommendations

  • Alert on any core dumps produced by valkey-server and preserve them for forensic review.
  • Track authentication events and correlate authenticated sessions with administrative commands such as CLIENT KILL.
  • Baseline connection churn on TLS listeners and alert when kill rates exceed normal operational thresholds.

How to Mitigate CVE-2026-56684

Immediate Actions Required

  • Upgrade Valkey to 7.2.14, 8.0.10, 8.1.9, 9.0.5, or 9.1.1 depending on the deployed branch.
  • Restrict network access to Valkey listeners so only trusted application tiers can reach the TLS port.
  • Audit Access Control List (ACL) entries and remove CLIENT KILL permissions from accounts that do not require them.

Patch Information

The upstream fix is tracked in GitHub Pull Request #4234 and landed in commit 7cd5bcb. Fixed builds are published in Valkey 7.2.14, Valkey 8.0.10, Valkey 8.1.9, Valkey 9.0.5, and Valkey 9.1.1. See the GitHub Security Advisory GHSA-53mc-f3m3-99vh for coordinated disclosure details.

Workarounds

  • Disable TLS listeners if operationally acceptable until patched builds are deployed, since the vulnerability path is specific to tlsProcessPendingData.
  • Use Valkey ACLs to deny the CLIENT|KILL subcommand for non-administrative users: ACL SETUSER <user> -CLIENT|KILL.
  • Place Valkey behind a network policy that limits authenticated clients to trusted service accounts.
bash
# Verify running version and revoke CLIENT KILL from application accounts
valkey-cli -h <host> -p <port> --tls INFO server | grep valkey_version
valkey-cli -h <host> -p <port> --tls ACL SETUSER appuser -CLIENT|KILL

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.