Redis RCE in 2026: Five Patched CVEs and the 27-Minute AI Discovery Defenders Should Note

Update, 23 July 2026. Redis has shipped a further security release set since the May advisory this post was originally written about. Redis 6.2.23, 7.2.15, and 7.4.10 fix a Streams shared NACK use after free that may lead to remote code execution. Redis 8.2.8, 8.4.5, and 8.6.5 fix that same Streams flaw plus out of bounds writes reachable through crafted RESTORE payloads in RedisBloom and TDigest. Redis 8.8.1 fixes the RedisBloom and TDigest loaders (Redis release notes).

This matters operationally, because the May fixed builds are themselves the builds under public attack. Non destructive but working authenticated RCE proofs of concept have been published against stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0, and three of those were the exact builds the May advisory told administrators to install (The Hacker News). If you patched in May and stopped there, you are running a build with a published proof of concept. Upgrade past it to the July release on your line. Neither Redis's July release notes nor the public proof of concept material reported exploitation in the wild as of July 24 2026.

On the 8.8 line, treat 8.8.1 as the current floor rather than a proven endpoint. Public proof of concept material also lists 8.8.1 as a target, through a separate invalid free in the bundled RedisBloom TopK path, and Redis has published no advisory settling that specific claim. Install 8.8.1 now, track Redis's next 8.8 release, and in the meantime apply the module hardening in the remediation checklist below: restrict RESTORE by ACL and unload probabilistic modules you do not use.

On May 5 2026, Redis published a single advisory patching five separate vulnerabilities, four of them rated CVSS 7.7 High on the v4.0 scale the advisory uses, every one a post authentication path that may lead to remote code execution on a self managed Redis server (Redis Security Advisory). The National Vulnerability Database scores four of those five identically, at CVSS v3.1 8.8 High and v4.0 7.7 High: CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, and CVE-2026-25589, classified CWE-122 or CWE-416 (NVD). The Canadian Centre for Cyber Security mirrored the same set as advisory AV26-423 the same day (Canadian Centre for Cyber Security). The common thread across most of these bugs is the RESTORE command mishandling a crafted serialized payload, in the core and in bundled modules.

Then, in late July 2026, something different and louder was reported: researcher Chaofan Shou, of a group self described as Bera Buddies, posted on X that Moonshot AI's Kimi K3 agents had found roughly 19 Redis zero days in about 90 minutes, and that a separate run produced a working exploit against Redis 8.8.0 in 27 minutes (The Hacker News; CyberPress). Those two events are not the same event, and conflating them is the single biggest reporting error circulating this month. The five patched CVEs were credited by Redis to named human researchers. The Kimi K3 claim is a separate, still developing story whose counts, timings, and degree of autonomy are self reported. This post keeps them cleanly apart.

Here is the direct answer defenders came for. The 2026 Redis RCE CVEs are CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, and CVE-2026-23631, all patched by Redis on May 5 2026, and the builds to run today are the July 23 2026 releases that supersede those May fixes. You are affected if you self manage Redis Software, OSS, or CE, especially with the RedisBloom or RedisTimeSeries modules loaded; Redis Cloud is already patched. And yes, an AI agent reportedly built a working exploit against one specific Redis build, 8.8.0, in about 27 minutes, but that July 2026 claim is a distinct, self reported event from the five May 2026 CVEs, which humans reported.

This post is the Stingrai research team's canonical 2026 reference for the Redis RCE CVEs and the AI discovery claim. It carries every figure with attribution to three primary publishers: Redis, the National Vulnerability Database, and the Canadian Centre for Cyber Security, plus clearly labelled press coverage for the separate Kimi K3 story. The advisory data is the freshest available: the five CVEs were disclosed May 5 2026, Redis shipped a further security release set on July 23 2026, and the AI claim surfaced in the same window. Every stat below carries its source, year, and severity basis so any claim can be audited against the primary advisory inline. There are no proof of concept steps or payloads here; this is a defender briefing.

TL;DR: the 2026 Redis RCE CVEs at a glance

