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.
How the bug appears in Redis internals: unblockClientOnKey() and a use-after-free
The vulnerability lives in unblockClientOnKey() in src/blocked.c. When a key event wakes a blocked command, the function dispatches the queued command through processCommandAndResetClient(), then continues to use the same client pointer. That called function can free the client as a side effect — its header comment explicitly notes this — but the caller ignores the return value and reads the freed structure anyway, creating a use-after-free (CWE-416). Per the public analysis, the bug took two commits to create: a January 2023 refactor (PR #11012) added the unchecked call and a March 2023 change (PR #11568) added further client access after it. Neither change was dangerous alone; together they reached general availability in 7.2.0 and survived multiple rounds of security review.
The three-stage exploit chain published by Team Xint Code
Team Xint Code reported the flaw and published a complete technical write-up. Wiz’s published exploit writeup lays out a three-stage chain that first leaks a heap pointer, then replaces a freed client with a fake structure, and finally corrupts Redis’s memory accounting to overwrite a function pointer.
- Stage 1: A one-line Lua script (EVAL "return tostring(redis.call)" 0) leaks a heap pointer.
- Stage 2: The attacker manipulates client memory limits, parks a bloated client on a stream, then drops the limits and wakes it so Redis frees the blocked client mid-call; a pipelined SET reclaims the freed slot with a fake client structure.
- Stage 3: updateClientMemoryUsage() performs an out-of-bounds decrement using attacker-controlled fields aimed at the Global Offset Table (GOT) so strcasecmp() is repointed at system(), turning the next parsed command into a shell command.
Team Xint Code demonstrated 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.
Cloud footprint, defaults, and the role of privileged defaults
Wiz’s analysis, published alongside the exploit writeup, finds Redis present in a large majority of cloud environments, and most of those instances run without a password. The published exploit requires an authenticated session, but in a default deployment the default user already holds every privilege the chain requires. The full chain requires CONFIG SET, EVAL, stream commands (XREAD/XADD), and basic SET/GET — mapping to the @admin, @scripting, @stream, and @read/@write ACL categories. Redis’s default user has all of them, and Wiz found those privileges are frequently grouped into a single shared application or operator role.
Platform details that make exploitation easier and ratings
The official Redis Docker image ships with only partial RELRO, leaving the GOT writable at runtime; that makes the final write easier. Address Space Layout Randomization (ASLR) and Position-Independent Executables (PIE) do not mitigate the issue here because the write is relative to a global whose offset is fixed at build time. The National Vulnerability Database (NVD) rates CVE-2026-23479 as 8.8 under CVSS 3.1; Redis lists it as 7.7 under CVSS 4.0.
Mitigation, patching, and what different operators should do
Redis released patched minor versions on May 5 for each supported series: 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3. Minor upgrades within a series are intended to be drop-in. Managed Redis services patch on their own schedules; Redis reports that Redis Cloud is already patched. Redis also 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 — but the full technical chain is now public, increasing the risk of follow-on exploitation.
If you cannot patch immediately, Redis recommends several operational mitigations that blunt this specific chain: keep Redis off the public internet and behind TLS; tighten ACLs so no single role holds @admin, CONFIG, and @scripting together; deny @scripting if you do not use Lua (which prevents the Stage 1 leak). Prioritize internet-exposed instances, shared application credentials, and any role that combines CONFIG, scripting, and stream access, and rotate any broadly shared Redis credentials.
What this means for security teams, managed providers, and application owners
- Security teams and technologists: patch to the listed minor releases and apply the suggested ACL and exposure mitigations; assume the public writeup raises exploitation risk.
- Managed Redis providers and operators: verify patch schedules and communicate completion — Redis says Redis Cloud is already patched and other managed services follow their own cadence.
- Application owners using shared credentials: treat any role that combines CONFIG, scripting, and stream access as high priority for credential rotation and privilege separation.
Two commits planted this bug, two years hid it, and it sat in one of the most-deployed databases until a hacking contest — and an autonomous AI tool — surfaced it. It survived multiple rounds of review; the public disclosure and working chain now raise a clear imperative: apply the May 5 patch levels and remove easy attack paths from default deployments.
Source: The Hacker News — Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479)
