CVE-2026-23479: Use-After-Free Vulnerability in Redis Blocking-Client Command Re-Execution

The vulnerability CVE-2026-23479 resides within the blocking-client management implementation of the Redis in-memory data store (redis-server). In Redis, clients can perform blocking operations, such as waiting for list items via BLPOP or waiting on stream entries via XREAD. While blocked, the connection state is tracked by a dedicated client structure. When the blocking condition is satisfied, the client is queued for unblocking, transitioning its execution state.\n\nDuring this transition, if the client has a pending command associated with it, the unblocking routing must dispatch and execute the command. This is handled by a dedicated command execution path inside the core engine. However, the system's client eviction policy can trigger memory reclamation routines under memory pressure, freeing inactive or memory-heavy client structures. This dynamic introduces a critical lifetime management issue if the execution path does not track whether a client structure remains valid.\n\nThe vulnerability is classified under CWE-416 (Use After Free). If an active, blocked client structure is freed during the command execution phase, the subsequent logic continues to read and write to the freed structure's memory address. Under standard deployments, an authenticated attacker can leverage this condition to gain control of execution flow, resulting in unauthenticated execution of administrative or system-level commands.

The root cause of the vulnerability lies within the unblockClientOnKey() function in src/blocked.c. When a blocked client is unblocked, the function checks for the CLIENT_PENDING_COMMAND flag. If set, it updates the state flags to CLIENT_REEXECUTING_COMMAND and calls processCommandAndResetClient(c) to process the queued command.\n\nThe critical flaw is that unblockClientOnKey() ignores the return value of processCommandAndResetClient(c). This function is documented to return C_ERR if the client structure is destroyed or freed during the execution of the command. Because the return value is ignored, the execution flow continues under the assumption that the pointer c points to a valid client struct.\n\nIf the client is evicted during the execution of the command (for example, if the command processing causes memory allocations that exceed configured thresholds and trigger client eviction), the client memory is freed using zfree(). The freed memory is not cleared, and the pointer remains registered. The subsequent lines in unblockClientOnKey() perform flag evaluations such as !(c->flags & CLIENT_BLOCKED) and bitwise assignments like c->flags &= ~CLIENT_REEXECUTING_COMMAND. This results in both use-after-free read and write operations on the reclaimed or unmapped heap memory.

To understand the structural failure, we analyze the vulnerable code path in src/blocked.c prior to the patch. The flow executes critical operations on the client pointer c after invoking processCommandAndResetClient(c) without any validation.\n\nc\n/* Vulnerable Code in src/blocked.c */\nstatic void unblockClientOnKey(client *c, robj *key) {\n ...\n if (c->flags & CLIENT_PENDING_COMMAND) {\n c->flags &= ~CLIENT_PENDING_COMMAND;\n c->flags |= CLIENT_REEXECUTING_COMMAND;\n ...\n /* processCommandAndResetClient can free client 'c' and return C_ERR */\n processCommandAndResetClient(c); \n \n /* UAF READ: Dereferencing c->flags on a potentially freed client */\n if (!(c->flags & CLIENT_BLOCKED)) {\n if (c->flags & CLIENT_MODULE) {\n moduleCallCommandUnblockedHandler(c);\n } else {\n /* Queues the freed pointer to server.unblocked_clients */\n queueClientForReprocessing(c);\n }\n }\n exitExecutionUnit();\n afterCommand(c);\n /* UAF WRITE: Modifying flags on a freed client */\n c->flags &= ~CLIENT_REEXECUTING_COMMAND; \n ...\n }\n}\n\n\nThe upstream patch introduces an explicit check on the return value of processCommandAndResetClient(c). If the return value is C_ERR, the function aborts further execution, ensuring no dereferences occur on the freed pointer.\n\nc\n/* Patched Code in src/blocked.c */\nstatic void unblockClientOnKey(client *c, robj *key) {\n ...\n if (c->flags & CLIENT_PENDING_COMMAND) {\n c->flags &= ~CLIENT_PENDING_COMMAND;\n c->flags |= CLIENT_REEXECUTING_COMMAND;\n ...\n /* The return value is now captured and checked */\n if (processCommandAndResetClient(c) == C_ERR) {\n /* Client was freed inside the call; abort immediately */\n return;\n }\n \n /* Safe dereference: client is guaranteed to be valid */\n if (!(c->flags & CLIENT_BLOCKED)) {\n if (c->flags & CLIENT_MODULE) {\n moduleCallCommandUnblockedHandler(c);\n } else {\n queueClientForReprocessing(c);\n }\n }\n exitExecutionUnit();\n afterCommand(c);\n c->flags &= ~CLIENT_REEXECUTING_COMMAND;\n ...\n }\n}\n

