Open Model Offensive Cyber: Inside the Kimi K3 powered Redis Vulnerability

Redis, a widely used open-source database system, became the subject of another AI-led security test this week.

Security researcher Chaofan Shou reported that Kimi K3, the latest general-purpose model from Chinese AI lab Moonshot AI, used 32 parallel agents to discover and weaponize multiple Redis vulnerabilities in less than 2 hours. Shou then published PoC exploits targeting Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0, its latest release.

These results, published by Chaofan, have not yet been independently reproduced, so the timeline of events should be treated as reported until then. Even so, it's still an episode worth discussing for some key reasons:

• It's the first instance of a non-frontier (and soon to be open-weight) model finding 0days in current critical software
• It reveals the power (and danger) of an agentic LLM without sufficient guardrails

Let’s unpack what happened.

The Setup: Kimi K3 and Agent Swarm

Chinese AI lab Moonshot AI released Kimi K3 on July 16, presenting it as a 2.8 trillion-parameter model designed for long-horizon coding and reasoning.

K3 also powers Kimi’s Agent Swarm infra, which divides complex tasks among parallel subagents and coordinates their results.

K3 had a massive launch because its launch benchmarks and early leaderboard results placed it alongside Anthropic’s Fable 5 and OpenAI’s GPT-5.6 Sol. It also debuted at number one on Arena’s Frontend Code leaderboard, ahead of both models (although Arena classified its initial score as preliminary).

The K3 model attracted significant attention for its comparatively relaxed stance on guardrails, particularly in biotechnology and cybersecurity use cases. This made it well-suited and an ideal model for Shou’s “research.” Equipped with the model, he was able to proceed with the vulnerability and exploit development, just by stating that he was conducting an “authorized security test.”

A look at the vulnerabilities

The vulnerabilities discovered by Shou can be split in two groups.

• The first targets Redis versions 6.2.22, 7.4.9 and 8.6.4.
  One clarifying point: they require access to Redis and permission to load crafted data through powerful commands such as RESTORE. Most importantly, they are not drive-by exploits that can compromise any Redis server simply because it is reachable.
  The vulnerability exploited by Shou and Kimi was related to, but distinct from, CVE-2026-25243, a previously discovered Redis flaw that was considered fixed. Redis 8.6.4 was specifically expected to include a safeguard against this issue, and its release notes indicated that the relevant fix had been included. Public records do not establish whether K3 found the vulnerability by noticing a mismatch between the release notes and the shipped code, or whether it discovered it independently.
• The published exploit targeting Redis 8.8.0 is different. Since the first vulnerability was patched, a 2nd exploit has been found that feeds manipulated data into RedisBloom, a data-analysis component bundled with Redis. This program was designed to make Redis write beyond its allocated memory and exploit the resulting corruption to execute commands. It was tailored to a fresh Redis 8.8.0 server with a predictable memory layout.

Redis had already patched a related issue in May, but Shou’s exploit reportedly used a variant that was not fully addressed by that fix.

Taking a Step Back

These developments tell us a few things:

Chinese models have become increasingly capable at analyzing software and finding vulnerabilities

While unconfirmed for this specific instance, research on past patched vulnerabilities is helpful in identifying similar exploit pathways

Regardless of the details of the vulnerability Kimi K3 discovered in this instance, the pattern is becoming harder to ignore. Read the details of this development alongside the recently disclosed OpenAI and Hugging Face incident, and they both show that LLM agents are beginning to perform sustained security work at a speed and volume that many existing processes were not designed to absorb.

Conclusion

For organizations, a faster security environment has a clear implication.

When a vulnerability is surfaced, an organization needs to determine almost immediately whether the affected software is in use, which systems and workflows depend on it, what data and permissions are exposed, and who owns the response.

AI can accelerate detection and remediation, but ultimately, it’s up to the organization to act. In a machine-speed security environment, operational visibility and control become defensive capabilities in their own right.