Redis Sat on an Authenticated RCE for Two Years. CVE-2026-23479, and Why 'Authenticated' Is Cold Comfort on the Box Nobody Firewalls.
- Patrick Duggan
- 7 minutes ago
- 4 min read
There is a use-after-free vulnerability in Redis, tracked as CVE-2026-23479, that lets an authenticated user run arbitrary operating-system commands on the host. It lives in the blocking-client code, it was introduced in Redis 7.2.0, and it sat there unnoticed for over two years until the May 5 fixes landed. The word doing the heavy lifting in every summary of this bug is "authenticated," and that word is going to lull a lot of teams into treating this as a low-priority patch. They are wrong, and the reason they are wrong is a fact about how Redis actually gets deployed that has nothing to do with the CVE itself.
Start with the bug, briefly, because the simple version is the true one. A use-after-free is what it sounds like: the program frees a chunk of memory, then keeps using it as though it were still valid. An attacker who can control what lands in that freed-and-reused memory can steer the program into doing things it was never supposed to do — here, executing commands on the underlying OS. The flaw is in the path that handles blocking clients, the Redis feature that lets a client wait on a key until something shows up. So an authenticated client, issuing the right sequence of blocking operations, walks the server off a cliff and lands as a shell on the box.
Now the part that matters more than the bug. "Authenticated" is doing a lot of reassuring in the writeups, and it should reassure you almost not at all, because of three facts about Redis in the wild.
First, Redis spent most of its life with no authentication at all. For years the default was no password, protected only by "protected mode," which refuses external connections but happily trusts anything that reaches it from inside. Enormous numbers of production Redis instances still run exactly that way: no auth, or a single shared password sitting in an environment variable that half the application fleet already has. On those instances, "authenticated" is not a barrier. It is the normal state of every app server that talks to the cache.
Second, Redis is the box nobody firewalls internally. It is trusted infrastructure — the cache, the session store, the job queue, the rate limiter, the pub/sub bus. It sits in the soft middle of the network where everything talks to it and nothing inspects it, because inspecting your own cache layer feels paranoid right up until it is the pivot. The hard perimeter holds; the soft surfaces bleed; Redis is about as soft and as central a surface as a modern stack has. An authenticated RCE on a component that every application server can already reach, on a flat internal network, is not a contained problem. It is a lateral-movement superhighway with a cache attached.
Third, the people who end up "authenticated" to your Redis are not only your own services. They are anyone who has already gotten one foothold — a compromised app server, a leaked connection string in a misconfigured CI log, an SSRF that can reach the internal port, a developer's overshared .env. The entire supply-chain and trust-graph story we have been writing for months ends with attackers holding exactly the kind of internal, already-trusted access that this CVE converts from "annoying foothold" into "root on the data layer." Authenticated is precisely the position the modern attacker is already in by the time they care about your Redis.
Here is the piece of this that should change your timeline, and it is the reason we are writing tonight instead of in three weeks. As of this writing, there is no public proof-of-concept exploit for CVE-2026-23479. We checked the place exploit code lands — GitHub — and the count is zero. That is not comfort. That is a countdown. The economics of this are the same ones we wrote about with the cPanel bug: the moment a working PoC goes public, the cost to weaponize this collapses from "skilled researcher reading a memory-corruption diff" to "paste a command," and the window between that moment and your patch being deployed is exactly where the breach happens. Right now you are on the good side of that window. You are left of the PoC drop. That is the cheapest and best place a defender ever gets to stand, and almost nobody uses it, because nothing has visibly gone wrong yet.
So use it. Patch Redis to the fixed release now, before there is a reason that feels urgent, because the urgent reason is a published exploit and by then you are racing. While you patch, do the two things that cost almost nothing and matter more than the patch on instances you cannot immediately update: require authentication on every Redis instance and rotate the passwords, and put the Redis port behind network policy so only the services that genuinely need it can reach it — not the whole VLAN. If an attacker cannot reach the port and cannot authenticate, an authenticated use-after-free is a bug they cannot touch. Defense in depth is unfashionable until it is the only reason a two-year-old memory bug did not become your incident.
The honest framing, capped as always below certainty: we cannot promise this is the Redis bug that gets mass-exploited rather than quietly patched into history. Most CVEs are the latter. But the shape of this one — ubiquitous trusted infrastructure, an authentication barrier that is routinely absent or already breached, an internal network that treats the cache as a friend, and a clock running toward the first public exploit — is the shape that, when it does go bad, goes bad everywhere at once. The detection rules and the patch are cheap. Being the org that watched the countdown and did nothing is the expensive option.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.