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 was published on August 27, 2026, and 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. The CVSS v4 base score is 9.2 (Critical) per the GitHub Advisory Database, while NVD assigns a CVSS v3.1 score of 7.1 (High) (Github Advisory, Feedly).

The root cause is a use-after-free (CWE-416) in src/tls.c. The tlsProcessPendingData() function iterates the pending_list 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 calls freeClient() → connClose() → connTLSClose() → listDelNode(), freeing the victim connection's pending_list node. If the iterator's cached next pointer referenced that now-freed node, the subsequent listNext() dereferences freed memory, causing a SIGSEGV or enabling 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). Exploitation requires that Redis be compiled and configured with TLS support; instances without TLS are not affected.

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, modify or delete keys, and potentially use the Redis process as a foothold for lateral movement within the network. A public proof-of-concept demonstrates achieving a shell as the redis user (uid=999) without any prior authentication, file write access, or module loading (PoC Repo).

A detailed public proof-of-concept exploit (exploit.py) has been published by v12-security (discovered by researcher "hexamine"), targeting the official amd64 Redis 8.8.0 image and achieving arbitrary command execution via a multi-stage heap grooming and Lua-based memory corruption chain (PoC Repo). The NVD SSVC assessment classifies exploitation as "poc" with "total" technical impact and "no" automatable exploitation. The EPSS score is approximately 0.435% (36th percentile), indicating moderate near-term exploitation probability (Github Advisory). No confirmed in-the-wild exploitation or threat actor attribution has been reported as of the time of publication, and the vulnerability is not listed in the CISA KEV catalog.

1. Reconnaissance: Identify Redis instances with TLS enabled (default port 6380 for TLS) using network scanners such as Shodan or Masscan, targeting versions prior to the patched releases.
2. Establish multiple TLS connections: Open at least three TLS connections to the target Redis server — a primary client (A) for sending slow commands, Pub/Sub clients (B) to accumulate output pressure, and a blocker client for event-loop timing shaping.
3. Leak Lua memory addresses: Use Lua object stringification via EVAL to leak addresses of _G, the Redis API table, the pairs CClosure, and candidate fake TLS strings, establishing the heap layout and PIE base.
4. Arrange unsafe iterator ordering: Ensure client B follows client A in the outer pending_list, so the outer iterator caches B's listNode * before nested processing closes B.
5. Trigger use-after-free: From client A's Lua script, perform a large PUBLISH to generate Pub/Sub output pressure that causes client B to be closed in the nested event loop. tlsPendingRemove() frees B's 24-byte listNode, but the outer iterator still holds its address.
6. Reclaim freed memory: Use HSET with crafted 22-byte SDS values to reclaim the freed node's allocator class, placing controlled data at the stale pointer's location to create a fake tls_connection object.
7. Convert stale pointer to one-bit write: The resumed outer walk reads the reclaimed node's value as a tls_connection *. The fake connection's fake aeEventLoop aliases events[0].mask to _G + 8, and aeDeleteFileEvent() clears bit zero, changing _G's Lua type from LUA_TTABLE to LUA_TSTRING.
8. Build read/write primitive: After GC releases the Redis API table, spray 47-byte Lua strings (solved via Z3 for hash zero) to reclaim the freed table slot, constructing a fake Lua table that provides arbitrary memory read/write.
9. Derive PIE base and patch server state: Read the raw luaB_pairs function pointer to compute the Redis PIE base, then write /bin/sh, -c, and the target command into memory, patching server.executable, server.exec_argv, and command flags to enable DEBUG CRASH-AND-RECOVER.
10. Achieve code execution: Send DEBUG CRASH-AND-RECOVER; Redis executes execve("/bin/sh", ["/bin/sh", "-c", command, NULL]) as the redis-server user, producing arbitrary command output (PoC Repo, Redis Commit).

• Network: Unusual or high-volume TLS connections to Redis TLS port (default 6380) from unexpected source IPs; multiple simultaneous TLS connections from a single client performing EVAL, PUBLISH, SUBSCRIBE, LPOS, HSET, and DEBUG commands in rapid succession.
• Logs: Redis logs showing SIGSEGV or unexpected server crashes/restarts; log entries for DEBUG CRASH-AND-RECOVER commands from unauthenticated or low-privilege clients; Lua timeout warnings (BUSY Redis is busy running a script) followed immediately by connection closures.
• Process: Unexpected child processes spawned by the redis-server process (e.g., /bin/sh, bash, curl, wget); execve syscalls from the Redis process to shell interpreters.
• File System: New files or scripts written to the Redis working directory or /tmp by the redis user account; unexpected cron jobs or scheduled tasks created under the redis user.
• Behavioral: Redis server restarting unexpectedly with no administrative action; server.executable or server.exec_argv configuration values changed at runtime (PoC Repo).

Upgrade Redis to one of the 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. For Redis Software (Enterprise), upgrade to 7.8.6-303, 7.22.2-179, 8.0.20-96, or 8.2.0-46 (Github Advisory). As interim workarounds if patching is delayed: restrict network access to Redis TLS ports to trusted hosts only using firewall rules, or disable TLS if it is not operationally required (note: disabling TLS removes the attack surface entirely since the vulnerability only exists in TLS-enabled deployments). Additionally, disabling Lua scripting (rename-command EVAL "") or denying the specific commands used by the known exploit chain (EVAL, PUBLISH, SUBSCRIBE, LPOS, HSET, DEBUG) will break the published PoC exploit chain as written (PoC Repo).

Redis published an official security advisory blog post at redis.io/blog/security-advisory-cve-2026-81934 shortly after disclosure. The Hacker Wire covered the vulnerability with a dedicated article on the Redis TLS use-after-free RCE (The Hacker Wire). Community discussion appeared on Reddit's r/vulnintel and Mastodon, and the vulnerability was picked up by security aggregators including SecurityOnline.info and Hunter Strategy's critical vulnerability roundup. Tenable released a Nessus detection plugin (ID 341276) within days of disclosure.