Kimi K3: AI Agents Claim Working Redis RCE Exploits

Key Takeaways

A group identifying itself as “Bera Buddies” reported that autonomous agents built on Moonshot AI’s newly released Kimi K3 model found 19 candidate Redis vulnerabilities in roughly 90 minutes and produced a working remote-code-execution exploit for Redis 8.8.0 in 27 minutes, publishing proof-of-concept code on GitHub [1][2][3]. The disclosed findings combine two distinct bug classes: a shared-NACK double-free in Redis Streams consumer groups affecting versions 6.2.22, 7.4.9, and 8.6.4, and a previously unreported heap out-of-bounds write in the RedisBloom TDigest RDB loader affecting Redis 8.8.0 [2][3]. The Streams issue appears to be an incomplete-fix variant of CVE-2026-25589, one of five CVEs (CVSS up to 7.7) that Redis had already patched on May 5, 2026 following disclosures from human researchers at Wiz’s ZeroDay.Cloud 2025 competition, which would suggest the AI agents’ most substantiated contribution is finding a gap in an existing patch rather than an entirely novel class of flaw [4][5]. Redis shipped seven new security releases on July 23, 2026, including version 8.8.1, to close the TDigest loader gap; as of July 24, 2026, neither Redis’s release notes nor the National Vulnerability Database carried a distinct CVE or CVSS score for the newly disclosed issues, and no in-the-wild exploitation had been reported [2]. The claimed discovery speed and degree of autonomy are self-reported by Bera Buddies and have not been independently verified by Redis or Moonshot AI, and they sit in tension with a joint UK AI Security Institute (AISI) and U.S. Center for AI Standards and Innovation (CAISI) preliminary evaluation, published the same month, that found Kimi K3 scored 0 of 41 on autonomous arbitrary-code-execution benchmark tasks [6]. Both exploit paths require prior authentication and reliance on commands — EVAL, RESTORE, and XGROUP — that security teams often leave enabled by default in internal deployments, reinforcing that credential hygiene and command restriction, not just patching, remain central defenses [2][3].

Background

Moonshot AI, the Beijing-based developer of the Kimi model family, released Kimi K3 on July 16, 2026, describing it as the first openly weighted model in the “3-trillion-parameter class,” with roughly 2.8 trillion total parameters, a one-million-token context window, and a design emphasis on long-horizon coding and agentic workflows [7][8]. Independent benchmarking placed K3 behind the leading proprietary systems from Anthropic and OpenAI on general capability, but ahead of other openly available Chinese models, and Moonshot committed to publishing full model weights under a modified MIT license within about two weeks of the API launch [7][9]. The release drew immediate attention from the security research community, in part, plausibly, because Kimi K3’s low API cost and long context window make it an attractive base for wrapping in autonomous, tool-using agent scaffolding rather than for direct conversational use.

Within roughly a week of that release, independent researcher Chaofan Shou reported using Kimi K3-based agents to analyze the Redis source tree, and a group publishing under the name “Bera Buddies” — describing itself simply as “AI Agent Research” — released a GitHub repository of proof-of-concept exploits alongside claims that its agents had autonomously cloned the Redis codebase, fuzzed target functions, debugged crashes with a symbolic debugger, and surfaced 19 candidate zero-day findings in about 90 minutes of agent time, then built a full remote-code-execution chain for Redis 8.8.0 in a further 27 minutes [1][2][10]. These claims were picked up by The Hacker News and several other security outlets in the week of July 20, 2026, generally noting that the timing, count, and autonomy level were self-reported and had not been independently reproduced [1][2].

The Redis codebase the agents examined was not, in fact, previously unexamined. On May 5, 2026, Redis published a security advisory disclosing five vulnerabilities — CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, and CVE-2026-23631 — with CVSS scores as high as 7.7, all reported by named independent researchers (including Emil Lerner, Joseph Surin, and members of Team Skateboarding Dog and Team Xint Code) through Redis’s coordinated disclosure process and the Wiz-hosted ZeroDay.Cloud 2025 competition held in December 2025 [4][5][11]. Redis shipped fixed builds across the 6.2.x through 8.6.x lines and patched the affected RedisBloom and RedisTimeSeries modules at that time [4]. The July claims from Bera Buddies concern what happened after that patch cycle: whether the Streams fix fully closed the shared-NACK double-free path, and whether the newer 8.8.0 release, built on the same RedisBloom TDigest module, introduced a fresh, unpatched memory-safety defect.

