CVE-2026-82631: 
Redis vulnerability analysis and mitigation

CVE-2026-82631 is a heap use-after-free (UAF) vulnerability in the handleClientsBlockedOnKey() function within src/blocked.c of the Blocked-on-keys Subsystem in valkey-io Valkey 9.1.0. The flaw was reported on July 17, 2026, disclosed publicly on August 31, 2026, and affects Valkey version 9.1.0 (though the vulnerable pattern may exist in older versions back to 7.2). It carries a CVSS v3.1 base score of 2.2 (Low) and a CVSS v4.0 base score of 1.2 (Low), reflecting the high attack complexity and high privilege requirements (GitHub Advisory, GitHub Issue).

The root cause is a CWE-416 (Use After Free) / CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) defect in handleClientsBlockedOnKey(). The function iterates the blocked-client list using a plain adlist iterator (listIter), which caches the successor listNode* pointer. When a module client blocked via ValkeyModule_BlockClientOnKeys() is served, its reply callback can synchronously re-enter the server and execute CLIENT KILL on a successor blocked client on the same ready key. This teardown path calls unblockClientWaitingData(), which empties c->bstate->keys and frees the exact listNode* already cached as listIter.next. When the outer loop resumes and calls listNext(), it dereferences the freed node, producing a heap-use-after-free confirmed by AddressSanitizer. The same class of UAF can also be triggered via the non-module path when unblockClientOnKey → processCommand → evictClients() frees a successor blocked client under maxmemory-clients constraints (GitHub Issue, Fix PR).

Successful exploitation results in a Denial of Service (DoS) against the Valkey server process — the server crashes or aborts due to the heap-use-after-free condition. There is no confidentiality or integrity impact; the vulnerability is limited to availability. An authenticated attacker with high privileges must control a loaded Valkey module and orchestrate a specific race condition involving two clients blocked on the same key, making real-world impact limited to service disruption (GitHub Issue, GitHub Advisory).

A proof-of-concept (PoC) exploit (PoC.zip) was publicly released alongside the vulnerability report and is available via the GitHub issue (GitHub Issue). The CVSS v4.0 exploit maturity is rated PROOF_OF_CONCEPT. The EPSS score is approximately 0.358%, indicating a low probability of widespread exploitation. There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high privileges, high attack complexity, and a loaded Valkey module, significantly limiting the practical attack surface (GitHub Advisory).

1. Prerequisite Setup: Obtain authenticated access to a Valkey 9.1.0 server with high privileges and the ability to load a custom module. The server must have the module API enabled.
2. Compile Malicious Module: Build a Valkey module (e.g., based on the public PoC readykey_iter_uaf.c) that registers two commands: one to block clients on a key using ValkeyModule_BlockClientOnKeys(), and one to signal the key as ready. The first blocked client's reply callback must call ValkeyModule_Call(ctx, "CLIENT", "ccl", "KILL", "ID", second_id) to kill the successor blocked client.
3. Load Module: Start the Valkey server with the malicious module loaded: ./valkey-server --port 6414 --loadmodule /tmp/readykey_iter_uaf.so.
4. Block First Client: From client A, issue the module's block command to block on a target key (e.g., readyuaf.block race first).
5. Block Second Client: From client B, issue the same block command as the successor (e.g., readyuaf.block race second), recording client B's ID for use in the reply callback.
6. Trigger the Race: From a third connection, signal the key as ready (e.g., readyuaf.signal race). This causes handleClientsBlockedOnKey() to serve client A's reply callback, which synchronously kills client B, freeing the cached listIter.next node and triggering the heap-use-after-free when the outer loop resumes (GitHub Issue).

• Logs: Valkey server crash logs or core dumps referencing src/adlist.c:267 (listNext), src/blocked.c (handleClientsBlockedOnKey), or AddressSanitizer output with heap-use-after-free at addresses within the blocked-client list.
• Process: Unexpected Valkey server process termination or restart; ASan abort messages (==ABORTING) in server stderr output.
• Network: Unusual sequences of module-specific commands followed by CLIENT KILL commands targeting specific client IDs on the same Valkey port; two clients blocking on the same key simultaneously via a custom module command.
• File System: Presence of unexpected .so module files loaded into the Valkey server (check MODULE LIST output); PoC-related files such as readykey_iter_uaf.so or PoC.zip on the server filesystem (GitHub Issue).

Apply the official patch commit b2fb0e13f5b4c8c2fb63dcfc2c37a067a0d6d20b, which was merged into the Valkey unstable branch on August 7, 2026, and backported to release branches 7.2, 8.0, 8.1, 9.0, and 9.1 by August 29–30, 2026. The fix replaces the unsafe listIter-based traversal with a snapshot of stable client IDs, re-resolving each client from the live blocking list before serving, and skipping any clients freed mid-loop. As a workaround where patching is not immediately possible, restrict the ability to load untrusted modules and enforce strict access controls on privileged Valkey connections to reduce the attack surface (Fix PR, Patch Commit).

The vulnerability was reported by researcher gff-cw via the Valkey GitHub issue tracker on July 17, 2026, with a detailed root cause analysis and PoC. Valkey maintainer ranshid noted that the vulnerable pattern likely predates version 9.1.0 and may affect versions as far back as 7.2, prompting backports across all active release branches. Contributor AlisinaDevelo independently reviewed the fix and flagged a potential ABA pointer-reuse edge case for module fake clients, which was subsequently addressed. The fix was also later rewritten in a simpler rotation-based approach (PR #4472) for improved readability (GitHub Issue, Fix PR).