• A second release set landed on July 23 2026: Redis shipped 6.2.23, 7.2.15, and 7.4.10 for a Streams shared NACK use after free; 8.2.8, 8.4.5, and 8.6.5 for that plus RedisBloom and TDigest out of bounds writes; and 8.8.1 for the RedisBloom and TDigest loaders (Redis release notes).

• The May fixed builds are now proof of concept targets (2026): published authenticated RCE proofs of concept target stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0, so a deployment that patched in May and stopped is running a build with a public proof of concept (The Hacker News).

• Five CVEs, one advisory (2026): Redis patched CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, and CVE-2026-23631 on May 5 2026, all post authentication RCE paths (Redis Security Advisory).

• Four of the five share one NVD score (2026): NVD rates CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, and CVE-2026-25589 identically at CVSS v3.1 8.8 High and v4.0 7.7 High, classified CWE-122 or CWE-416, so none of them outranks the others (NVD).

• Four High, one Medium on the v4.0 scale (2026): the Redis advisory rates the four memory safety RCE flaws at CVSS 7.7 High and the Lua use after free at 6.1 Medium; NVD's own v3.1 score for that Lua flaw is 8.1 High (Redis Security Advisory; NVD).

• RESTORE is the pivot (2026): three flaws abuse a crafted serialized payload through the RESTORE command, two of those through the RedisBloom and RedisTimeSeries modules (Redis Security Advisory).

• Current fixed core builds (2026): upgrade Redis OSS or CE to 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, or 8.8.1 on your line. The May builds 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3 close the five CVEs but not the July flaws (Redis release notes).

• Fixed RedisBloom (2026): upgrade the module to v2.8.20, v2.6.28, or v2.4.23 (Redis Security Advisory).

• Fixed RedisTimeSeries (2026): upgrade the module to v1.12.14, v1.10.24, or v1.8.23; NVD gives the boundary as all versions before 1.12.14 (Redis Security Advisory; NVD).

• Redis Cloud already patched (2026): the exposed population is self managed Redis Software, OSS, and CE (Redis Security Advisory).

• No confirmed exploitation in the wild (2026): Redis reported no evidence of exploitation as of the May advisory, and none was reported as of July 24 2026 (Redis Security Advisory; The Hacker News).

• Canada advisory (2026): the Canadian Centre for Cyber Security issued AV26-423 on May 5 2026 covering the same five CVEs (Canadian Centre for Cyber Security).

• The AI claim is separate (2026): researcher Chaofan Shou, of a group self described as Bera Buddies, reported on X roughly 19 Redis zero days in about 90 minutes, with one run producing a Redis 8.8.0 exploit in 27 minutes. Those figures are self reported and are not the five patched CVEs (The Hacker News).

Key takeaways

The AI headline and the patched CVEs are two different stories, and the difference matters. Redis credited the five May 2026 CVEs to named human researchers in its own advisory (Redis Security Advisory). The separate July 2026 claim, that Kimi K3 agents found roughly 19 Redis zero days in about 90 minutes and that one run built a working exploit against Redis 8.8.0 in 27 minutes, comes from researcher Chaofan Shou on X and is self reported: Redis has since confirmed and fixed the underlying flaws, but has not validated the zero day count or the degree of autonomy (The Hacker News). If a briefing blurs the two, it credits an AI with human work and misstates what has actually been patched.

These are post authentication flaws, which changes the risk model, not the urgency. Every one requires an attacker to already hold authenticated access before it can be reached (Redis Security Advisory). That is not comfort: exposed Redis instances, reused credentials, over broad ACLs, and application service accounts with RESTORE rights all convert a foothold into code execution on the datastore. Post auth RCE on a core data service is a full compromise primitive.

RESTORE and loaded modules are where the exposure concentrates. Three of the five flaws run through the RESTORE command and a crafted serialized payload, and two of those are reachable specifically when the RedisBloom or RedisTimeSeries modules are loaded (Redis Security Advisory). Teams that run these probabilistic and time series modules carry more of this surface than a plain key value cache does.

