A remote-code-execution bug in Redis's TLS handling went public on 27 August 2026 rated 9.8 out of 10. A week later, Redis's own security team was publicly arguing the real number is 7.5. The bug itself didn't change in that week. What changed was which CVSS version was used to score it, and that disagreement is a genuinely useful case study in how to triage a CVE when the vendor and the database don't agree.
CVE-2026-81934 is a use-after-free vulnerability in how Redis handles TLS connections. The initial CVE record, scored under CVSS v3, rated it 9.8, Critical. Redis's security team publicly disputed that, rating it 7.5, High, under the newer CVSS v4.0 standard, and asked NVD to revise the published score. NVD updated the score around 1-2 September 2026. Then, in early September, a working proof-of-concept exploit went public, which arguably matters more than either number.
Why the two scores disagree
CVSS v3 and CVSS v4 don't weigh the same underlying facts the same way. CVSS v4 accounts more granularly for things like how automatable an attack actually is and what a successful exploit requires downstream, rather than treating "reachable over the network with no privileges needed" as close to automatic maximum severity the way v3 tends to. Redis's argument for 7.5 under v4 isn't a claim that the bug is harmless. It's a claim that the older scoring model overstated it relative to the newer, more granular one, and NVD apparently agreed enough to revise the published number.
Why the dispute shouldn't change your patch schedule
Whether the "correct" score is 9.8 or 7.5, a public proof-of-concept exploit exists as of early September 2026, according to reporting from securityonline.info. That single fact should drive your timeline more than either CVSS number does. A score is an estimate of risk before anyone has demonstrated an exploit. A public PoC replaces the estimate with a demonstrated fact. Once that exists, the sensible move is to patch on the assumption that anyone can now reproduce the attack, regardless of which severity classification the vendor and the database eventually settle on.
What to actually check
First, confirm whether you're running Redis with TLS enabled at all. The flaw only affects TLS-terminated connections, so if you run Redis without TLS configured directly (for instance behind a separate stunnel, or entirely on a private network with encryption handled elsewhere), you're not exposed through this specific path, though upgrading is still worthwhile.
Second, check your running version against the fixed releases: 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. Redis published a fix for each active minor line, so find the line closest to what you currently run and upgrade to that patch release rather than jumping to a newer major version you're not ready to migrate to.
Third, if you run Redis as a managed service through a cloud provider, check whether the provider has already applied the patch on your behalf, or whether you need to trigger the upgrade yourself. Managed Redis offerings don't all patch automatically the moment a CVE lands, and the responsibility split varies by provider, so don't assume "managed" means "already handled" until you've actually confirmed the version your instance is running.
Fourth, if any of your own services talk to Redis over TLS from outside your immediate network, for example a background worker or a separate microservice connecting over the public internet rather than a private VPC, prioritise those instances first. They're the ones an external proof-of-concept exploit could reach directly, whereas an instance only reachable from inside a locked-down private network carries comparatively lower immediate risk even before you get to it.
The habit worth building from this
Treat "the vendor disputes the CVSS score" and "the bug isn't real" as two different statements, because they usually are. Redis's team disputing the number in public wasn't a claim that CVE-2026-81934 doesn't matter. It was a technical argument about scoring methodology, made transparently, which is itself a reasonable sign about how the team handles disclosure. The mistake would be reading "vendor disputes CVSS score" in a headline and concluding the fix can wait. Once a public proof-of-concept exists, as it does here, the wait should be measured in days, not in which CVSS version eventually wins the argument.
The bottom line
CVE-2026-81934 is a use-after-free RCE bug in Redis's TLS handling, scored anywhere from 7.5 to 9.8 depending on which CVSS version and whose assessment you use, and a working exploit is reportedly already public. Check whether you run Redis with TLS enabled, then upgrade to 8.10.1, 8.8.2, 8.6.6, 8.4.6, 8.2.9, 7.4.11, 7.2.16 or 6.2.24 depending on your line, this week.