CVE-2026-81934: Redis TLS Use-After-Free, Who's Exposed

CVE-2026-81934 is a use-after-free in tlsProcessPendingData(), the Redis function that drains buffered data on TLS connections. It was disclosed August 27, 2026, and a working proof-of-concept is now public. If you don’t run Redis with TLS enabled, this one largely passes you by. If you do, especially on a port reachable beyond localhost, treat it as urgent.

What CVE-2026-81934 actually is

CVE-2026-81934 is a use-after-free in Redis’s TLS pending-data handling. An iterator walking a list of pending data holds a reference to a node, command processing runs mid-loop and frees that node, and the iterator then reads released memory. It is only reachable when Redis terminates TLS itself.

That detail is the whole scope question. A list iterator keeps a reference to the current node while it walks the list, and somewhere in that loop command processing gets a chance to run and free a node the iterator has not finished with. It is a classic use-after-free rather than a buffer overflow or an injection flaw, and the code path does not exist if you sit behind a TLS-terminating proxy.

Use-after-free bugs in a network-facing service are a known quantity in security research. Depending on what gets allocated into the freed memory before the stale pointer gets dereferenced, the outcome ranges from a crash to something an attacker can shape into remote code execution. Redis’s own advisory doesn’t claim a fully weaponized RCE chain, but it doesn’t rule one out either, and the public PoC changes the practical calculus regardless of where the theoretical ceiling sits.

Two CVSS scores, same bug

Here’s the detail worth sitting with instead of skating past: the public CVE record lists this at 9.8 (Critical). Redis’s own security advisory scores it 7.5 (High) under CVSS v4.0. Same vulnerability, same root cause, two different numbers from two different sources.

This isn’t a typo on either side. CVSS v3.1 (which most CVE database entries still use) and CVSS v4.0 score attack complexity and required privileges differently, and vendors often make more conservative assumptions about exploitability than a database entry generated from the CVE description alone. A 9.8 assumes low attack complexity and no privileges required, full stop. A 7.5 under v4 typically reflects some added friction, maybe timing-dependent exploitation, maybe a narrower set of reachable configurations, that the vendor believes the raw description doesn’t capture.

We don’t have enough independent detail to say confidently which number is closer to reality, and neither does most of the reporting we’ve read on this one. That’s a completely normal outcome for this kind of disagreement, and it’s also why “check the CVSS score” is a bad substitute for “check whether the vulnerable code path is live in my deployment.” Score the bug how you like; if tlsProcessPendingData() never executes on your servers, the number doesn’t matter.

The authentication question nobody’s settled

Compounding the scoring confusion: reporting on whether this requires authentication is inconsistent across sources. Some descriptions frame it as needing network access to a TLS-enabled Redis instance without specifying whether AUTH or ACLs block the path. Others describe conditions under which it’s reachable without valid credentials.

We’re not going to manufacture false precision here. If your own testing or vendor guidance clarifies the exact preconditions for your deployment, follow that. Absent that clarity, the safe operating assumption is: if your Redis TLS port is reachable from a network segment you don’t fully control, treat this as exploitable pre-auth. That assumption costs you nothing except patching sooner, and being wrong in the other direction costs considerably more.

Checking if TLS is actually on

Most Redis deployments still run plaintext, either on a trusted internal network or behind a TLS-terminating load balancer or service mesh. In either case, tlsProcessPendingData() never gets called, and this specific CVE doesn’t reach you. Confirm it directly instead of guessing from memory:

# From redis-cli, against a running instance
redis-cli CONFIG GET tls-port
# empty or "0" -> TLS isn't configured on this instance

# Or check the config file directly
grep -E '^tls-port|^port' /etc/redis/redis.conf

# Confirm your running version against the fixed list
redis-server --version

If tls-port comes back unset or 0, and you’re not passing --tls-port on the command line, you’re not exposed to this specific bug. Still patch on your normal cycle, there will be a next one, but this isn’t the fire drill for you.

If tls-port is set and reachable from anything other than localhost, that’s your signal to move now rather than at the next maintenance window. This is common in managed cloud Redis offerings that enforce TLS by default, in Redis instances exposed across a VPC boundary, and in setups where TLS is layered on for defense in depth even inside an otherwise trusted network. All three profiles are in scope here.

Fixed versions

Redis shipped patches in 8.2.9, 8.4.6, 8.6.6, 8.8.2, and 8.10.1, one fix per active release line rather than a single jump-to-latest fix. Match your current line:

Running line	Upgrade to
8.2.x	8.2.9
8.4.x	8.4.6
8.6.x	8.6.6
8.8.x	8.8.2
8.10.x	8.10.1

If you’re on an older major (7.x or earlier) with TLS enabled, check Redis’s advisory directly for whether your line is in scope, older EOL branches sometimes get backports and sometimes don’t, and it’s not worth guessing on a memory-safety bug.

What about Valkey

If you’re running Valkey, the open-source fork that split off after Redis’s license change, don’t assume this CVE transfers automatically in either direction. Valkey shares Redis’s history but the codebases have diverged, sometimes a shared-ancestry bug carries over cleanly, sometimes it’s already been refactored away, sometimes a fix was needed but landed on a different timeline. Check Valkey’s own security advisories for CVE-2026-81934 specifically rather than extrapolating from what Redis published. We covered the fork itself and why teams are choosing one project over the other in more detail in our Valkey overview, useful background if you’re mid-migration and trying to figure out which advisory stream actually applies to your fleet.

It’s also worth remembering that Redis sits underneath more infrastructure than the cache layer alone, from API rate limiting to session storage. If you’re using it as the backing store for distributed locks, a crash or memory corruption in the Redis process itself is a different failure mode than a lock timing out, it can take down every service holding a lock through that instance at once. Factor that into how urgently you patch, not just whether the TLS port is technically reachable.

Why “no known exploitation” doesn’t mean “low risk” right now

Redis said at disclosure it had no evidence of exploitation in customer environments. That statement was accurate as of August 27. It says nothing about September 4, and a working proof-of-concept being public changes the timeline in a way that’s shown up repeatedly this year: full technical writeups plus working PoC code is usually the point where opportunistic scanning starts, sometimes within days, occasionally within hours, well before any vendor or researcher confirms exploitation in the wild. Waiting for that confirmation before patching an internet- or VPC-reachable TLS Redis instance is a bet against a trend that hasn’t been paying off for anyone this year.

The checklist

1. Run CONFIG GET tls-port (or check redis.conf) on every Redis instance you operate or manage. No tls-port set means this CVE doesn’t apply to that instance.
2. For any instance with TLS enabled, check redis-server --version against the fixed versions table above.
3. Patch TLS-enabled instances first, especially anything reachable outside a fully trusted network segment. Don’t wait for exploitation confirmation.
4. If you’re on Valkey, check Valkey’s advisories separately rather than assuming this CVE does or doesn’t apply.
5. Roll patching into your normal cadence for the non-TLS instances. They’re not urgent for this bug specifically, but they’re not exempt from the next one either.