Redis RCE CVE-2026-23479: AI Caught a 2-Year Cloud Flaw

Redis has patched a use-after-free in its blocking-client code path that lets any authenticated user execute arbitrary operating-system commands on the host. Tracked as CVE-2026-23479, the flaw shipped in Redis 7.2.0 in 2023 and survived two years of review until an autonomous AI bug-hunter surfaced it at Wiz’s ZeroDay.Cloud contest. With Redis running in roughly 80% of cloud environments — many with no password — this is the rare authenticated RCE that actually scales.

The bug is the headline of a five-vulnerability advisory published by Redis on May 5, 2026, but it deserves its own treatment: it is the one an AI tool found, it is the one with a public, working exploit chain, and it is the one sitting inside the most-deployed in-memory database on the planet.

What the Redis flaw actually is

CVE-2026-23479 is a use-after-free (CWE-416) in unblockClientOnKey() inside src/blocked.c. The function fires when a key event wakes a blocked command. It dispatches the queued command through processCommandAndResetClient(), then keeps reading the same client pointer. The problem, as The Hacker News reports, is that processCommandAndResetClient() can free the client as a side effect — its own header comment says so — yet the caller ignores the return value and dereferences the freed structure anyway.

Severity ratings disagree, which matters for triage. NVD scores it 8.8 Critical under CVSS 3.1; Redis lists it 7.7 High under CVSS 4.0. Either way it is remote code execution from an authenticated session, and “authenticated” is doing very little work here — the default Redis user carries every privilege the chain needs.

How the exploit chain works

The public write-up, hosted on ZeroDay.Cloud by finder Team Xint Code, breaks the attack into three stages:

1. Heap leak. A one-line Lua script — EVAL "return tostring(redis.call)" 0 — leaks a heap pointer that defeats ASLR.
2. Client swap. 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 crafted fake-client structure.
3. GOT overwrite. Redis’s own routine memory accounting in updateClientMemoryUsage() performs an out-of-bounds decrement using attacker-controlled fields, aimed at the Global Offset Table. It repoints strcasecmp() at system(). The next command Redis parses runs as a shell command.

The chain needs CONFIG SET, EVAL, stream commands (XREAD/XADD), and basic SET/GET — mapping to the @admin, @scripting, @stream, and @read/@write ACL categories. The default user holds all of them, and in most real deployments these privileges are lumped into a single shared application or operator role.

Why two commits hid it

This is the part that should make every defender uncomfortable. Per Wiz’s analysis, the bug took two separate commits to create — neither dangerous on its own:

• A January 2023 refactor (PR #11012) added the unchecked call.
• A March 2023 change (PR #11568) added more client access after it.

Together they reached general availability in 7.2.0 and survived multiple rounds of security review for over two years. Code review did not catch it. Fuzzing did not catch it. An autonomous AI tool entered a hacking competition and caught it. That is the signal worth sitting with.

The cloud exposure problem

The technical chain needs authentication, but the cloud reality is that authentication is thin. Wiz’s analysis puts Redis in roughly 80% of cloud environments, with a large share of those instances running without a password. The official Redis Docker image compounds the problem: it ships with only partial RELRO, leaving the GOT writable at runtime. ASLR and PIE do not help here, because the final write is relative to a global whose offset is fixed at build time.

Denying CONFIG outright breaks this specific chain (though not the underlying use-after-free). Denying @scripting kills the Stage 1 leak. But the default deployment grants both, and Redis has spent years being treated as a trusted internal component rather than a network-facing service that deserves least-privilege ACLs.

Five RCE flaws, one advisory

CVE-2026-23479 was not alone. The oss-sec disclosure lists five vulnerabilities, four of them rated High at CVSS 7.7:

Three of the four RESTORE-class bugs require a specific module loaded (RedisTimeSeries or RedisBloom), which narrows the blast radius. The Lua use-after-free (CVE-2026-23631) only affects replicas configured with replica-read-only disabled. But the pattern matters: Redis’s RESTORE deserialization and Lua scripting paths keep producing memory-safety bugs, and this is the second authenticated Lua-scripting use-after-free in two years, following 2025’s RediShell flaw.

Patch now or restrict access

Fixed releases landed on May 5, 2026. Redis Cloud is already patched. If you self-host Redis OSS or Community Edition, the target versions are:

Minor upgrades within a series are designed to be drop-in. If you cannot patch immediately, the compensating controls are blunt but effective, per Redis’s own guidance:

1. Take Redis off the public internet. Put it behind TLS and a private network. This is the single highest-leverage move.
2. Split ACLs. Ensure no single role holds @admin, CONFIG, and @scripting together.
3. Deny @scripting if you do not use Lua. It kills the Stage 1 heap leak.
4. Rotate shared credentials. The default user is the threat model. Rotate any broadly shared app or operator credential.
5. Enable protected-mode in OSS/CE to block accidental unauthenticated exposure.

Prioritize internet-exposed instances first, then any role that combines CONFIG, scripting, and stream access. The full technical chain is now public, so the window for follow-on exploitation is open.

AI hunting rewrites the rules

The buried headline is how this was found. Team Xint Code is described by Theori as an autonomous AI security tool built to hunt bugs in large codebases. It surfaced a two-year-old use-after-free that two human-authored commits planted and that multiple rounds of review missed — at a hacking competition, not a code audit.

Redis says it has no evidence of exploitation in its own or customer environments, and no public in-the-wild reports have surfaced. That is cold comfort now that the full chain is published. The defensible position is simple: treat every Redis instance as if the exploit is in the wild, patch the host, lock down the ACL, and stop assuming an internal service can stay unauthenticated because it sits on a private subnet. Two commits hid this for two years. The next one might hide longer.

Related reading on cloudaisec

• CVE-2026-23479 is the second authenticated-RCE memory-safety bug in a widely deployed open-source component that an AI tool surfaced this month — we covered the same pattern in the OpenSSL PKCS7_verify flaw, where automated analysis found an RCE-grade bug human review had missed.
• If the “80% of cloud environments run Redis unauthenticated” figure sounds familiar, it is the same posture that drives most cloud incidents — our cloud hardening checklist for APT exposure walks through the network-segmentation and identity controls that would have neutralised this chain.
• And if you are doing incident-response triage because a Redis box was exposed, our playbook for surviving an accidental production exposure covers the containment, rotation, and disclosure steps.

References

• Redis Security Advisory: CVE-2026-23479 and four related flaws (Redis, May 5, 2026)
• Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (The Hacker News, June 3, 2026)
• oss-sec: 5 CVEs in Redis (Seclists.org, June 3, 2026)
• CVE-2026-23479 Deep Dive (ZeroDay.Cloud / Wiz)
• CVE-2026-23479: Remote Code Execution in Redis (Positive Technologies dbugs)
• Redis Use-After-Free Remote Code Execution Vulnerability (Security Boulevard, June 4, 2026)