CVE-2026-56684

Executive Summary

CVE-2026-56684 is a use-after-free (UAF) vulnerability in Valkey, an open-source distributed key-value database, affecting all TLS-enabled deployments prior to versions 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1. An authenticated client can trigger the CLIENT KILL command while the server's tlsProcessPendingData function is iterating the connection pending list, causing connTLSClose to free a node cached by the iterator; subsequent dereference yields memory corruption that can crash the server or, in a worst-case scenario, lead to remote code execution. Organizations running Valkey with TLS termination on the database server itself are at risk and should restrict access to the TLS port and prioritize upgrade validation despite the absence of tracked patch artifacts.

Technical Analysis

The vulnerability resides in Valkey's TLS event-processing path. When a client connection uses TLS, Valkey buffers incoming and outgoing data in an internal linked structure referenced in the advisory as pending_list. The function tlsProcessPendingData walks this list, maintaining a cached pointer to the next node so that iteration can resume after processing the current entry.

The flaw is triggered by command interleaving on the same authenticated connection. While tlsProcessPendingData is mid-iteration, an authenticated client is able to issue the CLIENT KILL command against itself or an associated connection. Handling CLIENT KILL invokes connection teardown logic that ends at connTLSClose. This close routine tears down the TLS state and frees the pending-list nodes belonging to that connection — including the node that the iterator in tlsProcessPendingData has cached as its "next" pointer.

When the iterator resumes and dereferences that freed cached node, the server operates on dangling heap memory. This behavior matches CWE-416 (Use-After-Free). The consequences depend on heap state and the attacker's ability to shape allocation patterns: at minimum, the corrupted iteration results in a segmentation fault and server crash (denial of service); with careful heap grooming, an attacker could potentially overwrite function pointers or other control data reachable from the freed node to achieve arbitrary code execution within the valkey-server process.

Several factors shape the attack surface:

• The vulnerable code path is only compiled and exercised when Valkey is built with TLS support and a tls-port is configured; pure plaintext deployments are not affected.
• The attacker must already be an authenticated client (CVSS PR:L), meaning the initial authentication bypass is not part of this CVE — the bug is a post-authentication memory-corruption primitive.
• The attack requires precise timing to win the race between list iteration and connection teardown, which explains the elevated Attack Complexity (AC:H) in the CVSS vector.
• Because the primitive is a single freed-node dereference on the heap, the likely worst realistic outcome is a reliable crash, with RCE remaining theoretically possible but contingent on heap layout control — detailed exploitation data is not yet public.

There is insufficient public technical detail beyond the NVD description to enumerate the exact structure of pending_list, the precise call path from CLIENT KILL parsing to connTLSClose, or the availability of heap-spray gadgets in the Valkey binary. Analysts should treat this as a classic iterator-invalidation bug in a network-facing, memory-unsafe code path.

Exploitation Scenarios

No public proof-of-concept has been observed, and the NVD entry lists no exploit code. The following attack chain is therefore inferred strictly from the vulnerability class and the mechanism described in the advisory.

1. Reconnaissance / target identification. An attacker scans the network for Valkey servers exposing TLS-enabled listener ports, identifiable via service banners, TLS certificate metadata, or protocol handshake responses. Shodan-style queries such as port:6379 valkey or product:valkey would surface candidate hosts. The attacker also needs valid credentials; if weak or leaked passwords are used, an unprivileged authenticated session can be established. In default configurations where requirepass is unset but TLS is enabled, the PR:L requirement may be trivially satisfied.

2. Flaw-class triggering. The attacker opens a TLS connection to the target and sends commands at the application layer in a deliberate interleaving pattern: first, ensure that data is present on the connection's pending_list (e.g., by sending pipelined or partially-read requests); then, while the server is inside tlsProcessPendingData, issue CLIENT KILL targeting the same connection. This forces connTLSClose to free the pending-list node that the iterator has cached, invalidating the iterator's forward reference.

3. Payload / execution method (vulnerability-class level). Because this is a use-after-free, exploitation at the class level requires heap manipulation: after the free occurs, the attacker attempts to reallocate the freed chunk with controlled data (classic heap grooming) before the iterator dereferences it. The controlled contents of the reallocated node can influence what the stale pointer references — potentially a fake node structure with attacker-controlled fields that the iteration logic trusts, ultimately redirecting execution or corrupting adjacent heap metadata. Absent a grooming primitive on the same code path, the dereference will simply touch freed or reallocated memory and crash the process.