Security Analysis

Two bug classes, one shared precondition

The Streams vulnerability centers on a shared-ownership error in how Redis consumer groups track pending messages. When a corrupted or maliciously crafted RDB object causes two separate consumers to reference the same pending-entry record — the internal structure Redis calls a NACK — issuing XGROUP DELCONSUMER against both consumers frees that shared record twice, producing a heap double-free that a skilled attacker can convert into a reliable code-execution primitive [2][3]. This is functionally the same defect class Redis addressed in the May advisory’s stream-related fix under CVE-2026-25243 and CVE-2026-25589, but the July proof-of-concept reportedly still functions against 6.2.22, 7.4.9, and 8.6.4 — versions that already carry the May patches for the originally reported bugs [2][3]. If confirmed, that would mean the May fix closed the specific exploitation path the original researchers demonstrated without closing every path through the same shared-NACK logic, an outcome that security researchers frequently observe in memory-safety remediation and one of the reasons security teams should treat “patched” as a probabilistic rather than absolute claim for complex native-code data structures.

The second bug is more clearly novel. Redis 8.8.0’s bundled RedisBloom module includes a probabilistic data structure called TDigest, used for approximate percentile calculations. Its RDB loader allocates a centroid array sized according to a serialized “compression” value taken from the payload, but then separately trusts an attacker-controlled “capacity” field when deciding how many centroid nodes to read into that array. Because the two values are not cross-checked, an attacker can supply a small compression value — yielding a small real allocation — paired with an inflated capacity field, producing an out-of-bounds write when the loader reads more nodes than the buffer can hold [2][3]. This pattern, a mismatch between an allocation-sizing field and a separately trusted length or count field during deserialization, echoes the root cause of the earlier CVE-2026-25589 RedisBloom finding, raising the question of whether the module’s RDB deserialization code as a whole would benefit from a more systematic audit rather than point fixes to individual reported cases [3][4].

Both paths share a critical precondition: they require an attacker who already holds authenticated access to the Redis instance and the ability to issue RESTORE, and in the Streams case, XGROUP and consumer-management commands. Redis’s own May advisory was explicit that all five originally disclosed vulnerabilities were “post-authentication” issues, and that characterization holds for the July findings as well [2][4]. Redis deployments that require authentication, restrict command access through ACLs or rename-command, and are not exposed to untrusted networks retain a meaningful barrier against both exploit chains, even before any patch is applied.

What the autonomy claims add — and what they do not yet establish

The most significant open question is not whether the underlying bugs are real — Redis’s own July 23 patch release for RedisBloom and TDigest loaders is reasonably strong corroboration that at least the TDigest issue was genuine — but whether the claimed level of AI autonomy in finding and weaponizing it is accurately represented [2]. Bera Buddies’ public repository documents technical details, including patch-bypass notes and per-version exploitation reliability (the repository notes, for example, 5-of-5 successful runs against fresh 8.8.0 containers), but it does not itself substantiate the claimed 90-minute discovery window, the 19-finding count, or the specific degree to which a human operator directed or corrected the agent’s work at each step [3]. Autonomous-discovery narratives in this space have historically been difficult to audit, since public write-ups rarely disclose the full scaffolding, retries, or prompt engineering behind a result, and no independent party — not Redis, not Moonshot AI, and not a third-party lab — has reproduced the claimed timeline as of this writing.

That gap matters because it sits directly alongside a more rigorous, independently conducted assessment published the same month. The UK AI Security Institute and the U.S. Center for AI Standards and Innovation jointly ran a preliminary evaluation of Kimi K3’s offensive cyber capabilities using ExploitBench and a separate cyber-range scenario called “The Last Ones.” Kimi K3 achieved a 32 percent success rate on ExploitBench — ahead of the open-weight model GLM-5.2 at 24 percent, but well behind frontier U.S. systems — and, notably, scored 0 of 41 on the benchmark’s autonomous arbitrary-code-execution (ACE) tasks, where frontier models averaged 20 of 41 [6]. On the cyber-range exercise, Kimi K3 advanced an average of 17 of 32 attack-path steps, against a frontier average of 28.5, and completed the full attack chain in only one of ten attempts [6]. Read together, a formal, government-run capability evaluation found Kimi K3 essentially unable to autonomously produce working arbitrary-code-execution exploits in a controlled benchmark, while an unverified, self-published case study from the same week claims the model did exactly that against a real, complex piece of production software. Both things could be true if the Redis case involved substantially more human guidance, retries, or post-hoc validation than the public narrative suggests, or if benchmark tasks poorly represent real-world exploitation of a specific, well-understood bug class the agent had access to study through public patch history. Security leaders should treat the Redis claim as a plausible but unverified data point rather than confirmed evidence of a new autonomous offensive capability tier, pending independent reproduction.

