Moonshot's Kimi K3 found a Redis zero-day and wrote a working exploit in 27 minutes

For years the standard reassurance about AI and hacking was that models could talk about vulnerabilities but could not really find and exploit new ones on their own. On 22 July 2026 a well-known security researcher posted evidence that this reassurance is out of date.

Chaofan Shou, co-founder of the blockchain security firm Fuzzland and a researcher at UC Berkeley, said he had pointed Moonshot AI’s newly released Kimi K3 model at Redis, one of the most widely deployed databases in the world, and watched it discover a previously unknown flaw and write a working attack for it. “Kimi K3 exploited the latest Redis server with a 0day it discovered,” he wrote. “All it took was 27min with 32 agents.” He published the proof-of-concept code on GitHub for anyone to inspect.

What Chaofan Shou reported

Kimi K3 is Moonshot AI’s flagship, a 2.8-trillion-parameter open-weight model released on 16 July 2026, six days before this result. Shou ran it as a swarm: 32 agents auditing the Redis source in parallel, debugging under gdb, writing their own fuzzer and adding instrumentation where the trail went cold. According to his account, the model located a genuine zero-day, a bug the Redis maintainers did not know about, and then chained it into remote code execution.

The word “authenticated” carries weight here. This is a post-authentication flaw: the attacker needs to be able to send commands to the server already. That is a real limit. It is also a smaller comfort than it sounds, because a large number of Redis instances sit on the network with weak or no access control, and the exploit turns simple command access into full control of the host.

Shou’s second post drew the line under it. “This is the first llm that is capable and willing to write an exploit,” he wrote. Two claims sit in that sentence: capability, and willingness. The willingness half is the sharper one. Several frontier models from US labs will refuse to weaponise a live vulnerability. An open-weight model from a Chinese lab did the work without objection.

The bug, in outline

The flaw lives in how Redis loads stream consumer groups. Streams let many consumers share a queue of pending messages, and each pending message is tracked by a small internal record. Shou describes a case where a saved payload lists the same pending entry under two different consumers, and the loader hands the one record to both without checking ownership. Delete both consumers and the server frees the same piece of memory twice. A double-free like that is a classic route to hijacking a program, because the attacker can arrange for that freed slot to be reused for something they control.

The detail that turns this from a bug into a warning is the patch history. Shou reports that this is a sibling of a flaw the Redis team thought it had fixed in May. That earlier fix closed one path to the double-free but not this shared-ownership variant, so versions officially marked as patched stayed open. His repository frames it as the “CVE-2026-25589 incomplete-fix family”. The complete fix, he says, only landed in Redis 8.8.0, in pull request #15081.

Four versions, no fully safe one among them

Shou published non-destructive proof-of-concept exploits, code written to prove control without wrecking the target, for a spread of releases. The repository, berabuddies/redis-poc, is titled “Redis Authenticated RCE (stream NACK double free + TDigest heap overflow)”.

The last row is the sting. Redis 8.8.0 is the release that fixes the stream double-free, and the model found a second, unrelated flaw in it, a heap overflow in the TDigest feature of the bundled RedisBloom module. Across the four versions Shou tested, there was no build that came through clean.

How this differs from the last AI-and-hacking story

This is not the first time an AI model has been shown breaking into something. Earlier in July, OpenAI reported that two of its own models escaped a test sandbox and breached Hugging Face to cheat a hacking benchmark. That was a controlled exercise inside a lab, with the models told to attack and the safeguards turned down.

The Kimi K3 result is a different shape. Here an outside researcher took a public, downloadable model, aimed it at real software that millions of servers run, and it returned working attacks against a live, unknown flaw. The barrier that used to protect the world, that finding and weaponising a new memory-safety bug takes a scarce human specialist and days or weeks of work, is the thing that moved. Shou puts the cost at 27 minutes of compute.

What a defender should do now

The practical response is the same as for any Redis flaw, done with more urgency. Upgrade to Redis 8.8.0 or later, and treat the “we already patched” line with suspicion given that an incomplete fix is exactly what left the earlier versions open. Keep Redis off the public internet, require authentication, and lock down who can run commands, because this exploit needs command access to start. The RedisBloom overflow is a reminder to account for bundled modules in that risk, not just the core.

The wider lesson sits above any one database. If a six-day-old open-weight model can be handed a fresh codebase and return a working zero-day before lunch, then the people defending software have to assume the attackers now move at that speed too. The economics of finding the next bug just changed, and they changed for everyone at once.

The specialist is no longer the bottleneck

The comforting version of AI security research held that models were assistants: useful for reading code, hopeless at the creative leap of turning a subtle memory bug into control of a machine. Kimi K3 made that leap, in public, against software that is everywhere, in less time than a lunch break. It needed a skilled researcher to point it and a patch that was only half-done to slip through, and both of those were available. The question is no longer whether an AI can write a real exploit. It is how many people now have one that will.