Redis CVE-2026-81934: TLS pending-data use-after-free (High 7.5)

Redis published a security advisory for CVE-2026-81934 on 2026-08-28 (Riaz Lakhani; page updated 2026-09-02): a use-after-free in TLS pending-data processing. Under specific conditions an authenticated attacker could trigger the flaw and potentially execute remote code—as Redis states (advisory).

This brief stays inside the advisory. No exploit steps, payloads, or reproduction beyond Redis’s published wording. It is separate from the Kubernetes Active-Active password-wipe operator bug (no CVE).

Severity

Record	Score
Initial public CVE record	9.8 Critical
Revised public record (Redis note 2026-09-01)	7.5 High
Redis’s own assessment	High, CVSS v4.0 7.5

Prefer authenticated access as Redis’s advisory leads. Some third-party CVE mirrors may word the description differently; this brief follows Redis’s authenticated framing.

Fixed versions (as Redis lists)

Open source: 8.10.1 · 8.8.2 · 8.6.6 · 8.4.6 · 8.2.9 · 7.4.11 · 7.2.16 · 6.2.24

Redis Software: 8.2.0-46 · 8.0.20-96 · 7.22.2-179 · 7.8.6-303

Redis Cloud: Essentials patched; Pro remediation underway as of the advisory (contact a TAM for expedited help). Redis has not published a Pro completion date in this advisory.

Mitigations (vendor, high level)

Redis also recommends restricting the network to trusted clients, strong authentication with least-privilege ACLs, removing unnecessary CLIENT KILL / Lua / Pub/Sub access, and never exposing Redis to the internet—alongside upgrading (advisory).

As of 2026-08-27, Redis says it is not aware of active exploitation in customer environments—vendor statement only.

Who should care

Operators running Redis with TLS on affected builds should start at the Redis CVE-2026-81934 advisory—upgrade to a listed fixed version, keep RCE conditional as Redis writes it, and treat current public severity as High 7.5 with the earlier 9.8 history noted.