thehackernews.com web signal

Kimi K3 agents reportedly find 19 Redis zero-days, RCE in 27 min

7 sources tracking this story

TL;DR

  • Redis released seven security patches on July 23 confirming the discovered flaws, independent of any claim about how they were found.
  • The 19-zero-day count and 27-minute timeline are self-reported by the research team; Redis has not confirmed the figures and no independent reproduction has been published.
  • A UK AISI and US CAISI joint study published the same day found Kimi K3 scored 32.2% on ExploitBench versus 76.2% for unnamed US frontier models, and achieved zero arbitrary code executions across 41 tested vulnerabilities.

A researcher named Chaofan Shou says a swarm of Kimi K3 agents surfaced 19 Redis zero-days in roughly 90 minutes and produced a working remote code execution exploit against Redis 8.8.0 in another 27, The Hacker News reported. The specific numbers are self-reported through Shou and the Bera Buddies group, which describes itself as "AI Agent Research," and while Redis has confirmed the underlying memory flaws it has not validated the zero-day count or the degree of agent autonomy.

What is not in dispute is the patch load. Redis shipped seven security releases on July 23 covering builds 6.2.22, 7.4.9, 8.6.4, and 8.8.0, with fixes rolling into 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, and 8.8.1. The two disclosed exploit paths are a Streams shared-NACK double-free, in which a corrupt RDB object causes two consumers to reference the same pending-entry record, and an out-of-bounds write in the RedisBloom TDigest RDB loader that trusts an attacker-controlled capacity field. Both require an attacker to be able to run the RESTORE command, which is why the mitigation guidance is upgrade, revoke RESTORE from accounts that do not need it, and keep the port off untrusted networks.

If the autonomy claim holds up even partly, the interesting part is the shape of the workflow, not the tally. Finding memory-corruption bugs in a battle-tested C codebase inside 90 minutes and chaining one into an RCE inside 27 more is a loop that used to belong to well-funded offensive research teams. Cheap open-weight models running that loop against every popular open source dependency is a different threat model for maintainers and a different economics for defenders who now need to assume the same tooling is being pointed at their own code.

The honest caveat is that this is one researcher's write-up, amplified on X, and Redis has not confirmed either the count or how much of the work the agents actually did on their own. What the reporting does not give you is independent reproduction, a CVE-by-CVE severity breakdown, or evidence of exploitation in the wild. As of July 24 there was none. The upside sits with the defenders willing to point the same class of agent at their own dependency tree before someone less friendly does.

What others are reporting

Coverage cluster as of 2h after publish

  1. Runs a dedicated section on the limits of the speed claim: figures are self-reported, Redis has not verified them, and these findings are distinct from five separate May-patched CVEs.

    A security team using Moonshot AI's Kimi K3 said one of its agents found a Redis flaw and built a working remote code execution exploit in just 27 minutes.
  2. South China Morning Post Read →

    Government evaluation published within 24 hours of the Redis claim: Kimi K3 failed arbitrary code execution on all 41 tested vulnerabilities and scored 32% on ExploitBench versus 76% for US frontier models.

    Kimi K3 achieved an overall score of 32.2 per cent, outperforming domestic rival Zhipu AI's GLM-5.2 at 24.4 per cent, but lagging well behind top, unnamed US models that averaged 76.2 per cent.
  3. Cyber Security News Read →

    Maps each CVE to specific Redis versions and explains why upgrading to 8.8.0 closes the stream NACK path but leaves the RedisBloom TDigest chain open to authenticated attackers.

    Authenticated RCE via incomplete fixes and bundled modules means 'we set a password' is not a complete security strategy.
  4. heise online Read →

    Adds that Moonshot halted new subscriptions due to GPU demand after the demo went viral; frames the result as evidence Chinese AI now competes with US frontier labs on vulnerability detection.

    The developers of the open-source in-memory database redis have released updated versions that close several vulnerabilities within it.
  5. IBTimes UK Read →

    Most skeptical framing in the coverage: Redis maintainers have not acknowledged the flaws, Moonshot has not commented, and it is unclear whether the reported bugs are truly new or variants of prior disclosures.

    Because the reported vulnerabilities have not yet been independently reproduced or acknowledged by Redis, it remains unclear whether they represent entirely new flaws.
  6. GBHackers Read →

    Emphasizes the autonomous end-to-end workflow: a single natural-language prompt triggered code clone, fuzz, GDB debug, and non-destructive PoC with no human steering at any step.

    The AI agent, prompted with a simple instruction to locate memory corruption issues, completed a full vulnerability discovery workflow in as little as 27 minutes.