Redis TLS Use-After-Free (CVE-2026-81934): A Case Study in Reading Severity Correctly

CVE-2026-81934 is a use-after-free in Redis that was first published as a CVSS 9.8 Critical, then reassessed down to High once the real exploitation conditions were weighed. It's a clean lesson in why the number on a CVE is a starting point, not the answer.

CVE-2026-81934 is a use-after-free vulnerability in Redis, one of the most widely deployed in-memory databases in the world. It is worth reading closely, not just because of the flaw itself, but because of what happened to its score. It was first published as a CVSS 9.8 Critical, then reassessed down to High. That gap is a useful lesson in why the number on a CVE is a starting point, not the answer.

What the vulnerability is

The bug is a use-after-free in the tlsProcessPendingData() function, which handles the TLS pending-data list when Redis is configured with TLS support. Under the right conditions, an attacker can trigger the flaw and potentially execute arbitrary code with the privileges of the Redis server. The weakness class is CWE-416, use-after-free.

Two qualifiers matter here and shape everything about how urgent this is for you. First, exploitation requires TLS to be enabled. Second, and more importantly, Redis assesses this as requiring authenticated access, not an anonymous internet attacker.

The score story

The initial public CVE record rated this 9.8 Critical, which reads as "unauthenticated, trivial, drop everything." Redis pushed back on that assessment and rated it High instead, with a CVSS 4.0 score reflecting what real exploitation actually demands: authenticated access, broad permissions, coordinated TLS sessions, precise runtime timing, and target-specific adaptation. On September 1, 2026, the public record was updated to a revised High score.

This is the whole reason to look past the badge. A 9.8 and a High describe very different response priorities, and the difference here is not spin — it is the access and conditions an attacker actually needs. As of Redis's advisory, there was no known active exploitation in customer environments.

None of that makes it ignorable. It is still remote code execution in your database layer, and Redis is a classic example of software that gets deployed carelessly. The right response is calibrated, not panicked.

Who is affected and what to do

Fixed Redis Open Source releases are 8.10.1, 8.8.2, 8.6.6, 8.4.6, 8.2.9, 7.4.11, 7.2.16, and 6.2.24. Fixed Redis Software builds are 8.2.0-46, 8.0.20-96, 7.22.2-179, and 7.8.6-303. Redis Cloud Essentials has been patched, and Cloud Pro remediation is underway.

Beyond patching, the advisory's hardening guidance is worth following regardless of this CVE: keep Redis off the public internet entirely, restrict access to trusted clients, enforce strong authentication and least-privilege ACLs, and remove unnecessary access to sensitive commands. Redis exposed to the internet with weak or no auth is a recurring cause of real-world compromise, independent of any single vulnerability.

Reading it on VulnTracker

The CVE-2026-81934 page in VulnTracker captures the part that a static badge misses. The CVE Timeline shows the score's journey — base score set to 9.8 and Critical on publication, then revised down to High days later — so you can see the reassessment rather than reacting to a stale Critical rating. The Affected Products section lists the vulnerable Redis and Redis Software versions, with a Track button to alert you on future Redis CVEs. And the EPSS section shows a low current probability of exploitation, which lines up with Redis reporting no active exploitation.

Seeing the score change over time, instead of a single frozen number, is exactly what turns "is this a fire?" into an answer you can act on. (New to CVSS, KEV, and EPSS? See our plain-English guide to reading a CVE.)

The takeaway

The two questions that decide your workload never change: is the affected product in your stack, and do your conditions match the exposure requirements. For this one, that means asking whether you run an affected Redis version with TLS enabled, and whether an authenticated attacker could plausibly reach it. Answer those, and a scary-looking 9.8 sorts itself into its real place.

Track CVE-2026-81934 on VulnTracker — tell us you run Redis and you'd see the score reassessment, affected versions, and EPSS context in your alerts, so you respond to what a CVE actually is rather than the badge it launched with. Start a 5-day free trial, or get our daily digest free without setting anything up.

Quick reference

References: Redis security advisory · NVD · CVE.org