Exploitation of CVE-2026-23479 requires an authenticated connection with access to standard Redis commands and configurations. The attack payload involves a multi-stage process designed to bypass Address Space Layout Randomization (ASLR), trigger the Use-After-Free condition, reclaim the freed heap space, and redirect control flow.\n\nFirst, the attacker leaks a heap address using a Lua script conversion bypass. Running EVAL "return tostring(redis.call)" 0 returns the address of the internal handler. Because the offset between this handler and the main heap structures is constant, this leakage provides the precise location of the heap.\n\nSecond, the attacker establishes three distinct connections. Connection 1 configures the memory boundaries, Connection 2 creates a memory-intensive state by queueing massive command replies within a transaction and blocking on a stream, and Connection 3 triggers client eviction by lowering the limit and sending data to unblock Connection 2. This sequence forces unblockClientOnKey() to execute, evicting the victim client and queuing its freed pointer in the global server.unblocked_clients queue.\n\nThird, during the same event loop tick, the attacker reclaims the freed client allocation with a crafted SET command. When Redis processes the unblocked_clients queue, it reads the attacker's fake client structure. The fake client utilizes a controlled last_memory_type index and a controlled last_memory_usage decrement value to target the Global Offset Table (.got.plt), which is writable due to partial RELRO. This relative write decreases the GOT entry for strcasecmp until it points to system, allowing any subsequent commands to be executed directly in the host shell.

The security impact of CVE-2026-23479 is extremely high. Successful exploitation grants the attacker arbitrary remote code execution (RCE) with the privileges of the running Redis daemon. Since Redis is frequently run with administrative or container root privileges, this compromise can lead to complete host takeover.\n\nThe vulnerability is tracked with a CVSS 3.1 Base Score of 8.8 (High) and a CVSS 4.0 Base Score of 7.7 (High). The attack vector is Network (AV:N), complexity is Low to High depending on heap grooming precision (AC:L in NVD, AC:H in CVSS 4.0), privileges required are Low (PR:L), and no user interaction is required (UI:N). The scope remains Unchanged (S:U), while impact on confidentiality, integrity, and availability is High (C:H/I:H/A:H).\n\nmermaid\ngraph LR\n A["Attacker (Authenticated)"] -->|"1. Leak Heap via Lua"| B("Redis Server")\n A -->|"2. Trigger Eviction & UAF"| B\n A -->|"3. Reclaim Memory & Write GOT"| B\n B -->|"4. Hijack strcasecmp"| C["System Shell (RCE)"]\n\n\nBecause the vulnerability leads to a direct control-flow hijack, it acts as a significant vector for privilege escalation and lateral movement within internal networks where Redis instances are commonly deployed without deep perimeter defense.

The definitive remediation for CVE-2026-23479 is to upgrade Redis to a patched version. Upstream maintenance teams have released fixes across all active release branches. Administrators should deploy the following versions:\n\n* Redis 7.2.x: Upgrade to 7.2.14 or higher\n* Redis 7.4.x: Upgrade to 7.4.9 or higher\n* Redis 8.2.x: Upgrade to 8.2.6 or higher\n* Redis 8.4.x: Upgrade to 8.4.3 or higher\n* Redis 8.6.x: Upgrade to 8.6.3 or higher\n\nIf patching cannot be performed immediately, temporary operational workarounds must be implemented. First, restrict administrative capabilities by disabling or renaming the CONFIG command using Redis Access Control Lists (ACLs). This prevents attackers from manipulating maxmemory-clients to trigger the eviction sequence.\n\nSecond, disable Lua scripting support entirely if not required, or limit the @scripting category to administrative users to prevent the heap address leakage. Finally, ensure that the Redis service is bound exclusively to localized interfaces or private networks, protecting the port from public exposure.