Redis has patched a use-after-free in its blocking-client code that lets an authenticated user run arbitrary OS commands on the machine hosting the database. The flaw was found by an autonomous AI tool built to hunt bugs in large codebases.
Tracked as CVE-2026-23479, the flaw was introduced in Redis 7.2.0 and remained in every stable branch until the May 5 fixes, unnoticed for over two years. NVD rates it 8.8 under CVSS 3.1; Redis lists it as 7.7 under CVSS 4.0. It was reported by Team Xint Code, and a complete technical write-up is now public.
The cloud footprint makes this worse. Wiz’s analysis, published with the exploit writeup, puts Redis in a large majority of cloud environments, with most of those instances running without a password. The exploit needs an authenticated session, but in a default deployment, the default user already holds every privilege the chain requires.
The flaw lives in unblockClientOnKey() in src/blocked.c, which fires when a key event wakes a blocked command. The function dispatches the queued command through processCommandAndResetClient(), then keeps using the same client pointer. The problem: that function can free the client as a side effect, and its own header comment says so. The caller ignores the return value and reads the freed structure anyway, a use-after-free (CWE-416).
Per Wiz’s analysis, the bug took two commits to create. A January 2023 refactor (PR #11012) added the unchecked call. A March 2023 change (PR #11568) added more client access after it. Neither was dangerous alone. Together, they reached general availability in 7.2.0 and survived multiple rounds of security review.
The chain starts by leaking a heap address. From there it frees a client and slips a fake one into the same memory, then turns Redis’s own memory accounting against itself to overwrite a function pointer.
The published version runs in three stages.
- First, a one-line Lua script (EVAL “return tostring(redis.call)” 0) leaks a heap pointer.
- Second, the attacker grooms client memory limits, parks a bloated client on a stream, then drops the limits and wakes it. Redis frees the blocked client mid-call, and a pipelined SET immediately reclaims the freed slot with a fake client structure.
- Third, Redis’s routine memory accounting in updateClientMemoryUsage() performs an out-of-bounds decrement using attacker-controlled fields, aimed at the Global Offset Table to repoint strcasecmp() at system(). The next command Redis parses runs as a shell command.
The official Redis Docker image makes the last step easier. It ships with only partial RELRO, leaving the GOT writable at runtime. ASLR and PIE do not help here, since the write is relative to a global whose offset is fixed at build time.
The full chain needs an authenticated session with CONFIG SET, EVAL, stream commands (XREAD/XADD), and basic SET/GET, which maps to the @admin, @scripting, @stream, and @read/@write ACL categories.
The default user has all of them, and in most deployments, these privileges are grouped into a single shared application or operator role. Denying CONFIG outright breaks this specific chain, though not the underlying use-after-free.
Team Xint Code demonstrated the working RCE at ZeroDay.Cloud 2025, Wiz’s hacking competition in London last December. Theori describes Xint Code as an autonomous AI security tool built to hunt bugs in large codebases.
Redis said it had no evidence of exploitation in its own or customer environments, and as of publication no public in-the-wild reports have surfaced. The full technical chain is now public, increasing the risk of follow-on exploitation.
Upgrade to the patched minor for your series: 7.2.14, 7.4.9, 8.2.6, 8.4.3, or 8.6.3, all released on May 5. Minor upgrades within a series are meant to be drop-in. Managed Redis services patch on their own schedules, and Redis says Redis Cloud is already done.
| Branch | Affected | Fixed |
|---|---|---|
| 7.2.x | 7.2.0 to 7.2.13 | 7.2.14 |
| 7.4.x | 7.4.0 to 7.4.8 | 7.4.9 |
| 8.2.x | 8.2.0 to 8.2.5 | 8.2.6 |
| 8.4.x | 8.4.0 to 8.4.2 | 8.4.3 |
| 8.6.x | 8.6.0 to 8.6.2 | 8.6.3 |
If you cannot patch yet: keep Redis off the public internet and behind TLS, tighten ACLs so no single role holds @admin, CONFIG, and @scripting together, and deny @scripting if you do not use Lua, which kills the Stage 1 leak.
Prioritize internet-exposed instances, shared application credentials, and any role that combines CONFIG, scripting, and stream access. Rotate any broadly shared Redis credentials while you are at it.
CVE-2026-23479 was one of five RCE-class Redis flaws disclosed last month, and it follows Redis’s 2025 RediShell flaw, another authenticated use-after-free involving Lua scripting. It is also the one an AI tool caught. Two commits planted it, two years hid it, and it sat in one of the most-deployed databases around until a hacking contest surfaced it. Code review never did.
