CVE-2026-81934: 
Redis vulnerability analysis and mitigation

CVE-2026-81934 is a use-after-free (UAF) vulnerability in Redis's tlsProcessPendingData() function, which manages the TLS pending-data list when Redis is configured with TLS support. A remote, unauthenticated attacker may be able to execute arbitrary commands with the privileges of the Redis server process. The vulnerability affects Redis versions prior to 6.2.24, 7.2.16, 7.4.11, 8.2.9, 8.4.6, 8.6.6, 8.8.2, and 8.10.1, as well as Redis Software (Enterprise) versions prior to 7.8.6-303, 7.22.2-179, 8.0.20-96, and 8.2.0-46. It was published on August 27, 2026, with a CVSS v4 base score of 9.2 (Critical) per the GitHub Advisory Database, and 7.1 (High) per the Feedly/NVD CVSS v3.1 assessment (Github Advisory, Feedly).

The root cause is a CWE-416 (Use After Free) defect in src/tls.c. The tlsProcessPendingData() function iterates the TLS pending-data list (el->privdata[1]) using a listIter, which pre-caches the next node pointer on each listNext() call. When tlsHandleEvent() processes a connection's read handler, it can execute a command (e.g., CLIENT KILL) that closes a different pending TLS connection. That close path traverses freeClient() → connClose() → connTLSClose() → listDelNode(), freeing the victim connection's list node. If the iterator's cached next pointer referenced that freed node, the subsequent listNext() call dereferences freed memory, causing a SIGSEGV or exploitable memory corruption. The fix replaces the listIter-based loop with a detach-from-head bounded drain that re-reads listFirst() on each iteration and detaches the head via tlsPendingRemove() before calling tlsHandleEvent(), eliminating the dangling pointer (Redis Commit, Github Advisory).

Successful exploitation allows a remote, unauthenticated attacker to execute arbitrary commands with the privileges of the Redis server process, resulting in full confidentiality, integrity, and availability compromise of the affected instance. An attacker can read all data stored in Redis (including cached credentials, session tokens, or application secrets), modify or delete data, and crash the server. Because Redis is frequently used as a backend cache or message broker, compromise can facilitate lateral movement into connected application tiers or enable cryptojacking campaigns, as observed in related Redis-targeting threat activity (Github Advisory, GBHackers).

A public proof-of-concept exploit (exploit.py) has been published by v12-security, targeting the official Redis 8.8.0 amd64 image and demonstrating full RCE via the TLS command interface without requiring module loading, file writes, or prior filesystem access (v12-security PoC). The NVD SSVC assessment classifies exploitation as "poc" with "total" technical impact. The EPSS score is approximately 0.44% (37th percentile), indicating moderate near-term exploitation probability. No confirmed in-the-wild exploitation or threat actor attribution has been reported as of the time of writing, and the vulnerability is not currently listed in the CISA KEV catalog. The exploit is timing- and heap-layout-sensitive, requiring up to eight attempts and specific build offsets, which limits automated exploitation (Github Advisory, Feedly).