Consistent with a broader, faster-moving pattern

Regardless of how the autonomy question resolves, the Redis case fits an emerging pattern of AI-assisted vulnerability research compressing the cost and time of finding memory-safety bugs in mature, widely deployed software. CSA’s AI Safety Initiative has tracked this trend closely, from the first documented LLM-assisted zero-day exploit used in the wild — a two-factor-authentication bypass with forensic markers of AI-generated code, discovered by Google’s Threat Intelligence Group in May 2026 — to the disclosure that a commodity AI agent found 21 previously unknown FFmpeg vulnerabilities for roughly $1,000 in compute cost the following month [12][13]. Redis, like FFmpeg, is foundational infrastructure: it functions as a cache, message broker, session store, and data structure server embedded across an enormous share of cloud-native application stacks, often several dependency layers removed from the teams responsible for patching it. Whether or not Kimi K3 autonomously produced the specific exploit chain claimed, the direction of travel is consistent — the tools capable of finding exploitable defects in core infrastructure software are becoming cheaper and more widely accessible, and defenders should expect a steady stream of similar disclosures rather than treating any single case as an isolated event.

Recommendations

Immediate Actions

Redis operators running any of the affected versions — 6.2.22, 7.4.9, 8.6.4, or 8.8.0 — should upgrade to the July 23, 2026 patch releases (including 8.8.1, or the equivalent fixed build in their version line) without waiting for formal CVE assignment, since Redis’s own release notes confirm the underlying RedisBloom and TDigest loader defect that the patches address [2]. Security teams should also revisit the May 5, 2026 advisory to confirm their environments received the original CVE-2026-23479, -25243, -25588, -25589, and -23631 fixes, since the July findings suggest at least one of those fixes may not have fully closed its associated attack surface [4]. In parallel, teams should audit which clients and applications have access to the EVAL, RESTORE, and XGROUP commands, since both exploit paths depend on this access being available to an authenticated but potentially compromised or malicious client.

Short-Term Mitigations

Organizations should use Redis ACLs or the rename-command directive to restrict RESTORE, EVAL, and stream consumer-group management commands to only the specific service accounts and applications that require them, rather than leaving them broadly available to any authenticated connection. Network-level isolation — ensuring Redis instances are reachable only from application servers on private networks, never directly from the internet — remains a durable mitigation against both this disclosure and the broader class of post-authentication RESTORE-command vulnerabilities Redis has patched twice in the past three months. Teams operating RedisBloom or RedisTimeSeries modules should inventory which workloads actually require them; disabling unused modules removes an entire class of attack surface that a Redis core patch alone does not address. Given the apparent incompleteness of the May Streams fix, organizations should also enable monitoring for anomalous XGROUP, RESTORE, and EVAL usage patterns rather than treating a single patch cycle as closing the issue permanently.

Strategic Considerations

Security and engineering leadership should treat self-reported claims of autonomous AI vulnerability discovery — including this one — as signals worth tracking rather than as calibrated capability benchmarks, and should weight government or academic red-team evaluations like the AISI/CAISI Kimi K3 assessment more heavily when making risk decisions about AI-enabled offensive capability. At the same time, the direction of the underlying trend is not in serious doubt: the cost of finding and weaponizing memory-safety defects in foundational open-source infrastructure is falling, and organizations that depend on Redis, FFmpeg, OpenSSL, or comparable widely embedded components should assume that both defenders and adversaries have growing access to AI-assisted discovery tooling. This argues for accelerating patch-deployment timelines for foundational infrastructure components specifically, treating any RESTORE-command or RDB-deserialization advisory from Redis as high priority regardless of whether a CVSS score has been assigned yet, and evaluating AI-assisted static analysis or fuzzing for internally maintained forks or heavily customized deployments of open-source data infrastructure before an external researcher — human or AI — finds the next gap first.