Patching means two coordinated upgrades, not one, and the target moved in July. The core fix does not patch the module flaws: RedisBloom must reach v2.8.20 and RedisTimeSeries must reach v1.12.14 on their respective lines to close CVE-2026-25589 and CVE-2026-25588 (Redis Security Advisory). A core only upgrade can leave a loaded module vulnerable. And the core target is no longer 8.6.3 and its sibling May builds; it is 8.6.5 and the rest of the July 23 2026 set (Redis release notes).

Autonomous discovery of core infrastructure bugs is now a defender planning assumption. Whether or not the specific 27 minute figure holds up, the direction is clear: agentic tooling compresses discovery on widely deployed software, and open weights lower the barrier further (CyberPress). The defensive answer is not a single annual test but continuous, threat led validation of the paths that matter.

Methodology

This briefing draws on three primary sources plus clearly labelled tech press, with publication windows noted:

• Redis, Security Advisory (published May 5 2026): the authoritative source for the five CVE identifiers, flaw descriptions, the CVSS 7.7 and 6.1 v4.0 ratings, affected and fixed versions for core and modules, remediation guidance, exploitation status, and the human researcher credits.

• Redis, release notes (published July 23 2026): the authoritative source for the second security release set, its exact version numbers, and the plain language descriptions of the Streams shared NACK use after free and the RedisBloom and TDigest out of bounds writes. Redis assigned no CVE identifier to either in those notes.

• National Vulnerability Database (retrieved July 2026): used for the independent NIST CVSS v3.1 base scores across all five CVEs, the CNA v4.0 base scores, the CWE-122 and CWE-416 classifications, and the RedisBloom before 2.8.20 and RedisTimeSeries before 1.12.14 version boundaries.

• Canadian Centre for Cyber Security, advisory AV26-423 (issued May 5 2026): used as the Canadian government mirror confirming the same five CVEs and the patch guidance.

• Press coverage for the separate AI claim (published July 2026): The Hacker News for the named claimant and the scoped figures, and CyberPress for the 27 minute framing and the open weights release date. Used only for the developing, self reported Kimi K3 story, and kept explicitly distinct from the patched CVEs.

Research cutoff for this pass was July 24 2026. Every numeric claim above traces to one of these named sources. Where a figure could not be confirmed against a primary advisory, it was left out rather than estimated. Severity numbers are presented on their stated basis: the Redis advisory rating where Redis is the source, and the NVD rating where NVD is the source, so the two are never silently merged. This post carries no proof of concept links, repository names, or exploitation steps.

The five CVEs, defender altitude

At a CISO briefing altitude, the pattern is simple. Four of the five bugs are memory safety defects, a use after free or an invalid memory access, that an authenticated client can trigger to run code inside the Redis process. The fifth is a Lua scripting use after free. None is a pre authentication internet worm; all of them turn authenticated access to Redis into potential code execution on the host.

Descriptions and the v4.0 ratings are from the Redis Security Advisory; the NVD column carries the NIST assigned CVSS v3.1 base scores and CWE classifications from the NVD. Read the two columns as two scales, not as a disagreement. The practical point is that NVD does not single any of the four RCE flaws out as worse than the others: CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, and CVE-2026-25589 all sit at 8.8 High. A reader who ranks by NVD score and reaches for the module bug first has the priority backwards, because the core RESTORE flaw CVE-2026-25243 affects every OSS and CE release regardless of which modules are loaded, while the RedisBloom and RedisTimeSeries flaws only bite where those modules are present.

Figure 1: The five Redis 2026 CVEs on both scoring scales. Four of the five carry identical NVD v3.1 scores. Source: NVD (NIST v3.1 base scores, retrieved July 2026); CVSS v4.0 base scores as cited in the Redis Security Advisory (May 5 2026).

The RESTORE thread

The RESTORE command rebuilds a key from a serialized value, the same format DUMP produces. Three of these flaws, CVE-2026-25243 in the core and CVE-2026-25588 and CVE-2026-25589 in the modules, share the same shape: a specially crafted serialized payload passed to RESTORE reaches an invalid memory access that an authenticated attacker can steer toward code execution (Redis Security Advisory). NVD classifies the RedisBloom case as a heap based buffer overflow, CWE-122, rooted in the module not validating serialized values before it processes them (NVD). The practical takeaway for defenders is that RESTORE is a privileged, high blast radius command, and any identity that can call it against a vulnerable build is a code execution risk.

