AI vulnerability discovery: what changed

Redis shipped a fix on 23 July 2026 for a bug that exists only because an earlier fix, issued in May, was incomplete. An organisation that patched exactly as instructed in May was still exploitable in July. A second bug, fixed the same day, still has no CVE number at all as I write this - not a delay, a gap that has not closed.

That is the actual story behind this week's AI vulnerability discovery headline, and it holds regardless of what you make of the claim that broke it: AI agents allegedly finding 19 Redis zero-days in 90 minutes. Below is what is confirmed, what is only claimed, and what I would check in your own estate this week as part of my security consulting services.

What is AI vulnerability discovery

AI vulnerability discovery is the use of AI agents to find and weaponise flaws in existing software, rather than to defend against them. It is not new in principle. Google's Big Sleep and DARPA's AI Cyber Challenge have both produced real, independently confirmed finds over the past year, but the claim behind this story is a step beyond either: a research group called Bera Buddies says its Kimi K3 agents found 19 Redis zero-days in about 90 minutes, with one working exploit built in 27 minutes.

Treat that claim as unverified from the outset. It comes from one person's account of their own research, and neither Redis nor NVD has confirmed the count or the speed. What follows does not depend on it being true.

What happened to Redis in July 2026

Redis's own release notes describe two distinct bugs, and they do not share the same version range. The first: "a crafted stream RESTORE payload can make two consumers share the same NACK, leading to a use-after-free that may result in Remote Code Execution", fixed in six of the seven releases - 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5 and 8.6.5. The second: "crafted RESTORE payloads in RedisBloom and TDigest may trigger out-of-bounds writes, potentially leading to remote code execution", fixed in 8.2.8, 8.4.5, 8.6.5 and 8.8.1. None of the seven release notes carries a CVE number.

The claim, and what Redis actually confirmed

The affected versions with published proof-of-concept exploits were Redis 6.2.22, 7.4.9, 8.6.4 and 8.8.0, and the same PoC repository claims a separate exploit against 8.8.1 too, detailed further below. Redis's public record confirms the underlying flaws and the seven patches. It does not confirm the 19-bug count, the 90-minute figure, or how independently the agents actually worked.

The most common objection to the story, and a fair one, is that this is "just" an authenticated remote code execution bug. On Hacker News, one commenter put it bluntly: "It's an authenticated RCE in redis, anyone even vaguely familiar with the codebase knows to not expect there to be any real security boundary in place here." That is a reasonable instinct, but it understates two things. First, RESTORE sits in Redis's own @write and @dangerous ACL categories, not @admin - it is a normal command available to any client with ordinary write access, which is exactly why Redis's own mitigation is to revoke it from accounts that do not need it, not to assume it is already locked away. Second, as another commenter countered, "we're in an era where creds can be bought in online markets, and redis open source has no default requirement for password complexity." Authenticated does not mean hard to reach.

Why the identifier lagged the fix - the actual story

Here is the detail most coverage has missed, because it requires reading the NVD record rather than the press summary of it.

CVE-2026-66373's own description ends with a note: "this issue exists because of an incomplete fix for CVE-2026-25243." CVE-2026-25243 was Redis's May 2026 fix for a different RESTORE-related bug. The July flaw is not a new discovery in the purest sense, it is a gap the May patch left open. An organisation that patched to 6.2.22 or 7.4.9 in May, exactly as instructed, was still exploitable in July through a related path in the same command.

I checked this myself against the GitHub Security Advisories API on 27 July 2026. redis/redis's most recent advisories are all dated 5 May 2026. There is no GitHub Security Advisory for either July flaw. The second bug, the RedisBloom and TDigest one, has no CVE at all as of publication, in either the NVD or GitHub Security Advisories databases.

Here is the honest complication I would not skip: CVE-2026-66373 is not, by the usual measures, an emergency. It scores CVSS 3.1 7.5, with high attack complexity and low privileges required. Its EPSS score, the industry's own model for real-world exploitation probability, sits at 0.47 percent, in the 38th percentile, and it is not listed in the CISA Known Exploited Vulnerabilities catalogue. If you triaged purely on those numbers, you would rank it well below your urgent list, and for that one bug, you would not be wrong to.