1. Reconnaissance: Identify Redis instances with TLS enabled (port 6380 by default) using network scanners such as Shodan, Censys, or nmap. Confirm the target is running a vulnerable version (prior to 8.8.2 for the 8.x branch, or prior to the respective patched versions for 6.2, 7.2, 7.4 branches).
2. Setup exploit environment: Install Python dependencies (pwntools, z3-solver) and configure the exploit script (exploit.py) with the target Redis TLS host and port.
3. Leak Lua anchors and prepare fake objects: Connect to the Redis TLS port and use Lua object stringification via EVAL to leak addresses of _G, the Redis API table, the pairs CClosure, and candidate fake TLS strings. A temporary closure with 60 upvalues is allocated in the same size class as the fake TLS TString; its leaked address predicts the payload base.
4. Arrange unsafe iterator ordering: Establish three connection roles — Client A sends a slow EVAL; RESP3 Pub/Sub clients B accumulate output to become close candidates; a blocker client runs LPOS against a large list to shape event-loop timing. Clients A and B are primed with partial RESP ECHO requests so that B follows A in the outer pending list.
5. Trigger the use-after-free: Client A's Lua script performs a large PUBLISH (35 MB), burns CPU to cross Redis's Lua timeout path, then overwrites groomed HSET values. Lua timeout handling pumps the event loop while the script remains active. Pub/Sub output pressure causes B to be closed in the nested event loop, freeing B's 24-byte listNode while the outer iterator still holds its address.
6. Reclaim freed memory and build primitives: Final HSET allocations of 22-byte SDS values reclaim the freed node's allocator class, placing controlled data at the stale pointer's fields. The exploit converts the stale pointer into a one-bit write to corrupt the Lua _G table's type tag, then reclaims the Redis API table to build a read/write primitive via fake Lua table structures solved with Z3.
7. Derive PIE base and patch restart state: Read the raw luaB_pairs function pointer from the leaked pairs CClosure and subtract its known image offset to obtain the Redis PIE base. Patch server.executable to /bin/sh, server.exec_argv to ["/bin/sh", "-c", <command>, NULL], and enable the DEBUG command by patching server.enable_debug_cmd and redisCommandTable[DEBUG].flags.
8. Execute arbitrary command: Send DEBUG CRASH-AND-RECOVER. Redis closes the connection during restart and executes /bin/sh -c <command> as the redis-server user, with output visible in the server terminal (v12-security PoC).

• Network: Unexpected TLS connections to Redis on port 6380 from untrusted or external IP addresses; large PUBLISH commands (35+ MB payloads) observed in Redis traffic; multiple rapid reconnections from the same source IP (up to 8 exploit retry attempts).
• Logs: Redis logs showing SIGSEGV or crash/restart events (DEBUG CRASH-AND-RECOVER invocations); Lua timeout warnings (BUSY Redis is busy running a script) followed immediately by client disconnections; CLIENT KILL commands closing connections not initiated by the owning client.
• Process: Unexpected child processes spawned by the redis-server process (e.g., /bin/sh, id, uname, curl, wget); execve() calls from the Redis process to /bin/sh or other shells visible in auditd or strace output.
• File System: New or modified files in the Redis working directory created by the redis OS user; unexpected cron jobs or persistence mechanisms added under the redis user account.
• Redis Commands: Unusual sequences of EVAL, PUBLISH, HSET, LPOS, RPUSH, SUBSCRIBE, HELLO, and DEBUG commands from the same client session, particularly with large payloads or high iteration counts (v12-security PoC, Github Advisory).

Upgrade Redis to the following patched versions: 6.2.24, 7.2.16, 7.4.11, 8.2.9, 8.4.6, 8.6.6, 8.8.2, or 8.10.1 depending on your current branch. For Redis Software (Enterprise), upgrade to 7.8.6-303, 7.22.2-179, 8.0.20-96, or 8.2.0-46. If immediate patching is not possible, restrict network access to Redis instances to trusted hosts only using firewall rules or Redis's bind configuration directive, and disable TLS if it is not operationally required (note: disabling TLS eliminates the vulnerable code path entirely). Disabling Lua scripting (rename-command EVAL "") or denying the specific commands used by the known exploit chain (EVAL, PUBLISH, HSET, LPOS, DEBUG) also breaks the published PoC, though this may impact application functionality (Github Advisory, Redis Commit).

Redis published a dedicated security advisory blog post at redis.io/blog/security-advisory-cve-2026-81934, and the fix was committed by the Redis core team (sggeorgiev, YaacovHazan) with a detailed explanation of the iterator safety issue. The Hacker Wire covered the vulnerability with a dedicated article on Redis TLS use-after-free RCE. The vulnerability was discussed on Reddit's r/vulnintel and noted by the DailyCyberSecurity Mastodon account. Security roundup blogs including Hunter Strategy and Black Lantern Security's Crow's Nest highlighted it alongside other critical vulnerabilities. SUSE, Red Hat, AlmaLinux, and openSUSE all issued security advisories and errata, indicating broad downstream distribution response (Redis Blog, SUSE Advisory, Red Hat Errata).