• Posted by: Eng. Donya Bino
• February 11, 2026

Redis HLL Overflow → RCE in 8.0.0–8.0.2

A serious remote code execution vulnerability (CVE-2025-32023) was identified in Redis HyperLogLog (HLL) for all versions greater than (>=) 8.0.0 but less than (<) 8.0.3 (First and last respectively). This problem occurs during PFCOUNT and PFMERGE operations where Redis parses and merges sparse HyperLogLog structures using a malformed HLL value that has been produced with a large number of run lengths of zero (there is an integer overflow on internal counters when redis parses such an HLL value)."

When the resultant overflowed value is subsequently interpreted as a signed integer when merging, it will result in a huge negative index or length being computed, resulting in an out-of-bounds write to memory, leading to heap corruption and the potential for arbitrary code execution when Redis is running with elevated privileges or in an environment where host PID / network access exists.

Exploit Technical Details 
1. Header is configured with a valid sparse HyperLogLog (HYLL) magic number + encoding type (sparse), thus indicating to Redis parser that HLL will follow.
2. Huge amount of xzero spam, Appending 0x20000 runs of xzerovalue (0x4000) (max run length of 16383 zeros), each xzero needing 2 bytes results in total payload of ~256MB. Total count of xzero runs internally will overflow 32 bit field and yield negative when later recast to signed integer.
3. Trigger Exploitation : Calling pfcount() function against bad key forces redis to re-parse HLL and re-merge HLL into one object, causing heap out of bounds write by negative length/index and making adjacent structures become corrupted (often allocator metadata, function pointers or redis internal objects).

4. Remote Code Execution Methodology: Attackers can gain remote code execution by using this exploit in combination with the following methods:
a. Running Redis as root or a high-level user (outdated versions of either docker or K8S, i.e., kubernetes containers).
b. Using heap grooming techniques to arrange sensitive data within memory in proximity of an allocated area where the corrupted data applies.
c. Using follow-on writes to hijack the control flow (i.e., firing an appropriate function pointer, overwriting the exception handler, etc.).

The proof-of-concept should remain very small and trigger the overflow consistently but does not contain heap grooming or shellcode; this makes it a "safe" crash proof of concept used for testing purposes instead of a weaponized remote code execution attack.

Real-World Impact 
1. Affected Versions: Redis 8.0.0-8.0.2 (first public version with new Hadoop-HLL optimizations was made available in mid-2025)
2. Redis 8.0.3 (released Oct-2025) fixed this via constraints on runs, plus appropriate signed/unsigned handling
3. CVSS Score: 9.8 (Critical) : Exists remotely, without authenticated access (via any network) and has low exploitability.
4. Evidence of Exploitation: Shadowserver and GreyNoise reported spikes in scanning against Redis instances were seen within 48 hrs of when the vulnerability was disclosed. Additionally, many Redis honeypots were used to capture RCE chains of exploits through late Oct-2025, which in many instances included dropped miners or reverse shells.
5. Common Delivery Mechanisms: Unauthenticated redis endpoints (or have very weak passwords) on cloud VMs, Using Kubernetes StatefullSets, or some sort of misconfigured caching layer.

Mitigation Checklist 
1. Upgrade to a version of Redis that's greater than or equal to 8.0.3.
2. If using older versions of Redis (7.2.x, 7.4.x) there are patched versions of these branches available that do not have the vulnerabilities currently disclosed.
3. Do not expose Redis publicly (i.e., bind to the local host) and when doing so, should be implemented with TLS and strong authenticators.
4. Disable dangerous commands by utilizing Redis ACLs such as CONFIG, MODULE, SCRIPT command access.
5. Always run Redis with a non-root and low privileged user or have configured either Seccomp-Profiles or AppArmor-Profiles.
6. Ensure protected-mode is enabled and is still enabled since it's the default setting since v3.2 (please verify).
7. Monitor Redis process calls (or PFCOUNT, PFMERGE) for anomalies associated with specific key names.
8. Prevent Redis processes from creating unsolicited outbound connections by configuring firewall rules to block outgoing connections to known C2/miner pools.

If you're on Redis versions 8.0.0-8.0.2 and currently in production during the month of February 2026 these instances should be considered actively compromised until confirmed patched and forensically validated.

Source: Exploit DB