Redis fixes five vulnerabilities that can lead to remote code execution

Redis has released security updates for five vulnerabilities that can allow authenticated attackers to trigger remote code execution, crash servers, or compromise data in affected deployments.

The flaws affect Redis Software, Redis Open Source, and Redis Community Edition. Redis Cloud customers do not need to take action because Redis says cloud deployments have already received the fixes.

The most urgent issues involve memory corruption in Redis server features and Redis modules. Four vulnerabilities carry High severity scores of 7.7, while one Lua-related flaw carries a Medium severity score of 6.1.

What Redis disclosed

Redis published the advisory on May 5, 2026. The company said the vulnerabilities were found and fixed as part of its ongoing security work with the Redis community and external researchers.

All five flaws require authenticated access. That means attackers first need valid Redis access or credentials before they can exploit the bugs.

That requirement lowers the risk compared with unauthenticated remote code execution. However, the impact remains serious because many Redis instances run close to application data, session data, queues, caches, and internal services.

At a glance

CVE	Severity	Affected area	Potential impact
CVE-2026-23479	High, 7.7	Unblock client flow	Use-after-free that may lead to remote code execution.
CVE-2026-25243	High, 7.7	RESTORE command	Invalid memory access through crafted serialized payloads.
CVE-2026-25588	High, 7.7	RESTORE with RedisTimeSeries	Invalid memory access that may allow code execution.
CVE-2026-25589	High, 7.7	RESTORE with RedisBloom	Invalid memory access that may allow code execution.
CVE-2026-23631	Medium, 6.1	Lua scripting and replication	Use-after-free affecting replicas with replica-read-only disabled.

Why these Redis flaws matter

Redis often stores high-value operational data. Many teams use it for caching, queues, session storage, rate limiting, real-time application features, and temporary data pipelines.

If attackers gain authenticated access and exploit one of these bugs, they may execute code in the Redis server context. That can lead to data theft, service disruption, or broader system compromise depending on how the Redis server is deployed.

The RESTORE-related flaws deserve special attention because they involve serialized payloads. Attackers with permission to run RESTORE may craft malicious input that triggers memory errors inside Redis or affected modules.

RESTORE command flaws create RCE risk

CVE-2026-25243 affects the Redis RESTORE command. Redis says an authenticated user can send a specially crafted serialized payload that triggers invalid memory access and may lead to remote code execution.

CVE-2026-25588 affects RESTORE when RedisTimeSeries is loaded. The impact is similar, but the vulnerable path depends on the RedisTimeSeries module being present.

CVE-2026-25589 affects RESTORE when RedisBloom is loaded. Redis says the bug can also result in invalid memory access and potential code execution in the Redis server context.

Fixed versions

Product or module	Affected versions	Fixed versions
Redis OSS and Redis Community Edition	All releases listed by Redis as affected	6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3
Redis Software	Versions up to and including 8.0.6, unless already on a fixed build	8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, and 7.2.4-153
RedisTimeSeries	Affected module versions	1.12.14, 1.10.24, and 1.8.23
RedisBloom	Affected module versions	2.8.20, 2.6.28, and 2.4.23
Redis Cloud	Cloud deployments	Already patched by Redis

Lua and replication flaw affects specific deployments

CVE-2026-23631 is a Lua use-after-free vulnerability tied to Redis master-replica synchronization. It affects Redis replicas where replica-read-only is disabled or can be disabled.

The flaw exists across Redis versions with Lua scripting enabled. Redis rates this issue as Medium severity, but administrators should still review it carefully if their deployment uses replicas and allows writable replica behavior.

The safest fix remains upgrading to a patched Redis release. Where immediate patching needs more time, teams should review whether users can execute Lua scripts and whether replica-read-only has been disabled.

Who needs to act first

• Organizations running self-managed Redis OSS or Redis Community Edition.
• Teams running Redis Software up to and including version 8.0.6.
• Redis deployments exposed to application users, internal services, or untrusted networks.
• Environments where Redis users can run RESTORE.
• Deployments using RedisTimeSeries or RedisBloom modules.
• Replica setups where replica-read-only is disabled.
• Container images and appliances that bundle Redis or Redis modules.

How to reduce risk

The main fix is to upgrade Redis and affected modules to the corrected versions. Redis says self-managed customers should update Redis Software, Redis Open Source, or Redis Community Edition as soon as possible.

Administrators should also restrict network access. Redis should only accept connections from trusted applications, hosts, and private networks.

Strong authentication matters as well. Protected mode should remain enabled in Redis OSS and Community Edition deployments, and accounts should follow least-privilege rules.

Practical security checklist

• Upgrade Redis OSS or Community Edition to one of the fixed versions.
• Upgrade Redis Software to a fixed build listed by Redis.
• Patch RedisTimeSeries and RedisBloom if those modules are installed.
• Restrict access to the RESTORE command with ACL rules where possible.
• Limit Redis network exposure with firewalls and private network rules.
• Remove unnecessary Redis accounts and rotate credentials.
• Keep protected mode enabled for OSS and Community Edition instances.
• Review whether replicas have replica-read-only disabled.
• Rebuild containers that include vulnerable Redis packages.
• Restart Redis services after updates so fixed binaries load correctly.

What to monitor for signs of exploitation

Redis says it has no evidence of exploitation in Redis or customer environments at the time of publication. Even so, administrators should check for signs that attackers tried to abuse exposed or poorly protected instances.

Security teams should look for unknown Redis access, unusual inbound or outbound traffic, unexplained crashes, unexpected command execution by the redis-server user, and changes to Redis configuration or persistence files.

Lua-related crashes need extra attention, especially when stack traces point to the Lua engine. Teams should also review suspicious RESTORE activity and module-related errors on systems using RedisTimeSeries or RedisBloom.

FAQ