CVE-2026-82631: 
Valkey 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 (though the vulnerable pattern likely extends to earlier versions). Reported on July 17, 2026, and publicly disclosed on August 31, 2026, the flaw allows an authenticated remote attacker with high privileges to trigger a denial-of-service condition by causing the server to dereference a freed memory region during blocked-client iteration. It carries a CVSS v3.1 base score of 2.2 (Low) and a CVSS v4.0 base score of 1.2 (Low) (GitHub Advisory, Microsoft MSRC).

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 for a ready key using a plain adlist iterator (listIter), which caches the successor listNode* pointer. When a module-blocked client's reply callback (invoked synchronously via moduleTryServeClientBlockedOnKey) calls ValkeyModule_Call(ctx, "CLIENT", "ccl", "KILL", "ID", second_id), the server synchronously executes freeClient() on the successor blocked client. This teardown path calls unblockClientWaitingData(), which empties c->bstate->keys and invokes dictVanillaFree (i.e., zfree()) on the exact listNode* already cached as li.next in the outer iterator. When the outer loop resumes and calls listNext(&li), it dereferences the freed node, producing a heap-use-after-free confirmed by AddressSanitizer at src/adlist.c:267. A public PoC (readykey_iter_uaf.c) was released alongside the issue report (GitHub Issue #4198, PoC ZIP).

Successful exploitation results in a server-side crash (Denial of Service) of the Valkey server process, as the heap-use-after-free causes an abort under AddressSanitizer or undefined behavior in production builds. There is no confidentiality or integrity impact — the vulnerability is limited to availability. Because Valkey is commonly used as a high-performance caching and key-value store in production environments, a crash can disrupt dependent applications and services (GitHub Issue #4198, GitHub Advisory).

A proof-of-concept exploit (readykey_iter_uaf.c) was publicly released alongside the vulnerability report, requiring the attacker to load a custom Valkey module and have high-privilege access to the server. Exploitation requires high attack complexity — specifically, two clients must be blocked on the same key via ValkeyModule_BlockClientOnKeys(), and the first client's reply callback must synchronously kill the second via CLIENT KILL. The EPSS score is approximately 0.358%, and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the disclosure date. The NVD SSVC assessment classifies exploitation as "poc" with no automation (GitHub Issue #4198, GitHub Advisory).

1. Setup: Obtain high-privilege (authenticated) access to a Valkey 9.1.0 server instance that supports module loading.
2. Compile and load the PoC module: Build the readykey_iter_uaf.c shared library with AddressSanitizer enabled (gcc -shared -fPIC -O0 -g -Isrc readykey_iter_uaf.c -o /tmp/readykey_iter_uaf.so) and start the server with --loadmodule /tmp/readykey_iter_uaf.so.
3. Block first client: From client A, issue readyuaf.block race first — this blocks client A on the key race using ValkeyModule_BlockClientOnKeys() and registers a reply callback that will kill the successor client.
4. Block second client: From client B, issue readyuaf.block race second — this blocks client B on the same key race and records its client ID for the kill operation.
5. Signal the ready key: From a third connection, issue readyuaf.signal race — this triggers handleClientsBlockedOnKey() to iterate the blocked-client list for race.
6. Trigger UAF: The server serves client A first; client A's reply callback calls ValkeyModule_Call(ctx, "CLIENT", "ccl", "KILL", "ID", second_id), synchronously freeing client B's list node — which is already cached as li.next in the outer iterator. The outer loop then calls listNext(&li), dereferencing the freed node and triggering the heap-use-after-free, crashing the server (GitHub Issue #4198, PoC ZIP).

• Process: Valkey server process (valkey-server) crashes or aborts unexpectedly, particularly with an AddressSanitizer error message referencing heap-use-after-free at src/adlist.c:267 in listNext().
• Logs: Server logs showing ==ERROR: AddressSanitizer: heap-use-after-free with stack traces involving handleClientsBlockedOnKey, handleClientsBlockedOnKeys, moduleTryServeClientBlockedOnKey, and unblockClientWaitingData.
• Network: Unusual sequences of CLIENT KILL ID <id> commands issued from a module context (via ValkeyModule_Call) shortly after multiple clients block on the same key.
• File System: Presence of unexpected .so module files (e.g., readykey_iter_uaf.so) loaded into the Valkey server via --loadmodule or MODULE LOAD commands.

The fix is identified as commit b2fb0e13f5b4c8c2fb63dcfc2c37a067a0d6d20b, merged into the unstable branch on August 7, 2026, via PR #4212. The patch replaces the unsafe listIter-based traversal with a snapshot of stable client IDs, re-resolving each client from the live blocking list before serving, thereby preventing stale pointer dereferences across reentrant callbacks. Backports were applied to Valkey branches 7.2, 8.0, 8.1, 9.0, and 9.1 as of late August 2026. Operators should upgrade to a patched release as soon as available; as a short-term workaround, restrict module loading to trusted modules only and enforce strict access controls to limit high-privilege client access (GitHub PR #4212, Patch Commit).

The vulnerability was reported by researcher gff-cw via GitHub Issue #4198 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 identified a potential ABA pointer-reuse edge case in the initial patch, which was subsequently addressed. The fix was also later rewritten in a simpler rotation-based approach (PR #4472) by enjoy-binbin for improved readability (GitHub Issue #4198, GitHub PR #4212).