32 Agents Found a Redis Zero-Day in 27 Minutes. On July 27, the Model That Did It Becomes a 1.4TB Download.
TL;DR
On July 23, Redis shipped seven patch releases in one go (6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 and 8.8.1) closing two remote-code-execution paths that both run through the RESTORE command. Hours earlier, security researcher Chaofan Shou posted that he had aimed Kimi K3, Moonshot AI's 2.8-trillion-parameter model, at Redis with 32 parallel agents and had a working RCE proof of concept in 27 minutes, then 19 reported zero-days in roughly 90. The bugs are post-authentication and, by the standards of the people who do this for a living, dull. Hacker News said so at volume. The number worth staring at is not 19. It is 27, and the fact that on July 27 the thing that produced it stops being an API and starts being a file.
What Redis actually shipped
Start with the part that is not in dispute, because it came from the maintainers. Redis cut seven releases on July 23, with 8.8.1 tagged at 19:30 UTC. Two security fixes span the set.
The first, listed in the 8.6.5 notes, is a stream bug: a crafted RESTORE payload can make two consumers in a consumer group share the same NACK, producing a use-after-free that may lead to remote code execution. The second is in the bundled RedisBloom module, where crafted RESTORE payloads in RedisBloom and TDigest can trigger out-of-bounds writes with the same potential outcome.
Notably absent from those release notes: any CVE identifier, and any credit to a researcher. Redis normally names its finders. In May it named eight of them.
What a RESTORE bug is, concretely
RESTORE takes a serialized blob that Redis previously produced with DUMP and rebuilds the live object from it. It is a deserializer, which is to say it is a parser that trusts its input to describe a valid data structure, and a parser that trusts its input is where memory-safety bugs go to breed.
The stream NACK flavor is the coat-check failure mode: two customers walk away holding a ticket for the same peg. The first one collects the coat and the attendant tears up the record. The second one hands over the same ticket, and the attendant, having no memory that the peg was already emptied and reused, goes and fetches whatever is hanging there now. If you are the person who chose what got hung on that peg in between, you decide what comes back.
What was claimed, and by whom
Everything past this point is Shou's account, published on X and backed by code rather than by a maintainer's confirmation. He describes a run in which Kimi K3 coordinated 32 specialized agents that cloned the Redis source, generated fuzzers, instrumented the build, triaged the resulting crashes under gdb, and emerged with an authenticated RCE proof of concept against the newest server. Twenty-seven minutes, wall clock. A later run, he says, used up to 64 agents and surfaced 19 zero-days in the latest Redis 8.8.0 in about an hour and a half.
The receipts are in a public repository, berabuddies/redis-poc, marked for authorized testing only. It carries five exploit scripts against five targets: 6.2.22, 7.4.9, 8.6.4, 8.8.0 via a TDigest heap overflow, and 8.8.0 plus 8.8.1 via a TopK wild free. That is more than a screenshot and less than a maintainer confirmation, which is exactly the awkward middle this story sits in.
The patch-bypass part is the uncomfortable part
Look again at those target versions. 6.2.22 and 7.4.9 are not old builds. They are the fixed builds from Redis's May 5 advisory, the ones you were told to upgrade to. The repository's README describes the stream NACK double-free as a patch bypass of CVE-2026-25243, and the TopK wild free as a patch bypass of CVE-2026-25589, arguing the earlier fix was incomplete because the destructor still walks past an undersized heap allocation.
It also lists 8.8.1, the release Redis cut on July 23, as still affected by the TopK issue. Redis's notes do not address that, and no independent party has confirmed it. Treat it as an open claim, not a fact, and patch anyway.
Why the security crowd shrugged, and where they are right
The Hacker News thread did not reach for pitchforks. It reached for coffee. The consensus among the people who actually read the PoCs: this is authenticated RCE, Redis should never be exposed to the internet, and anyone vaguely familiar with the codebase knows there is no meaningful security boundary on the far side of the password. One commenter called it a deeply uninteresting example.
They are right on severity, and Redis says so itself. Its May advisory states plainly that exploitation requires authenticated access, making all five a post-authentication issue. If your Redis is bound to localhost, behind an ACL, with protected-mode on, none of this is your Tuesday.
But "the bug is boring" and "the result is boring" are different claims, and the thread mostly argues the first. Post-auth RCE is a real escalation step the moment credentials leak, an SSRF lands, or a network policy is looser than the diagram says. And the interesting variable here was never the bug class. It was the meter running next to it.
The clock is the story
Compare the two disclosure events. On May 5, Redis credited eight named humans across four teams, with several of the findings coming out of Wiz ZeroDay.Cloud, a live hacking competition, which is to say a purpose-built event with prize money attached. That is what serious vulnerability research in a widely deployed C codebase has cost for as long as anyone has been doing it.
On July 23, one researcher claims the same class of finding, against the patched builds, for 27 minutes of agent time. Even discount the number hard. Even assume heavy human steering, cherry-picked runs, and a generous definition of zero-day. The order of magnitude does not survive contact with the old cost model.
And note which model did it. Not a frontier lab's restricted cyber tier, gated behind government access and a safety review. A Chinese open-weights release that today answers API calls and on July 27 publishes 2.8 trillion parameters, roughly 1.4TB in four-bit MXFP4, for anyone with the disks. As of July 21 the UK's AI Security Institute put open-weight models four to seven months behind the cyber frontier. That gap is a moving target, and it is being measured against the wrong thing: not whether an open model can match a frontier lab's best exploit engineer, but whether 32 cheap copies of a merely good one, running unsupervised over a weekend, can out-grind a maintainer's patch cadence.
What to do right now
- Patch. Upgrade to 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 or 8.8.1, matching your line. Public PoC code exists for several older builds, including ones you may have believed were already fixed.
- Assume post-auth is reachable. The comfort of "it needs credentials" is doing a lot of load-bearing work in a world of leaked env files and SSRF. Segment the network, keep
protected-modeon, and give each client the minimum ACL it needs. - Watch your module surface. Both July fixes touch bundled modules. RedisBloom and TDigest ship enabled in the 8.8 line, which means you inherit their deserializers whether or not you use them.
- Stop treating "found by AI" as the headline. The maintainer-side question is whether your patch review process assumes an attacker who gets one shot at a diff, or one who gets 64.
Key Takeaways
- Redis shipped seven patch releases on July 23, 2026 fixing two RCE paths that both run through
RESTORE: a stream consumer-group use-after-free and an out-of-bounds write in the bundled RedisBloom and TDigest modules. - Researcher Chaofan Shou says Kimi K3 with 32 agents produced a working authenticated RCE against the newest Redis in 27 minutes, and 19 zero-days in about 90 minutes with up to 64 agents. Those counts and timings are self-reported and unconfirmed by Redis or Moonshot.
- The public PoC repository targets 6.2.22, 7.4.9, 8.6.4, 8.8.0 and 8.8.1, and describes two of the exploits as bypasses of the CVE-2026-25243 and CVE-2026-25589 patches from May.
- Practitioners are right that these are post-authentication bugs in a service that was never meant to face the internet. That is an argument about severity, not about the collapsing cost of finding them.
- Redis's May advisory credited eight named human researchers, several via a live hacking competition. The July fixes name no CVE and credit no one.
- Kimi K3's full weights are scheduled to publish on July 27, 2026, roughly 1.4TB in MXFP4. Until then the capability sits behind an API that can, in principle, refuse.
Sources: Redis 8.8.1 release notes, Redis 8.6.5 release notes, Redis security advisory, May 5 2026, berabuddies/redis-poc, Chaofan Shou on X, The Hacker News, heise online, Hacker News discussion, Moonshot AI, Kimi K3