Five high-severity vulnerabilities disclosed in a May 2026 Redis security advisory expose Redis Cloud, Redis Software, and all open-source community editions to remote code execution by authenticated attackers. The flaws span use-after-free conditions, invalid memory accesses, double-free bugs, and Lua scripting engine weaknesses, all of which can lead to arbitrary code execution or full system compromise in unpatched deployments.
Redis confirmed there is no evidence of active exploitation at the time of publication. However, the breadth of the disclosure, covering every supported Redis edition across cloud, enterprise, and community deployments, makes this a critical patching event for organizations relying on Redis as a core infrastructure component.
CVE-2026-23479: Use-After-Free in Unblock Client Flow
The first flaw, CVE-2026-23479 (CVSS 7.7), is a use-after-free vulnerability in the unblock client flow. When a blocked client is evicted while re-executing a blocked command, the Redis server fails to properly handle the error returned by processCommandAndResetClient. An authenticated user can deliberately trigger this condition to create a use-after-free scenario that may result in arbitrary code execution within the Redis server process.
Use-after-free vulnerabilities are particularly dangerous because they allow an attacker to control the contents of memory after it has been freed, potentially redirecting program execution to attacker-supplied code.
CVE-2026-25243: Invalid Memory Access via RESTORE Command
Tracked as CVE-2026-25243 (CVSS 7.7), this vulnerability affects the Redis RESTORE command. An authenticated user can send a specially crafted serialized payload that triggers an invalid memory access, potentially leading to arbitrary code execution. Independent researcher Emil Lerner discovered a double-free variant of this flaw, while Joseph Surin separately identified an integer overflow and out-of-bounds read in VectorSets, which were addressed in the same patch cycle.
CVE-2026-25588 and CVE-2026-25589: Module-Specific RESTORE Flaws
Two closely related vulnerabilities, CVE-2026-25588 and CVE-2026-25589 (both CVSS 7.7), affect the RESTORE command when used in conjunction with the RedisTimeSeries and RedisBloom modules respectively. Both allow authenticated attackers to trigger invalid memory accesses via crafted serialized payloads, resulting in the same remote code execution impact as CVE-2026-25243.
Joseph Surin, John Stephenson, and Annie Nie were credited with discovering the TimeSeries variant. Daniel Firer and Joseph Surin identified multiple RedisBloom issues including out-of-bounds reads and writes, integer overflow, and heap buffer overflow conditions. Several of these discoveries were made through Wiz ZeroDay.Cloud platform in partnership with Redis, highlighting the growing role of collaborative bug bounty programs in securing widely deployed open-source infrastructure.
CVE-2026-23631: Lua Use-After-Free via Replica Sync
The fifth flaw, CVE-2026-23631 (CVSS 6.1, medium severity), is a Lua scripting engine use-after-free vulnerability. An authenticated user can exploit the master-replica synchronization mechanism to trigger this condition. The flaw specifically affects Redis replicas configured with replica-read-only disabled, and exists across all Redis versions with Lua scripting enabled. Researcher Yoni Sherez (@yoyosh__) discovered this vulnerability.
Scope of Impact Across Redis Editions
The breadth of affected deployments is significant:
- Redis Cloud: All deployments have already been patched automatically, with no customer action required
- Redis OSS/CE (all releases): Fixed versions are 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3
- Redis Software up to and including 8.0.6: Fixes available in builds 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, and 7.2.4-153
- RedisTimeSeries module: Fixed in versions v1.12.14, v1.10.24, and v1.8.23
- RedisBloom module: Fixed in versions v2.8.20, v2.6.28, and v2.4.23
How to Protect Your Redis Infrastructure
Organizations running self-managed Redis instances should act immediately. Upgrading to the latest fixed release is the primary remediation step, with downloads available at redis.io/downloads. Beyond patching, administrators should take the following additional hardening steps:
- Restrict network access using firewalls and network policies to allow only trusted sources to connect to Redis instances
- Enforce strong authentication across all instances using ACL rules and complex passwords
- Keep Redis protected-mode enabled in CE and OSS deployments to prevent exposure on non-localhost interfaces
- Apply the principle of least privilege to Redis user permissions, limiting access to potentially dangerous commands like RESTORE
- Disable or restrict Lua scripting if not operationally required, particularly on replica instances with
replica-read-onlydisabled
Detection and Indicators of Exploitation
Although no active exploitation has been confirmed, organizations should monitor for indicators that may suggest attempted exploitation. These include unauthorized access attempts against Redis authentication, unexplained server crashes accompanied by Lua engine stack traces in logs, anomalous command execution originating from the redis-server process user, and unexpected modifications to Redis configuration files or persistent dump files.
Redis is one of the most widely deployed in-memory data stores in the world, serving as a caching layer, message broker, and session store in applications ranging from e-commerce platforms to financial services infrastructure. Given this ubiquity, these vulnerabilities represent a meaningful risk to organizations that delay patching, and administrators should prioritize bringing all self-managed instances to the fixed versions as quickly as their change management processes allow.