The module multiplier

CVE-2026-25588 and CVE-2026-25589 only bite when the RedisTimeSeries or RedisBloom modules are loaded. That is a meaningful scoping signal. A team running a plain Redis cache with no modules still needs the core fixes for CVE-2026-23479, CVE-2026-25243, and CVE-2026-23631, but does not carry the two module CVEs. A team running Bloom filters, cardinality sketches, or time series workloads carries the full set and needs both the core and the module upgrades.

The Lua edge case

CVE-2026-23631 is the outlier, though how much of an outlier depends on the scale. It is rated 6.1 Medium on the v4.0 scale the Redis advisory uses, but NVD's own NIST assigned CVSS v3.1 base score is 8.1 High (NVD). Do not file it as a low priority on the strength of the 6.1 alone. It is a Lua use after free reachable through the master replica synchronization mechanism, and, per the advisory, it affects only replicas configured, or configurable, with replica-read-only disabled, in Redis builds that ship Lua scripting (Redis Security Advisory). If you keep replica-read-only enabled, which is the default posture, your exposure to this specific flaw is narrower. It still upgrades away with the same core releases.

Affected versions and the fixed releases

Redis Cloud customers are already covered; Redis applied the fixes to its cloud builds and states no customer action is required. The population that must act is self managed Redis Software, OSS, and CE. Redis Software up to and including 8.0.6 is impacted unless already on a fixed build in the same line, and all Redis OSS and CE releases are impacted (Redis Security Advisory).

Read the two right hand columns in order. The May 5 2026 column is the history: those builds close the five CVEs and nothing more. The July 23 2026 column is what you should actually be running, because Redis found further remote code execution paths in the May builds themselves.

The May column is quoted from the Redis Security Advisory; the July column is quoted from the Redis release notes published July 23 2026. The module version boundaries are corroborated by the NVD entries for CVE-2026-25589 and CVE-2026-25588. Pick the current fixed release on your major line, so an 8.6 core deployment moves to 8.6.5 and a 7.4 deployment moves to 7.4.10.

One scoping note on the July set, because the seven builds are not interchangeable. The release notes for 6.2.23, 7.2.15, and 7.4.10 carry the Streams shared NACK fix alone. The notes for 8.2.8, 8.4.5, and 8.6.5 carry both the Streams fix and the RedisBloom and TDigest out of bounds write fix. The notes for 8.8.1 carry the RedisBloom and TDigest loader fix alone, because the 8.8 line already shipped with the Streams guard in place (Redis release notes). If you run bundled probabilistic modules on a 6.2 or 7.x line, that asymmetry is a reason to plan a major line upgrade rather than assume the patch release on your line covers you.

Figure 2: The current fixed releases, and the May builds they supersede. Source: Redis release notes (July 23 2026); Redis Security Advisory (May 5 2026).

Am I affected?

Work through this quickly. You are in scope if all or several of these are true:

• You self manage Redis Software, OSS, or CE rather than consuming Redis Cloud.

• Your Redis build is older than the July 23 2026 fixed release on your line. Being on a May 2026 build is not sufficient; those builds are in scope for the July flaws.

• You are running 6.2.22, 7.4.9, 8.6.4, or 8.8.0 specifically. These are the stock builds with published authenticated RCE proofs of concept, so treat them as the highest priority upgrades in your estate.

• You load the RedisBloom or RedisTimeSeries modules, which adds CVE-2026-25589 or CVE-2026-25588, and which is also the surface the July TDigest fix addresses.

• Application service accounts or admins can call RESTORE, the pivot for three of the five CVEs and for both July flaws.

• You run replicas with replica-read-only disabled, which adds the Lua flaw CVE-2026-23631.

