Redis, unblock-client use-after-free RCE

Overview

CVE-2026-23479 is a high-severity use-after-free vulnerability in Redis, the in-memory data store. An authenticated client can trigger memory corruption in the server's blocked-client handling that may escalate to remote code execution in the redis-server process. The NVD assigns a primary CVSS v3.1 base score of 8.8 (High); the Redis CNA additionally rates it 7.7 under CVSS v4.0.

The bug is notable for its longevity and how it was found: it was introduced in Redis 7.2.0 and went unnoticed across every stable branch for more than two years until being surfaced by an autonomous AI-assisted code-analysis effort and fixed in May 2026. Redis published a GitHub Security Advisory (GHSA-93m2-935m-8rj3) alongside release 8.6.3. Because Redis is ubiquitous in caching and queueing tiers and is frequently deployed with weak or shared authentication, an authenticated RCE in core command handling carries broad relevance even though it is not, at time of writing, listed as exploited in the wild.

Technical Details

The flaw is a use-after-free, classified as CWE-416, in the unblock client flow. Redis supports blocking commands (for example list and stream blocking reads) that park a client until data is available or a timeout fires. When such a client is unblocked, Redis re-executes the previously blocked command by calling processCommandAndResetClient. The vulnerable code does not handle an error return from processCommandAndResetClient during this re-execution path.

The dangerous interleaving occurs when the blocked client is evicted, for example under a maxmemory client-eviction policy, during this unblock-and-re-execute flow. Eviction frees the client structure, but the unblock path continues to operate on it because the error return that would have signalled the client was gone is ignored. The result is a dereference of freed memory. As with most heap use-after-free conditions in a C program processing attacker-influenced data, an attacker who can shape the heap and the timing can potentially turn the dangling pointer into controlled memory corruption and, ultimately, remote code execution in the redis-server process.

Triggering the condition requires the ability to issue commands to the server (Privileges Required: Low), which in many real deployments means any client that has authenticated or any client at all where Redis is left without authentication. The defect is present in redis-server from 7.2.0 up to and including 8.6.2, and is fixed in 8.6.3.

Impact

• Potential remote code execution in the redis-server process, executing with the privileges of the Redis service.
• Memory corruption and server crashes (denial of service) as a more readily achievable outcome of the use-after-free.
• High loss of confidentiality, integrity, and availability (CIA all High): a compromised Redis exposes all cached and stored data and can be used to tamper with it.
• A pivot toward connected applications, since Redis often holds session tokens, queue payloads, and cached credentials.
• Broad applicability across the large installed base running affected 7.2.0 through 8.6.2 builds, including many internet-adjacent or weakly authenticated instances.

Mitigation

1. Upgrade Redis to version 8.6.3 or later, which fixes the use-after-free in the unblock client flow.
2. If you cannot upgrade immediately, require authentication on every Redis instance (set a strong requirepass or use ACL users) and never expose Redis directly to untrusted networks.
3. Bind Redis to localhost or a trusted internal interface and enforce firewall rules so only known application hosts can connect to the Redis port.
4. Apply least privilege to the OS account running redis-server so that any successful code execution is contained, and enable available OS hardening (ASLR, non-executable heap) to raise exploitation difficulty.
5. Where the workload does not need them, restrict or disable blocking commands via ACLs to shrink the path to the vulnerable code, and review aggressive client-eviction (maxmemory) policies that make the race easier to reach.
6. After upgrading, monitor for crashes or instability that could indicate prior probing, and rotate any secrets that were stored in or reachable through the affected instance.

Detection

This vulnerability lives deep in server-internal memory handling, so there is no clean on-the-wire payload signature; detection leans on crash telemetry, access control, and command-pattern anomalies. The most reliable operational signal is redis-server instability: unexpected crashes, restarts, or SIGSEGV entries in the Redis log, especially correlated with heavy use of blocking commands (BLPOP, BRPOP, BLMOVE, BLMPOP, XREAD BLOCK, WAIT, and similar) under memory pressure. Configure Redis logging and your process supervisor to capture and alert on abnormal exits, and preserve any core dumps for analysis; a use-after-free exploitation attempt frequently produces crashes before it produces a working shell.

Instrument the client surface. Because triggering requires issuing commands, enumerate which clients connect to each instance and from where, using CLIENT LIST and connection logs, and alert on connections from unexpected source addresses or on Redis being reachable from outside its intended trust boundary. If you run the Redis ACL log, review ACL LOG for denied or unusual command attempts. Where you have a proxy or sidecar in front of Redis, watch for clients that rapidly open blocking commands and then disconnect or churn connections in a way that would drive eviction, since the bug depends on a client being evicted mid-unblock; such timing-sensitive bursts of blocking commands plus connection churn are a plausible exploitation fingerprint worth flagging.

At the host level, treat the Redis process like any RCE target: use EDR or auditd rules to alert if redis-server spawns a child process (a shell, interpreter, or downloader), opens unexpected outbound connections, or writes to unusual file paths, since a normal Redis process does none of these during steady-state operation. Build and maintain an inventory of Redis versions across your estate and flag anything in the 7.2.0 through 8.6.2 range as in-scope, prioritising instances that are network-exposed or lack authentication. Given the more-than-two-year exposure window, retain logs and, where practical, re-examine historical crash records for the affected period, and re-baseline after upgrading to 8.6.3 so future anomalies stand out.