CVE-2026-81934: Redis TLS pending-list use-after-free

Redis assigned CVE-2026-81934 to a TLS-only use-after-free fixed across current supported trains. Redis revised the public CVE record on September 1, 2026 to CVSS 7.5 (High). Its current advisory says exploitation requires authenticated access, broad permissions, coordinated TLS sessions, precise runtime conditions, and target-specific adaptation. A public proof of concept exists, so affected self-managed deployments should still upgrade promptly.

Who is not in scope

Skip the pager if any of these hold:

• The binary was built without TLS (BUILD_TLS off) and you do not listen with tls-port. The bug lives in tlsProcessPendingData() in src/tls.c; plaintext Redis never enters that list.
• You already run a fixed Redis Open Source release: 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+.
• Managed Redis where the vendor confirms the Aug 17 SECURITY builds (or newer) are what you get. Confirm the exact server version; do not assume from the control-plane UI alone.

What this is not

This is not a plaintext Redis RCE, not the CMSketch RDB OOB write from the same security batch (CVE-2026-62356), and not an internet worm that works against every open 6379. Redis's current assessment requires a TLS-enabled server, authenticated access, broad permissions, coordinated TLS sessions, precise runtime conditions, and target-specific adaptation.

What broke

tlsProcessPendingData() walked the TLS pending-data list with Redis's adlist iterator. listNext() caches current->next before returning the current node. While the current connection's read handler runs, a command can close a different pending TLS connection (the commit message cites CLIENT KILL as the example). That close path frees the victim's pending-list node. If the iterator had already cached that node as next, the following listNext() dereferences freed memory.

The fix stops using a pre-cached iterator. It drains a bounded count of heads: detach via tlsPendingRemove() before tlsHandleEvent(), then re-read listFirst() each turn so no list node pointer is held across a handler call. Cherry-picked from 98ff29b into the stable trains as 6d088c3 (authored 2026-08-17).

v12-security published a PoC against the official amd64 Redis 8.8.0 image with TLS on. It grooms the pending list with multiple TLS clients, uses Lua timeout / Pub/Sub traffic to re-enter the event loop, reclaims the freed node, and ends in arbitrary command execution as the Redis uid. The PoC is timing- and heap-layout-sensitive; treat that as evidence the UAF is weaponizable, not as a reliability guarantee for every build.

Operator check

On each Redis host (or pod):

redis-server --version
redis-cli -p <port> INFO server | egrep 'redis_version|tcp_port'
# if you use TLS on a dedicated port:
redis-cli --tls -p <tls-port> INFO server | egrep 'redis_version'
grep -E '^(port|tls-port|tls-cert-file|tls-key-file)' /etc/redis/redis.conf 2>/dev/null

You should treat the instance as affected when TLS is enabled and the Redis version is below the fixed release for its train. Exploitation also depends on authenticated access and the additional prerequisites in Redis's advisory. Do not use an open TLS listener by itself as evidence that the flaw is remotely exploitable without credentials.

How to fix

Upgrade Redis Open Source to one of:

• 8.10.1
• 8.8.2
• 8.6.6
• 8.4.6
• 8.2.9
• 7.4.11
• 7.2.16
• 6.2.24

For Redis Software, Redis lists fixed builds 8.2.0-46, 8.0.20-96, 7.22.2-179, and 7.8.6-303. Redis Cloud Essentials has been patched; Redis says remediation of Redis Cloud Pro subscriptions is underway. Prefer the fixed release on the train you already run unless a broader upgrade is already planned.

After upgrade, re-check redis-server --version and confirm TLS listeners still come up. Rolling restart replicas before primaries if you run replication.

References

• Redis security advisory: CVE-2026-81934
• HOL Guard evidence pack: CVE-2026-81934
• Fix commit: 6d088c3 tlsProcessPendingData pending-list drain
• Release notes (SECURITY, 2026-08-17): Redis 8.2.9 / 8.4.6 / 8.6.6 / 8.8.2 / 8.10.1
• Public PoC write-up: v12-security/pocs redis/server_ssl