Reachability still requires authenticated access, so an internet exposed Redis with weak or absent authentication is the worst case, because it shortens the distance to that authenticated foothold. Redis reported no evidence of exploitation as of the May advisory, and none had been reported as of July 24 2026 (Redis Security Advisory; The Hacker News). That supports a planned change window rather than a panic. It is not a reason to defer, and the existence of published proofs of concept against the May builds compresses the window you have.

Remediation checklist

This is remediation only. There are no exploit steps in this post.

1. Upgrade the core to a July 23 2026 build, not a May one. Move Redis OSS or CE to the current fixed release on your line: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, or 8.8.1 (Redis release notes). Do not stop at the May builds. Three of the May fixed releases, 6.2.22, 7.4.9, and 8.6.4, are themselves the stock builds with published authenticated remote code execution proofs of concept, so you must upgrade past them, not to them (The Hacker News). For Redis Software, the May advisory named 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, and 7.2.4-153 as the fixes for the five CVEs (Redis Security Advisory); check the Redis Software release notes for the current build on your line before you schedule the change.

2. On the 8.8 line, install 8.8.1 and keep watching. 8.8.1 is the current floor, but public proof of concept material also lists it as a target through a separate invalid free in the bundled RedisBloom TopK path, and Redis has published no advisory settling that claim. Install 8.8.1, subscribe to Redis release announcements, and apply the ACL and module loading controls in steps 4 and 5 below as compensating controls in the meantime.

3. Upgrade the modules too. If RedisBloom is loaded, reach v2.8.20, v2.6.28, or v2.4.23. If RedisTimeSeries is loaded, reach v1.12.14, v1.10.24, or v1.8.23. A core upgrade alone does not close the module CVEs, and, conversely, a module upgrade alone does not close the bundled TDigest out of bounds write that the July core builds fix.

4. Restrict RESTORE with ACLs. Grant RESTORE only to identities that genuinely need it, and remove it from application service accounts that do not. NVD notes ACL restriction of RESTORE as a temporary workaround for the RedisBloom case (NVD). This is the single highest value compensating control here, because RESTORE is the entry point for three of the five CVEs and for both July flaws.

5. Constrain module loading. Limit who can load modules and audit which modules are actually loaded in production; unload modules you do not use. On the 8.x lines the probabilistic modules are bundled by default, so "we never installed RedisBloom" is not the same as "RedisBloom is not loaded". Check.

6. Enforce strong authentication and protected mode. Require credentials for all access and keep protected mode enabled on CE and OSS, as the advisory recommends (Redis Security Advisory).

7. Segment Redis off the public internet. Put Redis behind firewalls and network policy so only trusted application tiers can reach it. An unreachable port is an unexploitable one.

8. Keep replica-read-only enabled unless you have a specific, reviewed reason to disable it, which narrows CVE-2026-23631.

9. Monitor for the advisory's indicators. Watch for access from unknown sources, anomalous ingress or egress, unexplained crashes with a Lua stack trace, and unexpected command execution or file system changes by the redis-server user (Redis Security Advisory).

Sidebar: the separate 27-minute AI discovery claim

This section is a clearly labelled, developing story. It is not the five patched CVEs above.

The claim has a named claimant, which matters when you are weighing it. Researcher Chaofan Shou, of a group self described as Bera Buddies, posted on X that Moonshot AI's Kimi K3 agents found roughly 19 Redis zero days in about 90 minutes, and that a separate run produced a working exploit against Redis 8.8.0 in 27 minutes (The Hacker News). Note the scoping: the 27 minute figure attaches to one run against one build, not to Redis class RCE discovery in general, and the two numbers describe different things. Coverage also notes the model's open weights were scheduled for public release on July 27 2026, which is the part that should hold a CISO's attention: once capable agents run privately, discovery pressure on widely deployed infrastructure rises (CyberPress).

The technical substance behind the headline is two distinct bug classes, and press coverage has attached the wrong label to one of them. The first is a stream consumer group shared NACK double free, reachable on stock builds including 6.2.22, 7.4.9, and 8.6.4; this is the finding the published proof of concept material frames as belonging to a CVE-2026-25589 "incomplete fix family" (Cybersecurity News). That framing is contested: Redis maps CVE-2026-25589 to RedisBloom memory corruption during RESTORE, not to the Streams flaw (The Hacker News). The second, separate finding is a heap overflow in the bundled RedisBloom TDigest path on 8.8.0, a build that already carried the Streams guard, which is why Redis's 8.8.1 notes list only the RedisBloom and TDigest loader fix (Redis release notes). Redis has now fixed both classes.