4. Post-exploitation impact. On crash-only failure, the impact is denial of service: the Valkey server process exits and, depending on supervision configuration, may restart with data-loss risks from unsaved writes. On successful code execution, the attacker inherits the privileges of the valkey-server process — typically a dedicated service account — enabling theft of all keyspace data, modification of cached data, credential harvesting from stored values, and possibly lateral movement if the host is otherwise weakly segmented. Because a real Cassandra/Redis-style key-value store frequently backs session state and application caches, an RCE outcome can cascade into broader application compromise.

Impact Assessment

The CVSS v3.1 base score is 7.5 (High) with vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. The vector indicates a network-reachable vulnerability that does not require user interaction, is difficult to exploit reliably due to race conditions, and requires only low-privilege (authenticated) access, but that would — if fully exploited — yield complete compromise of confidentiality, integrity, and availability of the affected process.

Business impact focuses on any organization that:

• Runs Valkey with TLS enabled (tls-port configured) in production;
• Exposes those TLS listeners beyond the trusted network boundary;
• Uses weak or default authentication, which downgrades the PR:L requirement in practice;
• Stores session tokens, feature flags, rate-limit counters, or cached user data whose disclosure or manipulation would violate compliance obligations (GDPR, PCI-DSS, HIPAA).

Blast radius is broad because Valkey is a drop-in fork of Redis and is deployed in the same niches: caching layers, message brokering, session stores, and in-memory databases. A crash in the TLS path can take down the whole keyspace for all connected applications, not just the malicious session. The high-impact confidentiality/integrity ratings are justified by the RCE potential noted in the advisory; however, until a reliable exploit is demonstrated, security teams should plan for a realistic worst case of repeated denial-of-service with a less probable escalation to code execution.

Detection Guidance

The rules below are written to flag (a) the issuance of CLIENT KILL against Valkey TLS connections, (b) crash artifacts referencing the vulnerable symbols, and (c) the temporal correlation of the two, which is the strongest observability signal available for this race condition.

Sigma Rule

title: Valkey CLIENT KILL Preceding TLS Use-After-Free Crash
id: 5a4b0d3e-2f6a-4c99-9b1e-cve202656684
status: experimental
description: Detects Valkey server crash events correlated with CLIENT KILL command execution, indicating possible attempted exploitation of CVE-2026-56684.
logsource:
  category: application
  product: linux
detection:
  selection_kill:
    event.category: command
    command: "CLIENT KILL"
  selection_crash:
    message|contains:
      - "tlsProcessPendingData"
      - "connTLSClose"
      - "use-after-free"
      - "Segmentation fault"
      - "AddressSanitizer: heap-use-after-free"
  timeframe: 30s
  condition: selection_kill followed by selection_crash
falsepositives:
  - Legitimate administrative session termination coinciding with an unrelated crash
level: high

YARA Rule

rule CVE_2026_56684_Valkey_TLS_UAF_Crash
{
    meta:
        author = "ValterIT Threat Intelligence"
        description = "Detects crash dumps, core files, or memory captures containing symbols associated with the Valkey TLS use-after-free (CVE-2026-56684)"
        cve = "CVE-2026-56684"
        date = "2026-05-01"
    strings:
        $s1 = "tlsProcessPendingData" ascii nocase
        $s2 = "connTLSClose" ascii nocase
        $s3 = "pending_list" ascii nocase
        $s4 = "CLIENT KILL" ascii nocase
    condition:
        any of ($s1, $s2, $s3) and any of ($s2, $s4) or filesize < 2MB and all of them
}

Suricata IDS Rule

alert tcp any any -> $VALKEY_SERVERS 6379 ( \
  msg:"ET EXPLOIT Valkey CVE-2026-56684 CLIENT KILL Command Attempt Over TLS-Enabled Listener"; \
  flow:established,to_server; \
  content:"CLIENT"; nocase; \
  content:"KILL"; within:10; nocase; \
  pcre:"/^CLIENT\\s+KILL/im"; \
  classtype:attempted-admin; \
  sid:20265668401; rev:1; \
  reference:cve,2026-56684;)

Note: for deployments where Valkey TLS is terminated on a dedicated TLS port, this rule requires TLS inspection (decryption) at the sensor, or placement on an internal segment where traffic is already decrypted. In the absence of decryption visibility, rely on host-based crash correlation rules instead.

Elastic Detection

sequence by host.id with maxspan=1m
  [ any where process.name == "valkey-server" and (
      message contains "CLIENT KILL" or
      message contains "client kill"
    ) ]
  [ any where process.name == "valkey-server" and (
      message contains "tlsProcessPendingData" or
      message contains "connTLSClose" or
      message contains "Segmentation fault" or
      message contains "heap-use-after-free"
    ) ]