CSA Resource Alignment

This case extends two lines of CSA AI Safety Initiative research directly. CSA’s research note on the first confirmed LLM-assisted zero-day exploit used in the wild, First AI-Built Zero-Day: Autonomous Exploit Creation in the Wild, examined the forensic markers that revealed AI authorship in a real authentication-bypass exploit and cautioned that semantic logic errors — historically requiring skilled human researchers to find — could be surfaced at scale if large language models proved capable of the task; the Redis case is a direct continuation of that question, this time applied to native-code memory-safety bugs rather than authentication logic. CSA’s subsequent note, AI Finds 21 FFmpeg Zero-Days for $1,000, documented the same cost-and-speed compression in a different foundational library and argued that enterprise remediation capacity, not discovery capacity, has become the binding constraint; the Kimi K3/Redis claims — if substantiated — would represent that same dynamic reaching one of the most widely deployed data infrastructure components in cloud-native architectures.

This case also converges with CSA’s AI-Accelerated Exploitation and Asymmetric Vulnerability Velocity research, which frames the widening gap between AI-accelerated vulnerability discovery and organizations’ remediation capacity as a systemic “patch debt” problem rather than a series of isolated vendor incidents; the patch-cadence and command-restriction recommendations above are best read as a specific instance of that broader capacity constraint [14].

Both cases also engage CSA’s MAESTRO framework for agentic AI threat modeling, which provides the vocabulary for reasoning about autonomous, tool-using research agents as threat actors in their own right rather than as passive software; organizations evaluating whether to deploy similar AI-assisted vulnerability discovery internally, defensively, should use MAESTRO to define the trust boundaries, validation checkpoints, and human review gates appropriate to that tooling. The AI Controls Matrix (AICM) v1.1’s application security and vulnerability management domains are the control baseline CSA recommends for evaluating whether an organization’s patch-deployment velocity and command-restriction practices are adequate to the accelerating discovery timelines these cases illustrate, and CSA’s STAR program offers a structure through which cloud service providers can disclose their own use of AI-assisted scanning and their remediation timelines for foundational open-source dependencies like Redis.

References

[1] Chaofan Shou, cited in The Hacker News. “Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say.” The Hacker News, July 2026.

[2] Cyber Security News. “New Kimi K3 AI Agent Uncovers 0-Day Exploits in Redis Server.” Cyber Security News, July 2026.

[3] Bera Buddies. “redis-poc: RCE PoC for Redis 6.2.22, 7.4.9, 8.6.4, 8.8.0.” GitHub, July 2026.

[4] Redis. “Security advisory: CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, CVE-2026-23631.” Redis, May 5, 2026.

[5] Wiz ZeroDay.Cloud. “CVE-2026-25243: Two Redis RESTORE Bugs Leading to RCE.” ZeroDay.Cloud, 2026.

[6] UK AI Security Institute and U.S. NIST Center for AI Standards and Innovation. “UK AISI / CAISI Preliminary Assessment of Kimi K3’s Cyber Capabilities.” NIST, July 2026.

[7] Forbes. “Chinese AI Startup Moonshot Unveils Kimi K3 Model—Will It Challenge OpenAI And Anthropic?” Forbes, July 17, 2026.

[8] Tom’s Hardware. “China’s 2.8-trillion-parameter Kimi K3 beats Claude Fable 5 in Frontend Code Arena benchmark.” Tom’s Hardware, July 2026.

[9] Gizmochina. “Kimi K3: Moonshot AI unleashes 2.8 trillion parameter model for free.” Gizmochina, July 19, 2026.

[10] IBTimes UK. “Kimi K3 Beat Claude at Coding, Now It’s Allegedly Writing Zero-Day Exploits in 27 Minutes.” IBTimes UK, July 2026.

[11] Redis. “Reporting a Vulnerability.” GitHub, accessed July 2026.

[12] CSA AI Safety Initiative. “First AI-Built Zero-Day: Autonomous Exploit Creation in the Wild.” CSA Labs, May 18, 2026.

[13] CSA AI Safety Initiative. “AI Finds 21 FFmpeg Zero-Days for $1,000.” CSA Labs, June 7, 2026.

[14] CSA AI Safety Initiative. “AI-Accelerated Exploitation and Asymmetric Vulnerability Velocity.” CSA Labs, May 30, 2026.