Two cautions keep this honest. First, the counts, the timings, and the degree of autonomy are all self reported. Redis has since confirmed the underlying flaws and shipped fixes for them on July 23 2026, but it has not validated the claimed zero day count or how independently the agents worked, and it assigned no CVE identifier to either July flaw in its release notes (Redis release notes; The Hacker News). Treat the 27 minute figure as a reported claim about one run, not a settled benchmark. Second, and most important, this is not the same event as the May 2026 advisory. Some coverage has listed the five patched CVE identifiers directly under the Kimi K3 headline, which reads as if an AI found them. It did not. Redis's own advisory credits those five CVEs to named human researchers who reported them through its disclosure process (Redis Security Advisory). The autonomous agent story and the patched CVE story overlap only in that both concern Redis.

Figure 3: Two events, kept distinct. Left, the human reported and patched CVEs (May 5 2026). Right, the separate self reported AI claim (July 2026). Source: Redis Security Advisory; Redis release notes; The Hacker News and CyberPress.

What this means for defenders

The Redis advisory looked like a clean patch story in May: upgrade the core, upgrade the modules, tighten RESTORE and network exposure, and monitor. What July showed is that the patch story was not finished. The builds the May advisory told administrators to install were, eleven weeks later, the builds with published authenticated RCE proofs of concept against them. Any team that treated "we applied the May advisory" as a closed ticket is now behind, and the only thing that would have caught that is a process that keeps re checking, rather than a one time remediation sign off.

The Kimi K3 claim is the strategic signal underneath it. When an AI agent can plausibly build a working exploit against a current build of core infrastructure in under half an hour, and when the weights to run such agents privately are days from public release, point in time assurance stops being enough. The gap between a patch shipping and an attacker reaching an unpatched instance keeps shrinking, and, as this advisory showed, so does the shelf life of the patch itself.

That is why continuous, threat led validation is now table stakes rather than a nice to have. An annual test tells you about the day it ran; agentic red teaming and human led AI red teaming keep testing the paths that matter as your estate changes. For a datastore and infrastructure layer like Redis, the highest signal work stays with senior human pentesters, and with human led offensive security operations that reason about ACL design, RESTORE permissioning, module exposure, replication topology, and network segmentation, the exact factors that decide whether a post authentication flaw is reachable in your environment.

Stingrai, a CREST-accredited firm based in Canada, brings that combination. Our senior human pentesters and red team lead the datastore and infrastructure work, while our autonomous agent, Snipe, hunts the complex web application vulnerability classes that generic scanners miss: broken authorization, insecure direct object references, and business logic flaws. Snipe performs both black box dynamic testing and white box source review, opens AutoFix pull requests for what it finds, and can run as a pull request gating check so vulnerable code is caught before it merges. Together, continuous PTaaS coverage and threat led validation produce the evidence your SOC 2, ISO 27001, and PCI DSS programs rely on, and shorten the window an advisory like this one leaves open. See Stingrai pricing for how engagements are scoped.

Frequently Asked Questions

What are the 2026 Redis RCE CVEs?

The 2026 Redis RCE CVEs are CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, and CVE-2026-23631, all patched by Redis on May 5 2026. On the CVSS v4.0 scale the Redis advisory uses, four are rated 7.7 High and the Lua flaw CVE-2026-23631 is rated 6.1 Medium; on NVD's CVSS v3.1 scale the same four are all 8.8 High and the Lua flaw is 8.1 High. Every one is a post authentication path that may lead to remote code execution (Redis Security Advisory; NVD).

Am I affected by the 2026 Redis CVEs?

