What happened?

As part of an ongoing effort by the Redis community and Redis to maintain safety, security, and compliance posture, five security vulnerabilities in Redis have been proactively identified and [remediated in the versions indicated below].

What are the vulnerabilities?

1. CVE‑2026‑23479 – Use-After-Free in unblock client flow may lead to Remote Code Execution.
   CVSS Score: 7.7 (High)
   When a blocked client is evicted while re-executing a blocked command, an authenticated user may trigger a use-after-free and potentially lead to remote code execution. The code doesn't handle the case where processing the command (processCommandAndResetClient) returns an error value.
2. CVE‑2026‑25243 – Invalid Memory Access in Redis RESTORE Command May Lead to Remote Code Execution.
   CVSS Score: 7.7 (High)
   A vulnerability in the Redis RESTORE command allows an authenticated user to trigger an invalid memory access via a specially crafted serialized payload, potentially resulting in remote code execution.
   Successful exploitation could allow an attacker with authenticated access to execute arbitrary code in the context of the Redis server, potentially leading to full compromise of the affected system, data exfiltration, or service disruption.
3. CVE-2026-25588 - Invalid Memory Access in RESTORE Command When Used with RedisTimeSeries module May Lead to Remote Code Execution.
   CVSS Score: 7.7 (High)
   A vulnerability in the RESTORE command, when used with the RedisTimeSeries module, allows an authenticated attacker to trigger invalid memory access via a specially crafted serialized payload, potentially resulting in remote code execution.
   Successful exploitation could allow an attacker with authenticated access to execute arbitrary code in the context of the Redis server, when used with the RedisTimeSeries module, potentially leading to full compromise of the affected system, data exfiltration, or service disruption.
4. CVE‑2026‑25589 – Invalid Memory Access in RESTORE Command When Used with RedisBloom module May Lead to Remote Code Execution.
   CVSS Score: 7.7 (High)
   A vulnerability in the RESTORE command, when used with the RedisBloom module, allows an authenticated attacker to trigger invalid memory access via a specially crafted serialized payload, potentially resulting in remote code execution.
   Successful exploitation could allow an attacker with authenticated access to execute arbitrary code in the context of the Redis server, when used with the RedisBloom module, potentially leading to full compromise of the affected system, data exfiltration, or service disruption.
5. [CVE-2026-23631] - Lua Use-After-Free may lead to remote code execution.
   CVSS Score: 6.1 (Medium)
   An authenticated user may exploit the synchronization mechanism of the master-replica and trigger a use-after-free vulnerability, potentially leading to remote code execution. The bug affects only replicas that are configured, or may be configured with replica-read-only disabled, and exists in all versions of Redis with Lua scripting.

How can you protect your Redis instance?

If you’re a Redis Cloud customer, your Redis instance is protected against these vulnerabilities, as we’ve already upgraded our Redis Cloud service with the fixes. If you’re self-managing Redis Software, Open Source (OSS), or Community (CE) versions, there are several steps you should take to protect your Redis from exploitation.Exposure to these vulnerabilities requires an attacker to gain authenticated access to your Redis instance, making this a post-authentication issue that can lead to remote code execution (RCE).

To remediate against these vulnerabilities, upgrade your Redis to the latest versions, see our table below for full details. To minimize the risk of exploitation, it’s important to follow these best practices:

• Restrict Network Access: Ensure that only authorized users and systems have access to the Redis database. Use firewalls and network policies to limit access to trusted sources and prevent unauthorized connectivity.
• Enforce Strong Authentication: Enforce the use of credentials for all access to Redis instances. Avoid configurations that allow unauthenticated access, and ensure protected-mode is enabled (in CE and OSS) to prevent accidental exposure.
• Limit Permissions: Ensure that user identities with access to Redis are granted the minimum permissions necessary. Only allow trusted identities to run potentially risky commands.
• Update Regularly: Keep Redis updated to the latest version for the newest security patches.

For more details on how to securely configure, deploy, and use Redis, visit the Community Edition and Enterprise Software documentation sites.

Am I impacted and how can I remediate?

If you’re a Redis Cloud customer, we’ve already upgraded our Redis Cloud service with the fixes, so no additional action is required from you.

If you’re self-managing Redis, whether Software or Community versions, upgrade your Redis to the latest release.

The versions of Redis OSS, CE and Software listed below and future versions include the corrections. Once the upgrades are performed, the vulnerability will be remediated in your environment.

You can download the latest versions here: https://redis.io/downloads/

How can I tell if I was already exposed and how can I identify exploitation?

Refer to the table above to identify if you are on a vulnerable version.

As of this publication we have no evidence of exploitation of these vulnerabilities at Redis or in customer environments.

This isn’t a comprehensive guide, but it is a general recommendation you can adapt to your needs and operating environment.

There are a number of technical and behavioral indicators or artifacts that may be created if exploitation of the vulnerability occurred. If you search for these within your Redis environment, you should be able to detect potential exploitation related to your Redis instance.

• Access to the Redis database from unauthorized or unknown sources
• Unknown or anomalous network ingress traffic to the Redis database
• Unexplained Redis server crashes, specifically crashes with a stack trace that originates from the Lua engine
• Unknown, unexpected, or anomalous command execution by the redis-server user
• Unknown or anomalous network egress traffic (or attempts) from the Redis database
• Unknown or anomalous changes to the file system, in particular in directories that host Redis persistent or configuration files

Who gets the credit?

We thank the following researchers for their vigilance in reporting these vulnerabilities through our published process. We would also like to thank Wiz for the partnership and hosting Wiz ZeroDay.Cloud, where a number of these vulnerabilities were identified:

• [CVE‑2026‑23479] reported by independent researchers Team Xint Code (Tim Becker @tjbecker, Jacob Newman, and Juno IM)
• [CVE‑2026‑25243] the following issues were reported by:
  • Redis: double-free, discovered by independent researcher Emil Lerner (@emil_lerner)
  • VectorSets - Integer overflow and Out-Of-Bounds read. discovered by the independent researcher Joseph Surin.
• [CVE-2026-25588] discovered by independent researchers Team Skateboarding Dog (Joseph Surin, John Stephenson, and Annie Nie)
• [CVE‑2026‑25589] – the following issues were reported by:
  • RedisBloom: Out-Of-Bounds read/write, discovered by Daniel Firer
  • RedisBloom - Integer overflow, heap buffer overflow, and Out-Of-Bounds read/write, discovered by independent researcher Joseph Surin.
• [CVE-2026-23631] discovered by independent researcher Yoni Sherez (@yoyosh__)