CVE-2026-25589: 
Redis vulnerability analysis and mitigation

CVE-2026-25589 is a heap-based buffer overflow vulnerability in the RedisBloom probabilistic data structures module for Redis, caused by improper validation of serialized values processed through the Redis RESTORE command. An authenticated attacker with permission to execute RESTORE on a server with the RedisBloom module loaded can supply a crafted serialized payload that triggers invalid memory access, potentially leading to remote code execution. All RedisBloom versions prior to 2.8.20 are affected. The vulnerability was published on May 5, 2026, and credited to Joseph Surin and Daniel Firer during the Wiz Zeroday Cloud event. It carries a CVSS v3.1 base score of 8.8 (High) and a CVSS v4.0 base score of 7.7 (High) (GitHub Advisory, RedisBloom Release).

The root cause is insufficient validation of serialized data processed by the RedisBloom module when handling the Redis RESTORE command, classified as CWE-122 (Heap-based Buffer Overflow) and CWE-20 (Improper Input Validation) (GitHub Advisory). An attacker crafts a malformed serialized payload and sends it via the RESTORE command, causing the module to perform unsafe memory accesses in the heap, which can be leveraged for arbitrary code execution. Exploitation requires three preconditions: the RedisBloom module must be loaded on the target Redis server, the attacker must be authenticated to the Redis instance, and the attacker must have permission to execute the RESTORE command. A GitHub repository referencing multiple Redis CVEs including this one has been identified, though it was assessed as a security advisory document rather than functional exploit code (GitHub PoC Repo).

Successful exploitation allows an authenticated attacker to execute arbitrary code in the context of the Redis server process, potentially resulting in full system compromise, data exfiltration, or service disruption (GitHub Advisory). The vulnerability has high impact on confidentiality, integrity, and availability of the affected Redis instance. Given that Redis servers often store sensitive application data and may have network access to other internal services, a compromised Redis instance could serve as a pivot point for lateral movement within an environment (Redis Blog).

1. Reconnaissance: Identify Redis servers with the RedisBloom module loaded, using network scanning tools (e.g., Shodan, Censys, or nmap targeting port 6379) and probing with MODULE LIST after authentication to confirm RedisBloom is active.
2. Authentication: Obtain valid Redis credentials (e.g., via credential stuffing, leaked secrets, or misconfigured instances with no authentication) and authenticate to the target Redis instance using redis-cli -h <target> -p 6379 -a <password>.
3. Verify RESTORE permission: Confirm the authenticated user has permission to execute the RESTORE command by issuing ACL WHOAMI and ACL CAT or attempting a benign RESTORE call.
4. Craft malicious payload: Construct a specially crafted serialized payload that exploits the insufficient validation in the RedisBloom module's deserialization logic, designed to trigger a heap-based buffer overflow.
5. Execute RESTORE command: Send the malicious payload via the RESTORE command (e.g., RESTORE <key> 0 <crafted_serialized_payload>) to the target server, triggering invalid memory access in the RedisBloom module.
6. Achieve code execution: If the heap overflow is successfully exploited, arbitrary code executes in the context of the Redis server process, enabling reverse shell establishment, data exfiltration, or further lateral movement (GitHub Advisory).

• Network: Unexpected or anomalous RESTORE command traffic to Redis port (default 6379/tcp) from unusual source IPs or at unusual times; outbound connections from the Redis server process to unknown external IPs.
• Logs: Redis server logs showing RESTORE commands with unusually large or malformed payloads; crash logs or core dumps generated by the Redis process indicating memory access violations.
• Process: Unexpected child processes spawned by the Redis server process (e.g., /bin/sh, bash, curl, wget); unusual CPU or memory spikes in the Redis process consistent with heap corruption.
• File System: Unexpected files written to directories accessible by the Redis service account; new cron jobs, SSH authorized keys, or scripts created under the Redis user's home directory.

Upgrade RedisBloom to version 2.8.20 or later, which contains the security fix for this vulnerability (RedisBloom Release). Note that starting with Redis 8, probabilistic data structures are integrated natively into Redis and the standalone RedisBloom module is no longer required. As an immediate workaround without patching, restrict access to the RESTORE command using Redis ACL rules — for example: ACL SETUSER <username> ~* &* -RESTORE — to prevent unauthorized users from executing the vulnerable command (GitHub Advisory). Additionally, enforce the principle of least privilege for all Redis user accounts and ensure Redis instances are not directly exposed to untrusted networks.

Redis published an official security advisory blog post covering this CVE alongside four other related Redis vulnerabilities (CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-23631) (Redis Blog). The Canadian Centre for Cyber Security (CCCS) issued a security advisory (AV26-423) covering the Redis vulnerabilities (CCCS Advisory), and HKCERT published a corresponding bulletin. Security news outlets including GBHackers, CyberSecurityNews, and CyberPress covered the Redis RCE vulnerabilities, highlighting the risk to exposed Redis deployments. The Wiz Zeroday Cloud event, where the vulnerability was discovered, also published a blog post covering the five Redis CVEs (Zeroday Cloud Blog).