You are affected if you self manage Redis Software, OSS, or CE on a build older than the July 23 2026 fixed release on your line, especially with the RedisBloom or RedisTimeSeries modules loaded or with identities that can call RESTORE. Being on a May 2026 build is not sufficient, because Redis shipped a further security release set in July. Redis Cloud is already patched, so it requires no customer action (Redis Security Advisory; Redis release notes).

Do I need to patch Redis again after the May 2026 advisory?

Yes, if you self manage Redis. Redis shipped a further security release set on July 23 2026: 6.2.23, 7.2.15, and 7.4.10 fix a Streams shared NACK use after free that may lead to remote code execution; 8.2.8, 8.4.5, and 8.6.5 fix that plus out of bounds writes reachable through crafted RESTORE payloads in RedisBloom and TDigest; and 8.8.1 fixes the RedisBloom and TDigest loaders (Redis release notes). Published authenticated RCE proofs of concept target stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0, and three of those were May remediation targets (The Hacker News). Applying the May advisory and stopping leaves you on a build with a public proof of concept.

Did an AI really find a Redis vulnerability in 27 minutes?

Researcher Chaofan Shou, of a group self described as Bera Buddies, reported on X that Moonshot AI's Kimi K3 agents found roughly 19 Redis zero days in about 90 minutes, and that one separate run produced a working exploit against Redis 8.8.0 in 27 minutes (The Hacker News). The 27 minute figure applies to that single run against that single build, not to Redis RCE discovery in general. The counts, timings, and degree of autonomy are self reported: Redis has confirmed and fixed the underlying flaws but has not validated the zero day count or how independently the agents worked. This is also a separate story from the five May 2026 CVEs, which Redis credits to named human researchers.

What is CVE-2026-25589 in RedisBloom?

CVE-2026-25589 is an invalid memory access in the RedisBloom module when a crafted serialized payload is passed to the RESTORE command, which an authenticated attacker can steer toward remote code execution. NVD classifies it as a CWE-122 heap based buffer overflow and scores it CVSS v3.1 8.8 High for all RedisBloom versions before 2.8.20 (NVD). That 8.8 is not a uniquely high score: NVD gives the same v3.1 8.8 High to CVE-2026-23479, CVE-2026-25243, and CVE-2026-25588 as well.

Which Redis version fixes these CVEs?

For Redis OSS or CE, upgrade to the July 23 2026 release on your major line: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, or 8.8.1 (Redis release notes). The May 5 2026 builds 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3 close the five CVEs but are superseded, and three of them now have published authenticated RCE proofs of concept against them, so upgrade past those builds rather than to them. For Redis Software, the May advisory named 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, and 7.2.4-153; check the Redis Software release notes for the current build on your line. Load fixed modules as well: RedisBloom v2.8.20 and RedisTimeSeries v1.12.14 on their current lines (Redis Security Advisory).

Is the Redis RESTORE command the main risk?

RESTORE is the common pivot for three of the five flaws: a crafted serialized payload passed to RESTORE reaches an invalid memory access in the core and in the RedisBloom and RedisTimeSeries modules. Restricting RESTORE to only the identities that need it, via ACL rules, is recommended as a temporary workaround alongside patching (NVD).

Are these Redis CVEs being exploited in the wild?

As of its advisory, Redis reported no evidence of exploitation of these vulnerabilities in its own or customer environments (Redis Security Advisory), and no in the wild exploitation had been reported as of July 24 2026 (The Hacker News). That supports a planned change window for patching rather than an emergency response, but the flaws should still be closed promptly given they enable code execution, and working proofs of concept are now public against several stock builds.

How do I reduce Redis RCE risk beyond patching?

Beyond upgrading core and modules, restrict RESTORE and module loading with ACLs, enforce strong authentication and protected mode, segment Redis off the public internet behind firewalls, keep replica-read-only enabled, and monitor for anomalous access, crashes, and command execution by the redis-server user (Redis Security Advisory).

Who discovered the 2026 Redis CVEs?