Why this matters even though the score says otherwise

Attack complexity measures the cost of building an exploit, not the cost of using one someone else already built. The PoC repository behind this story has 450 stars on GitHub, was created the night before the patch, and its own description claims RCE against Redis 8.8.1 - the very version Redis shipped the next day specifically as the fix - through a separate exploit path from the RedisBloom and TDigest bug discussed below. I have not run that exploit myself and I am reporting the claim, not confirming it. But it is the same repository NVD cites directly in its own record.

The sharper point is the second bug, the RedisBloom and TDigest one. It has no CVE number at all, which means it cannot have a CVSS score, cannot have an EPSS probability, and cannot appear in CISA's Known Exploited Vulnerabilities catalogue, because all three systems key off an identifier that was never issued. That is not a scoring system rating a risk as low. It is a fixed, shipped, remote-code-execution-capable bug that every CVSS-, EPSS- and KEV-driven triage process is structurally unable to see at all.

If you do not run Redis yourself, this can still reach you. Redis is one of the most widely deployed in-memory data stores, commonly sitting behind other products as a cache, a session store or a queue. You may never touch it directly and still depend on a supplier who does. The ICT supplier risk management question worth asking this month is simple: does any part of your supply chain run Redis, and how quickly do they apply security fixes relative to when the vendor ships them, not relative to when a CVE appears.

What to do about it this week

If you run Redis yourself:

1. Revoke RESTORE from any account that does not need it, and block untrusted network access to Redis instances. This closes both disclosed paths and needs no patch or CVE to exist first.
2. Upgrade regardless of whether your exact version had a public exploit, and check which fix you actually needed. Published proof-of-concept exploits targeted 6.2.22, 7.4.9, 8.6.4 and 8.8.0. Redis's own release notes show the shared-NACK fix went into six of the seven branches - 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5 and 8.6.5 - while 8.8.1 needed only the separate RedisBloom/TDigest fix, because NVD's own record scopes the shared-NACK bug to versions before 8.8.0: that branch was never vulnerable to it in the first place. The two bugs do not track the same version ranges, and treating "we're on 8.8.1" as proof you got both fixes would be a mistake.

Whether or not you run Redis, the part that generalises: an incomplete May patch and a July fix with no identifier at all both slipped straight past a vulnerability management process built around CVE feeds. That process needs a second input that does not wait on an identifier.

1. Watch vendor release notes and security channels directly for the handful of components your business actually depends on, rather than waiting for an entry to appear in NVD, which the record above shows can lag the fix by days, or never appear at all.
2. Ask your suppliers three direct questions: do you run Redis, or anything else with a comparable disclosure history, anywhere in this product; do you patch security fixes ahead of CVE assignment or only after one appears; and do you restrict dangerous commands like RESTORE by default, or only after a named incident.
3. Set the tighter of the two published UK timescales, not the looser one. Cyber Essentials requires critical and high-severity updates within 14 days of release, full stop. NCSC's own guidance goes further for anything internet-facing and recommends five days, not 14. Treat the Cyber Essentials number as the compliance floor, not the target.

What not to do

Do not treat the 19-zero-days figure as fact, and do not use it to justify emergency action on unrelated systems that were never part of this disclosure. Do not assume "not in CISA KEV" means safe to ignore indefinitely, KEV lists confirmed exploitation, not absence of risk. And do not conflate NCSC's five-day recommendation with Cyber Essentials' 14-day requirement, they are a stricter recommendation and a compliance floor, not the same number said two ways.

If you want an independent check on whether your estate, or your suppliers', has a gap like this one - patched but unidentified, or identified but unscored - book a free consultation and I will help you find it before an unverified headline does. Whether the AI-discovery claim behind this story turns out to be accurate changes nothing about the fix, the missing identifier or the gap between them; it only explains why this made the news instead of sitting in a routine advisory feed.

I offer estate and supplier checks like this as part of my IT management services for UK businesses, alongside the IT risk management work that catches identifier-lag gaps like this one before they become someone else's blog post. It is the same pattern I wrote about in the OpenAI sandbox escape: a capable system, a real gap, and a process that was not built to catch it.