CVE-2026-66373: 
Redis vulnerability analysis and mitigation

CVE-2026-66373 is a double free vulnerability in Redis that allows authenticated attackers with RESTORE command access to achieve remote code execution (RCE). It affects all Redis versions before 8.8.0 and exists because of an incomplete fix for the prior vulnerability CVE-2026-25243. The flaw was published on July 25, 2026, and has a CVSS v3.1 base score of 7.5 (High) (Github Advisory, Feedly).

The root cause is a double free (CWE-415) in Redis's stream RDB/RESTORE loading logic within rdbLoadObject. When a crafted RESTORE payload is submitted where the same NACK (pending entry, streamNACK) is referenced by more than one consumer in a stream consumer group, the nack->consumer pointer is overwritten without checking if it was already assigned. When both consumers are subsequently deleted via XGROUP DELCONSUMER, the shared streamNACK is freed twice — the first deletion frees the memory, and the second leaves a dangling pointer that can be exploited for heap corruption and ultimately RCE. The fix (PR #15081) adds a guard in rdbLoadObject that checks nack->consumer != NULL before assigning the consumer pointer, rejecting corrupt RDB payloads with a "Bad data format" error (Redis PR #15081, Github Advisory). A public PoC repository (berabuddies/redis-poc) demonstrates exploitation across multiple Redis versions including 6.2.22, 7.4.9, and 8.6.4 (PoC Repo).

Successful exploitation grants an authenticated attacker with RESTORE command privileges full remote code execution on the Redis server, resulting in high confidentiality, integrity, and availability impact. An attacker can execute arbitrary OS commands as the Redis service account, potentially enabling data exfiltration, persistence, lateral movement within the network, or complete server compromise. The NVD SSVC assessment rates the technical impact as "total," reflecting the severity of a full system takeover (Github Advisory, Feedly).

1. Reconnaissance: Identify Redis instances (versions before 8.8.0) accessible over the network using tools like Shodan, Censys, or direct port scanning (default port 6379). Confirm the Redis version with the INFO server command after authentication.
2. Authentication: Authenticate to the Redis server using valid credentials (password or ACL user with RESTORE, EVAL, and XGROUP permissions).
3. Craft malicious RESTORE payload: Using the public PoC tools (e.g., P86_exploit.py for Redis 8.6.4), build a serialized stream RDB payload where two consumers (consumerA, consumerB) both reference the same NACK entry (e.g., entry ID 1-0). This requires computing valid CRC64 checksums using the bundled libcrc64.so helper.
4. Submit RESTORE command: Send the crafted payload to the target via the RESTORE command, loading the corrupt stream object into Redis memory. On vulnerable versions, the server accepts the payload without detecting the shared NACK invariant violation.
5. Trigger double free: Issue XGROUP DELCONSUMER for both consumers referencing the shared NACK. The first deletion frees the streamNACK memory; the second deletion frees the same memory again, corrupting the heap.
6. Heap grooming and RCE: Use additional Redis commands (e.g., EVAL for Lua scripting, further RESTORE calls) to groom the heap and gain control of execution flow, ultimately executing an arbitrary shell command (e.g., writing a file to /data/pwned) as the Redis process user (PoC Repo, Redis PR #15081).

• Network: Unusual or repeated RESTORE commands sent to Redis (port 6379) from unexpected source IPs; large binary payloads in Redis traffic consistent with crafted RDB stream objects.
• Logs: Redis logs showing Bad data format errors during RESTORE operations (on patched versions rejecting the payload); unexpected XGROUP DELCONSUMER commands issued in rapid succession for the same stream key.
• File System: Unexpected files written to the Redis data directory (e.g., /data/pwned*) or other directories writable by the Redis process; new cron jobs or scripts created by the Redis service account.
• Process: Unusual child processes spawned by the Redis server process (e.g., /bin/sh, bash, curl, wget, python3); unexpected outbound network connections from the Redis server process.
• Post-exploitation residue: Presence of exploit artifact keys in the Redis keyspace (the PoC deliberately leaves inert double-freed chunk keys); corrupted or zeroed tdigest/TopK structures if bundled RedisBloom module exploits were also used (PoC Repo).

Upgrade Redis to version 8.8.0 or later, which includes the fix from PR #15081 that rejects corrupt stream RDB payloads with shared NACKs at load time (Redis PR #15081, Github Advisory). Backports to older supported branches (6.2, 7.2, 7.4, 8.2, 8.4, 8.6) were initiated as of late July 2026 — monitor the Redis release page for patched versions in those branches. As a workaround until patching is possible, restrict the RESTORE command to only highly trusted users via Redis ACLs (ACL SETUSER <user> -RESTORE) and enforce network-level access controls (firewall rules, VPC isolation) to limit who can connect to the Redis server.

The vulnerability generated notable community discussion on Hacker News (HN thread) and was highlighted on social media, including a post by researcher @Fried_rice on X (Twitter) referencing the public PoC. Security news outlets including SecurityOnline.info covered the RCE implications, and the vulnerability was picked up by automated CVE tracking communities on Reddit (r/pwnhub) and Mastodon (infosec.exchange). Tenable published Nessus detection plugins (IDs 330019 and 331358) shortly after disclosure, reflecting rapid vendor tooling response (Tenable Plugin).