Redis credits named independent researchers in its advisory, including Team Xint Code for CVE-2026-23479, Emil Lerner and Joseph Surin for CVE-2026-25243, Team Skateboarding Dog for CVE-2026-25588, Daniel Firer and Joseph Surin for CVE-2026-25589, and Yoni Sherez for CVE-2026-23631 (Redis Security Advisory). These are human researchers, and the credit for every one of the five CVEs is theirs. One nuance is worth stating on CVE-2026-23479: Team Xint Code surfaced it by running Theori's autonomous code auditing tool of the same name, so that finding is AI assisted and human credited rather than a purely manual one.

Where can I get the official Redis advisory?

The primary source is the Redis security advisory published May 5 2026 (Redis Security Advisory), and the follow up fixes are documented in the Redis release notes published July 23 2026 (Redis release notes). In Canada, the Canadian Centre for Cyber Security published the mirroring advisory AV26-423 the same day as the May advisory (Canadian Centre for Cyber Security), and the NVD entries for each of the five CVEs carry independent NIST scoring (NVD).

References

1. Redis. Security advisory: CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, CVE-2026-23631. May 5 2026. https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/. Official advisory naming the five CVEs, CVSS ratings, affected and fixed versions for core and modules, remediation guidance, exploitation status, and the human researcher credits.

2. Redis. Redis release notes: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, 8.8.1. July 23 2026. https://github.com/redis/redis/releases. Official release notes for the follow up security release set, naming the Streams shared NACK use after free and the RedisBloom and TDigest out of bounds writes, with no CVE identifier assigned to either.

3. National Vulnerability Database (NIST). CVE-2026-25243 Detail. Retrieved July 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-25243. NIST assigned CVSS v3.1 8.8 High and CNA CVSS v4.0 7.7 High for the core RESTORE flaw, with CWE-122 classification. The same v3.1 8.8 High and v4.0 7.7 High pair applies to CVE-2026-23479, CVE-2026-25588, and CVE-2026-25589.

4. National Vulnerability Database (NIST). CVE-2026-25589 Detail. Retrieved July 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-25589. Independent CVSS scoring (v3.1 8.8 High, v4.0 7.7 High), CWE-122 heap based buffer overflow classification, the RedisBloom before 2.8.20 version boundary, and the ACL restriction of RESTORE as a temporary workaround.

5. National Vulnerability Database (NIST). CVE-2026-25588 Detail. Retrieved July 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-25588. CVSS v3.1 8.8 High, v4.0 7.7 High, CWE-122, and the RedisTimeSeries before 1.12.14 version boundary.

6. National Vulnerability Database (NIST). CVE-2026-23631 Detail. Retrieved July 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-23631. NIST assigned CVSS v3.1 8.1 High against the CNA v4.0 6.1 Medium carried in the Redis advisory, with CWE-416 classification, the basis for treating the Lua flaw as more than a Medium.

7. Canadian Centre for Cyber Security. Redis security advisory (AV26-423). May 5 2026. https://www.cyber.gc.ca/en/alerts-advisories/redis-security-advisory-av26-423. Canadian government mirror confirming the same five CVEs and advising administrators to apply the necessary updates.

8. The Hacker News. Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say. July 2026. https://thehackernews.com/2026/07/kimi-k3-agents-found-redis-zero-days.html. Named attribution to researcher Chaofan Shou and the self described Bera Buddies group, the scoped figures (about 19 zero days in roughly 90 minutes; one run producing a Redis 8.8.0 exploit in 27 minutes), the stock builds targeted by published proofs of concept, and the note that no in the wild exploitation had been reported as of July 24 2026.

9. CyberPress. Kimi K3 AI Agent Finds Redis RCE Vulnerabilities in Just 27 Minutes. July 23 2026. https://cyberpress.org/kimi-k3-ai-agent-finds-redis-rce-vulnerabilities/. Coverage of the separate, developing autonomous agent claim, including the 27 minute framing and the scheduled July 27 2026 open weights release date.

10. Cybersecurity News. New Kimi K3 AI Agent Uncovers 0-Day Exploits in Redis Server. July 23 2026. https://cybersecuritynews.com/redis-server-0-day-exploit/. Coverage describing the stream shared NACK and RedisBloom TDigest findings and the incomplete fix family framing applied to the Streams issue.