CVE-2026-66373: 
Redis vulnerability analysis and mitigation

CVE-2026-66373 is a double free vulnerability in Redis that allows an authenticated attacker with the ability to execute the RESTORE command to achieve remote code execution (RCE). It affects 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). A public PoC exploit is available targeting multiple Redis versions including 6.2.22, 7.4.9, and 8.6.4 (PoC Repo).

The root cause is a double free condition (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 structure is freed twice, resulting in heap corruption that can be leveraged for arbitrary code execution (Redis PR #15081). The fix adds a guard in rdbLoadObject that checks nack->consumer != NULL before assigning the consumer pointer, aborting with a "Bad data format" error on detection of this invariant violation (Redis PR #15081). Exploitation requires network access and low-privilege authentication (ability to run RESTORE, XGROUP, and EVAL commands), making it a network-based, high-complexity attack (Github Advisory).

Successful exploitation grants an attacker full remote code execution on the Redis server process, with high impact to confidentiality, integrity, and availability. An attacker can execute arbitrary shell commands, exfiltrate all data stored in Redis (including cached credentials, session tokens, or application secrets), corrupt or destroy data, and potentially pivot to other internal systems reachable from the Redis host (Github Advisory, PoC Repo). The NVD SSVC assessment rates the technical impact as "total," reflecting the complete compromise potential of a successful exploit (Github Advisory).

A public, functional PoC exploit repository (berabuddies/redis-poc) is available on GitHub, providing working exploit scripts for Redis versions 6.2.22, 7.4.9, and 8.6.4, with reported reliability rates of up to 25/25 on fresh containers (PoC Repo). The NVD SSVC classification lists exploitation status as "poc" and automatable as "no," reflecting that exploitation requires some manual setup and authenticated access (Github Advisory). The EPSS score is approximately 0.47–0.50%, placing it around the 40th percentile for exploitation probability within 30 days (Github Advisory). No confirmed in-the-wild exploitation or CISA KEV catalog listing has been reported as of the time of this report. No specific threat actor attribution is available.

1. Reconnaissance: Identify Redis instances accessible over the network (default port 6379) using tools like Shodan, Censys, or nmap. Confirm the version is below 8.8.0 using the INFO server command after authenticating.
2. Authenticate: Obtain or brute-force valid Redis credentials. The attacker must have at minimum the ability to execute RESTORE, XGROUP, and EVAL commands.
3. Craft malicious RESTORE payload: Build a serialized Redis stream RDB payload (using the CRC64 library provided in the PoC) where two consumers (consumerA, consumerB) in a stream consumer group both reference the same NACK entry (e.g., entry ID 1-0). This violates the stream data structure invariant (Redis PR #15081).
4. Execute RESTORE: Send the crafted payload to the target Redis server using the RESTORE command to load the malicious stream object into memory.
5. Trigger double free: Issue XGROUP DELCONSUMER for both consumers referencing the shared NACK. This causes the streamNACK structure to be freed twice, corrupting the heap.
6. Exploit heap corruption for RCE: Use heap grooming techniques (as demonstrated in the PoC scripts, e.g., P86_exploit.py for Redis 8.6.4) to control the double-freed memory and redirect execution flow, ultimately running an arbitrary shell command on the server (PoC Repo).

• Network: Unexpected or anomalous connections to Redis port 6379 from untrusted IP addresses; outbound connections from the Redis server process to external IPs (potential reverse shell).
• Logs: Redis server logs showing RESTORE commands followed by XGROUP DELCONSUMER commands in rapid succession; log entries containing "Bad data format" or corrupt RDB error messages (on patched versions detecting the attack attempt); authentication events from unusual source IPs.
• Process: Unusual child processes spawned by the Redis server process (e.g., /bin/sh, bash, curl, wget, python3); unexpected files written under /data/ (e.g., files named pwned* as left by the PoC exploit).
• File System: Presence of exploit residue keys in Redis keyspace (the PoC deliberately leaves exploit keys to keep double-freed chunks alive); unexpected scripts or binaries written to disk by the Redis process user (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 (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 July 23, 2026 (Redis PR #15081). Debian LTS users should apply the security update announced in August 2026. As a workaround until patching is possible, restrict the RESTORE command to only fully trusted users using 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 (https://news.ycombinator.com/item?id=49024938) and was highlighted on social media by security researchers, including a post by @Fried_rice on X (https://x.com/Fried_rice/status/2080059356322918777). The public release of a working multi-version PoC exploit repository (berabuddies/redis-poc) with 490 stars and 118 forks on GitHub attracted significant attention from the security community (PoC Repo). Security news outlets including SecurityOnline.info covered the RCE aspect of the vulnerability. The Debian LTS team issued a security announcement, and AUSCERT published a bulletin (ESB-2026.9207), reflecting broad awareness across the security ecosystem.