Redis Got Patched Twice in 79 Days: The Real AI Discovery Story vs. the One Trending on X

On May 5, 2026, Redis shipped fixes for five authenticated RCE vulnerabilities and called it done. Seventy-nine days later, on July 23, it shipped seven more releases — because researchers had just published working exploits against the versions the May advisory said were safe. That's the real headline: Redis's own "fixed" release wasn't.

The AI-discovery story attached to this is real, but it's not the one that went viral. A validated, credited, CVE-tied AI discovery is sitting quietly inside the official May advisory. The story getting shared everywhere — an AI agent finding 19 zero-days in 90 minutes — is a separate, unverified claim with no CVE and no confirmation from Redis. Both threads matter for anyone bundling Redis into a platform, but they matter for different reasons, and conflating them gets the actual lesson wrong.

The Actual Timeline, Precisely​

Here's what happened, in order, cross-checked against Redis's own security advisory rather than secondhand summaries:

The gap that looks like an error but isn't: the May advisory's fixed list tops out at 8.6.3, while the July PoCs targeted 8.6.4 and 8.8.0 — versions that didn't exist yet in May. Redis's ordinary release train kept moving between the two security advisories, and those new minor versions inherited the same incompletely-patched code. So the vulnerable surface didn't just sit still for 79 days waiting to be re-patched — it actually grew, picking up two more minor releases before July's fix caught up to all of them.

Three of the five May CVEs share a common thread worth naming, because it explains why a second round was even plausible: the RESTORE command deserializes an attacker-supplied, serialized RDB payload back into a live Redis object, and three of the five bugs (the core RESTORE flaw, plus its RedisTimeSeries and RedisBloom module variants) are all invalid-memory-access issues in that same deserialization path. That's not one bug patched three times — it's the same class of parsing mistake recurring across the core command and two of its most widely deployed modules, which is exactly the kind of bug family where a fix that closes one code path can leave a sibling path open. The July Streams and TDigest issues extend that same family rather than introducing an unrelated one.

The discovery venue matters too. Wiz's ZeroDay.Cloud is a live, cash-prize hacking contest specifically targeting widely deployed open-source infrastructure — the kind of event that produces exactly this pattern: multiple independent teams (human, AI-assisted, or both) converging on the same software in the same short window. All five May CVEs were found at the December 2025 running of that contest, disclosed within 48 hours of each other, which is why they landed in Redis's advisory as one coordinated batch rather than trickling in individually over months.

What "AI Found It" Actually Means Here​

Two AI-discovery claims sit inside this timeline, and they are not the same kind of claim.

The real one: Theori's Xint Code tool found CVE-2026-23479 — a use-after-free in Redis's blocked-client handling that had shipped unnoticed since Redis 7.2.0, over two years earlier. Team Xint Code demonstrated a working exploit at the December 2025 ZeroDay.Cloud contest, reported it through Redis's normal disclosure process, and is credited by name in the official May 5 advisory alongside the CVE number, the CVSS score (7.7, High), and the exact fixed version. Every part of that claim is checkable against a primary source.

The unverified one: researcher Chaofan Shou, describing work by a group calling itself "Bera Buddies," reported that Moonshot AI's Kimi K3 agents autonomously found roughly 19 Redis zero-days in about 90 minutes, and built a working exploit against Redis 8.8.0 in 27 minutes. No CVE number exists for this claim. Redis has not confirmed it. The bug count, the timing, and the autonomy of the process are all self-reported by the same party making the claim, with no independent verification as of this writing.

That gives a usable heuristic for the next headline like this one: does the claim have a CVE number and a vendor advisory attached, or does it have a tweet and a round number? The first is checkable infrastructure risk. The second is a marketing claim about an AI product that happens to be plausible — Xint Code proves the underlying capability is real — but plausible isn't the same as verified, and a patch-cadence decision built on an unverified claim is a decision built on nothing.

The 79-Day Exposure Window​

Here's the number that should change behavior more than either AI story: a team that upgraded to Redis 6.2.22, 7.4.9, or 8.6.3 in May, confirmed the CVEs were patched, and stopped watching, was running a version with a publicly demonstrated working exploit for 79 days before Redis's actual fix shipped on July 23.

That's not a hypothetical gap — it's the literal distance between "the CVE database says fixed" and "the bug class is actually closed." The May advisory wasn't wrong when it was published; the Streams and RedisBloom/TDigest fixes just didn't cover every code path the underlying flaw touched, and it took a second round of published proofs-of-concept to surface that. Nothing about that process was unusual or negligent on Redis's part — incomplete first patches for subtle memory-safety bugs are a known pattern across the industry, not a Redis-specific failure. But "known pattern" is exactly why a platform that bundles Redis can't treat a CVE fix as a closed ticket.

What This Means for a Self-Hosted PaaS's Own Patch Cadence​

If Redis ships as a tenant add-on — the common case for any PaaS offering a managed cache or session store — the practical lesson isn't "AI found bugs, patch faster." It's narrower and more durable than that:

• Track the security-announce feed directly, not just CVE databases. The July 23 releases were published before a CVE number existed for the underlying issue in most public trackers; a platform watching only CVE feeds would have been late to notice the second fix shipped at all.
• Treat a version bump as provisional, not closed. The May advisory looked complete — CVE numbers, CVSS scores, a fixed-version table, researcher credits, all present. It still needed a follow-up two and a half months later. A patch tracker that marks a dependency "resolved" the moment a CVE gets a fixed version, and never revisits it, would have missed the July release entirely.
• Automate the diff-and-redeploy step for bundled dependencies. Not because Kimi K3's claim is confirmed — it isn't — but because the incomplete-fix pattern is confirmed, and it happened via the boring, well-documented path (human researchers, an official advisory, a second official advisory), not the sensational one. A weekly human changelog check catches the first advisory fine; it's the quiet follow-up release, two months later, addressing a bug class everyone already assumed was closed, that a human process is most likely to miss.

Concretely, that's a small piece of infrastructure, not a research project: a scheduled job that pulls Redis's GitHub security advisories feed alongside the CVE feed, diffs the pinned image tag a platform ships to tenants against the latest release on each tracked minor branch, and opens a ticket (or, further along, cuts the rebuild and rollout itself) the moment a new patch lands on a branch already in production — regardless of whether that patch carries a fresh CVE number yet. The July 23 releases would have tripped that check the same day they shipped, independent of any CVE assignment lag.

None of this requires believing an AI agent found 19 zero-days in 90 minutes. It requires believing that a dependency a platform bundles for every tenant needs continuous tracking, not episodic patching — which the verified part of this story already proves on its own.

A self-hosted PaaS that bundles Redis as a tenant add-on inherits this exact tracking problem — Bex.co is the open-source, AI-native Render alternative built to treat infrastructure state as something an operator (human or agent) can query and act on continuously, not a changelog someone has to remember to check. Star the repo on GitHub or deploy your first app today.

Sources​

• Redis security advisory: CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, CVE-2026-23631
• Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479) — The Hacker News
• Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say — The Hacker News
• Redis RCE 2026: Five Patched CVEs and an AI Discovery
• Critical Redis Patches Fix RCE and Memory Corruption Flaws
• CVE-2026-23479, the Redis UAF Behind an Authenticated RCE Path
• Five Redis Vulnerabilities Found in 48 Hours — ZeroDay.cloud