Splunk SPL Query

index=main sourcetype=valkey*
  ("CLIENT KILL")
| transaction host maxspan=1m
| search "tlsProcessPendingData" OR "connTLSClose" OR "Segmentation fault" OR "heap-use-after-free"
| stats count by _time, host, src_ip, dest_port, command, message
| where count >= 1
| sort - _time
| table _time, host, src_ip, dest_port, command, message

Wazuh OSSEC Rule

<group name="valkey,">
  <rule id="100566" level="12" frequency="2" timeframe="60">
    <if_sid>100565</if_sid>
    <regex>tlsProcessPendingData|connTLSClose|heap-use-after-free|Segmentation fault</regex>
    <description>Valkey CVE-2026-56684: possible use-after-free crash after CLIENT KILL in TLS processing path.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>valkey_cve_2026_56684,</group>
  </rule>
  <rule id="100565" level="6">
    <decoded_as>json</decoded_as>
    <field name="command">CLIENT KILL</field>
    <description>Valkey CLIENT KILL command observed; monitoring for subsequent crash.</description>
    <group>valkey_client_kill,</group>
  </rule>
</group>

Mitigation & Patch Guidance

The NVD description states the issue is fixed in upstream releases 7.2.14, 8.0.10, 8.1.9, 9.0.5, and 9.1.1. That said, the tracked patch confidence rating for this CVE is 0/4 — UNPATCHED — with no patch artifacts, vendor advisories, or OSV package records ingested from any tracked source at the time of writing. Treat the fixed version list as the authoritative remediation target while independently verifying availability of the corresponding build artifacts from the Valkey project before deployment.

1. Immediate mitigations

   • Restrict network access to the Valkey TLS port to trusted application servers and administrative jump hosts only; do not expose the listener to the internet or untrusted segments.
   • Enforce strong authentication: set requirepass (or equivalent ACL-based user authentication) and rotate credentials; disable the default unprotected client mode if the deployment permits it.
   • If you cannot upgrade immediately, consider fronting Valkey with a TLS-terminating proxy or load balancer and disabling the Valkey native tls-port, moving TLS to a non-vulnerable component. Verify that this does not degrade the access-control model.
   • Monitor for the detection signatures above, especially CLIENT KILL followed by process crash, and page on-call for rapid containment.

2. Patch / upgrade steps

   • Plan a maintenance-window upgrade for all affected branches: 7.2.x → 7.2.14 or later, 8.0.x → 8.0.10 or later, 8.1.x → 8.1.9 or later, 9.0.x → 9.0.5 or later, and 9.1.x → 9.1.1 or later.
   • Prefer testing the upgraded build in a staging environment that mirrors production TLS configuration (including mutual TLS and certificate rotation policies) before production rollout.
   • After upgrade, verify that tlsProcessPendingData-related crash symbols no longer appear in core dumps and that CLIENT KILL operations during TLS load testing do not crash the server.

3. Long-term hardening

   • Enable OS-level and binary-level memory safety mitigations: full ASLR, NX, stack canaries, and, where available, run Valkey inside a memory-safety-hardened sandbox (container with seccomp/AppArmor) to reduce the likelihood that a heap UAF escalates to RCE.
   • Implement fleet-wide logging of all administrative commands (including CLIENT KILL) with correlation into the SIEM so exploit attempts can be distinguished from routine operations.
   • Subscribe to Valkey security advisories and ensure CVE ingestion from NVD/OSV is continuous; revisit this CVE's patch-confidence rating once vendor artifacts are formally published.
   • Establish a choke-point policy: any in-memory data store that holds session-state or PII should be network-isolated, authenticated via strong ACLs, and treated as a high-value target requiring the same scrutiny as a primary database.

References

• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-56684
• OSV vulnerability record: https://osv.dev/vulnerability/CVE-2026-56684
• MITRE CVE listing: https://www.cve.org/CVERecord?id=CVE-2026-56684
• Valkey project security page (verify patched release artifacts 7.2.14 / 8.0.10 / 8.1.9 / 9.0.5 / 9.1.1): https://valkey.io
• CISA KEV: Not listed (NO) — no known exploitation-in-the-wild evidence or threat-actor campaign has been attributed to this CVE at the time of writing.

No public exploit code, PoC, or Nuclei/exploit template has been observed for CVE-2026-56684; the exploitation chain described above is inferred from the vulnerability class and the advisory's mechanism description.