How the Redis CVE-2026-23479 RCE Works and How to Mitigate It

On May 5, Redis released fixes for five remote code execution (RCE) vulnerabilities, the most severe of which — CVE-2026-23479 — received a CVSS score of 8.8 from NVD (v3.1). This is a use-after-free bug (CWE-416) that existed in all stable Redis branches starting from version 7.2.0 — for more than two years. A public exploit is already available, although no exploitation in real-world attacks has been observed so far. All administrators of Redis instances need to update to versions 7.2.14, 7.4.9, 8.2.6, 8.4.3 or 8.6.3, and if an immediate upgrade is not possible, restrict ACL privileges and network access to the server.

Technical nature of the vulnerability

The vulnerability is located in the unblockClientOnKey() function in src/blocked.c. This function is called when a blocked command is woken up by a key event. It passes the queued command through processCommandAndResetClient(), and then continues to use the same pointer to the client structure. The problem is that processCommandAndResetClient() may free the client as a side effect — this is stated explicitly in the comment in the function header. The caller ignores the return value and accesses already freed memory.

According to the researchers, the bug arose from the interaction of two commits. A refactoring in January 2023 (PR #11012) added an unchecked call. A change in March 2023 (PR #11568) added an additional access to the client structure after this call. Neither commit alone introduced a vulnerability — the combination of both, which shipped publicly in version 7.2.0, is what created the dangerous condition.

Redis rates the vulnerability at 7.7 under CVSS 4.0, which is lower than the NVD score. The discrepancy stems from differences between the 3.1 and 4.0 scoring methodologies rather than disagreement about the seriousness of the issue.

Published exploitation chain

A full technical description of the exploit has already been published. According to that write-up, the attack chain consists of three stages:

• Heap address leak. A one-line Lua script (EVAL "return tostring(redis.call)" 0) returns a heap pointer needed for subsequent calculations.
• Client structure substitution. The attacker manipulates the client’s memory limits, blocks the “bloated” client on a stream, then resets the limits and wakes it up. Redis frees the blocked client midway through processing, and a pipelined SET command immediately reuses the freed slot with a forged client structure.
• Function pointer overwrite. The standard memory accounting mechanism in updateClientMemoryUsage() performs an out-of-bounds array decrement using attacker-controlled fields. The target is the Global Offset Table (GOT): redirecting strcasecmp() to system(). The next command that Redis parses is then executed as a shell command.

According to the researchers, the official Redis Docker image ships with partial RELRO, leaving the GOT writable at runtime. ASLR and PIE do not help, because the write is performed relative to a global variable with a fixed offset determined at build time.

Exploitation requirements and threat scope

The full exploit chain requires an authenticated session with CONFIG SET, EVAL, stream commands (XREAD/XADD), and basic SET/GET privileges. In Redis ACL terms these are the @admin, @scripting, @stream, @read and @write categories. The default user has all of these privileges.

The vulnerability was discovered by the Team Xint Code group. The company Theori describes Xint Code as a standalone AI-based security tool designed to find bugs in large codebases. This is a noteworthy case: two commits created the vulnerability, it went through many rounds of code review over two years, and in the end it was found not by a human but by an automated tool during a hacking competition.

Redis has stated that it has no evidence of exploitation in its own environments or those of its customers. At the time of publication there had been no reports of exploitation in real-world attacks. However, publication of the full technical chain significantly raises the risk of subsequent exploitation.

Practical recommendations

Priority — immediate upgrade. Install the fixed versions for your series:

• Redis 7.2 → 7.2.14
• Redis 7.4 → 7.4.9
• Redis 8.2 → 8.2.6
• Redis 8.4 → 8.4.3
• Redis 8.6 → 8.6.3

According to the vendor, Redis Cloud has already been updated. Managed services from other providers are updated on their own schedules — check the status with your provider.

If an immediate update is not possible:

• Eliminate direct internet access to Redis; place it behind TLS.
• Separate ACL privileges: no single role should simultaneously have @admin, CONFIG and @scripting.
• Disable the @scripting category if Lua scripts are not used — this blocks the first stage of the chain (heap address leak).
• Denying CONFIG breaks the specific published chain but does not fix the underlying use-after-free bug.
• Rotate all shared Redis credentials.

Prioritize instances exposed to the internet, shared application accounts, and any roles that combine access to CONFIG, scripts, and streams.

CVE-2026-23479 is one of five RCE-class vulnerabilities disclosed in a single Redis update bundle, and the second recent use-after-free bug in Redis related to Lua scripting. The presence of a public PoC combined with Redis’s broad deployment makes the window for safe updating extremely narrow. Update affected instances to the fixed minor versions now, not after the first attack reports appear.