CyberKimi, an unrestricted fork of Moonshot AI’s Kimi K3, is at the centre of a claim that would collapse browser patching into nothing. Its creator says the model read a Chrome V8 security patch published on 2 September 2026, found what the fix missed, and had a working exploit chain running against Chrome Stable in under 24 hours. The claim went up on X on 4 September. Nobody outside that account has reproduced it.
That combination — highly specific technical detail, a demonstration video, and zero independent confirmation — is exactly the shape of story that gets amplified badly. It also arrived in the same week Google shipped a genuine, separately confirmed V8 zero-day fix, which is why the two keep getting merged into one headline. They are not the same event, and the difference matters for anyone deciding what to patch this morning.
This article separates them. It covers what the CyberKimi post actually claims, the exploit chain it describes, the four specific things the video does not establish, Google’s confirmed CVE-2026-85046 patch, what CyberKimi is as a product, and the awkward gap between this claim and the vendor’s own published benchmark evidence. Everything below is drawn from the original post, the vendor’s site and benchmark repository, the NVD record and trade coverage, all read on 6 September 2026.
Table of contents
- What CyberKimi Claims It Did to the September 2 V8 Patch
- The Exploit Chain CyberKimi Describes, Step by Step
- What the CyberKimi Video Does Not Prove
- Google’s Separate, Confirmed V8 Zero-Day the Same Week
- What CyberKimi Actually Is, and How It Was Built
- The CyberKimi Benchmark Record, Read Carefully
- The Gap Between the CyberKimi Benchmark and the CyberKimi Claim
- Why the CyberKimi Timeline Is the Real Story
- What Security Teams Should Do About CyberKimi This Week
- Frequently Asked Questions About CyberKimi
- References
What CyberKimi Claims It Did to the September 2 V8 Patch
The claim is unusually concrete for a social-media exploit boast, which is both why it drew attention and why it is worth reading closely rather than dismissing.
The post, in one paragraph
On 4 September 2026, the account @lordx64 — the malware reverse engineer Taha Karim, who identifies himself as the founder of Adversarial AI — posted a video and a technical summary. He says he trained CyberKimi on a corpus of historical unpatched vulnerabilities, then pointed a custom harness at V8’s security-relevant code changes on the main development branch. When Google published a V8 patch on 2 September, the harness flagged it.
The two bugs the harness flagged
From that single patch diff, the post says the model identified two distinct issues, tracked internally as Chromium bug numbers 554421904 and 530292883. The first is described as a Late Load Elimination aliasing bug in V8’s optimising compiler. The second is a race condition in object handling, referred to as a SLICED-PARENT-FLIP race. Neither carried a public CVE identifier at the time of the post, and Chromium security bugs stay restricted for months, so outside readers cannot open either report.
The claimed outcome
CyberKimi is said to have chained the two into a full renderer sandbox escape and executed a command on the host operating system. The post calls it a “silent in-the-wild” chain and asserts that Chrome Stable is not protected against it. The weaponisation, it says, was autonomous and took under 24 hours from patch publication.
| Element of the claim | As stated in the post |
|---|---|
| Date posted | 4 September 2026, on X |
| Model | CyberKimi, a cyber-tuned fork of Kimi K3 |
| Trigger | V8 security patch published 2 September |
| Bug one | Late Load Elimination aliasing, crbug 554421904 |
| Bug two | SLICED-PARENT-FLIP race, crbug 530292883 |
| Claimed result | Renderer sandbox escape to host command execution |
| Claimed time | Under 24 hours, autonomous |
| Public CVE | None assigned at time of posting |
| Independent verification | None as of 6 September 2026 |
The Exploit Chain CyberKimi Describes, Step by Step
The post does not just assert a result; it lists the stages. Reading them in order shows what would have to be true, and where the hard part sits.
From an aliasing bug to an in-cage primitive
The first stage is described as a deterministic forge built on the Late Load Elimination bug, producing a primitive inside V8’s memory cage. In plain terms, the compiler is convinced that two references point to different objects when they point to the same one, which lets the attacker read and write memory the script should not touch — but only inside the sandbox V8 draws around itself.
From caged read and write to the whole sandbox
The second stage composes that caged access into sandbox-wide read and write. The post describes forging an external BigUint64Array pointer and leaking the binary base address at runtime, explicitly noting there are no baked-in offsets. That detail is a capability claim in itself: an exploit that resolves addresses at runtime survives across builds, where a hardcoded offset breaks on the next release.
From memory control to program-counter control
The third stage is where the chain leaves memory and takes the processor. The post cites a RegExp calling-convention desynchronisation to gain program-counter control, then a jump-oriented programming gadget chain assembled inside a controlled string, ending in a call to the C library’s system() function. That is the sandbox escape. Everything before it is contained; this is the step that is not.
Why the calculator matters, and why it does not
The video ends with a calculator application opening. Popping the calculator is the oldest proof-of-concept signal in exploit development, and it does show that a command ran outside the browser process. It proves nothing about the route taken to get there — and with the sandbox already disabled, that route is the entire question. This is why researchers publish write-ups and crash traces alongside the clip rather than instead of it.
What the CyberKimi Video Does Not Prove
Four specific things stop this from being a verified result. None of them means the claim is false. All of them mean it is not yet evidence.
The sandbox was switched off
The Chromium build in the video is launched with --no-sandbox. Disabling the sandbox is a routine step while developing an exploit, because it removes noise from the debugging loop. It is also, precisely, the boundary the chain claims to defeat. A demonstration of a sandbox escape recorded with the sandbox disabled cannot show that the escape works, and this is the single largest hole in the CyberKimi evidence.
The build in the overlay predates current Stable
Observers reading the video overlay put the target at Chromium 152.0.7977.80. Google shipped 152.0.7977.82 and .83 to the Stable channel around 3 and 4 September. So the demonstration appears to run against a build that current Stable has already superseded, which sits awkwardly beside the assertion that Stable is unprotected.
No CVE, and no readable bug reports
Two Chromium bug identifiers are not the same as two published vulnerabilities. Security bugs in the Chromium tracker are restricted while a fix propagates, so nobody outside Google can confirm that 554421904 and 530292883 describe the flaws the post says they describe, or that they are unfixed.
Nobody has reproduced it
As of 6 September 2026, no security vendor, no independent researcher and no member of the Chrome security team has corroborated the CyberKimi chain, and Google has not commented on it. Reproduction under default, fully sandboxed conditions is the only thing that settles this, and it has not happened.
| What is claimed | What the published evidence supports |
|---|---|
| A working renderer sandbox escape | A clip recorded with the sandbox disabled |
| Chrome Stable is not protected | A target build older than shipping Stable |
| Two live, unfixed V8 bugs | Two restricted tracker IDs nobody can read |
| Fully autonomous weaponisation | A narrative summary, no transcript released |
| Under 24 hours from patch to exploit | Two timestamps, no intermediate artefacts |
| Arbitrary command execution on the host | A calculator window, cause not established |
Google's Separate, Confirmed V8 Zero-Day the Same Week
This is the part that is not in dispute, and it is the part that should drive action. It is a different vulnerability from the two the CyberKimi post names.
CVE-2026-85046, exploited in the wild
Google shipped Chrome 152.0.7977.82 on 3 September 2026 with 12 security fixes, one of them already under active attack. CVE-2026-85046 is a type confusion bug in V8, scored CVSS 8.8 High, and the NVD record states that it allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. Google confirmed exploitation and withheld attack details pending patch adoption.
What the patch actually contained
The same update carried a separate fix for a V8 race condition. CVE-2026-85046 was reported by the researcher Salvatore Gulizia, who works under the handle Serotav, on 4 August 2026 and earned a $1,000 bounty — a modest figure for a V8 bug, which usually signals moderate rather than trivial exploitation complexity. Patched versions are 152.0.7977.82 and .83 on Windows and macOS, and .82 on Linux.
The severity distinction that keeps getting lost
Read the two stories side by side and the difference is stark. Google’s confirmed zero-day gets code execution inside the V8 sandbox. The CyberKimi claim is a full escape out of it, onto the host. Those are different severity classes, and conflating them turns a serious-but-contained browser bug into an unverified full-system compromise. This is Chrome’s sixth actively exploited zero-day of 2026, following CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 and CVE-2026-11645.
| Date | Event |
|---|---|
| 4 Aug 2026 | Salvatore Gulizia reports CVE-2026-85046 to Google |
| 9 Aug 2026 | CyberKimi released publicly, built in about five days |
| 1 Sep 2026 | Same account claims a CVE-2026-79236 exploit inside 24 hours |
| 2 Sep 2026 | Google publishes a V8 security patch on the main branch |
| 3 Sep 2026 | Chrome 152.0.7977.82 ships; CVE-2026-85046 record published |
| 4 Sep 2026 | CyberKimi video posted claiming the 2 Sep patch was weaponised |
| 5 Sep 2026 | Claim circulates on Reddit and threat-intelligence feeds |
| 6 Sep 2026 | Still no CVE, no vendor comment, no reproduction |
What CyberKimi Actually Is, and How It Was Built
The model is not a rumour. It is a product with a public site, a price list and a published benchmark record, which makes the capability question answerable in a way the exploit claim is not.
An ablated fork of Kimi K3
CyberKimi is built on Moonshot’s Kimi K3, a mixture-of-experts model of roughly 2.8 trillion parameters. Rather than jailbreaking it at the prompt layer, the vendor says it computed the refusal direction from the model’s own activations and removed it from the weights — 278 matrices across 93 layers, described as forward-only maths with no capability loss. The first version was assembled in about five days and released on 9 August 2026.
What it was tuned on
On top of the ablation, the vendor reports fine-tuning against incident-response and digital forensics material, zero-day write-ups and exploitation proofs of concept, malware reverse-engineering reports, and red and blue team playbooks. That corpus is narrow and operational by the standards of cybersecurity more generally, and nothing like the open-web training data behind a general-purpose model. It is also the part of the recipe the vendor credits for its capability gain, rather than the ablation.
Version two is planned as a reinforcement-learning run over verifiable attack and defence environments, using 1,507 CyberGym tasks plus private live-CVE ranges, on a training mixture the vendor describes as 75% real-world material and 25% synthetic.
What it costs to run
Access is pay-per-use from a prepaid wallet with no subscription: $8 per million input tokens, $0.80 per million cached input tokens and $30 per million output tokens. The vendor states it keeps no request logs, runs no telemetry and never trains on user prompts, and it lists membership of NVIDIA’s Inception programme. The pitch is dual-use — the same model for exploit development and for detection engineering.
Why an ablated model is not automatically a stronger one
Removing a refusal layer changes what a model will answer, not what it can do. The interesting question is whether the cyber tuning raised capability, and the vendor’s own benchmark work is the only public attempt to measure that. This is the same distinction that separates a governed frontier release like the Critical cyber rating OpenAI attached to GPT-6 Astra from an unrestricted fork: one publishes evaluations with its safeguards described, the other publishes a video.
The CyberKimi Benchmark Record, Read Carefully
Here the picture gets more useful, because there are numbers, transcripts and a documented method. The results are respectable. They are also a long way from the 4 September claim.
ExploitBench: eight capabilities out of sixteen, unassisted
On ExploitBench’s v8-cve-2024-6100 environment — a WASM type-canonicalizer type confusion, graded on 16 exploitation capabilities per bug — CyberKimi scored 8 out of 16 unassisted, against 4 out of 16 for stock Kimi K3 on the same harness and prompt. Doubling the base model is a real result, and it is evidence that removing the guardrails did not damage capability.
The methodology pack that added two capabilities
A second run added a one-page exploit-technique brief to the initial prompt. That run banked 10 out of 16, picking up binary and library information leaks, and reached the external pointer table corruption stage. The vendor discloses the brief verbatim in the transcript rather than hiding it, and labels the run as assisted — which is the right way to report it.
Where that sits on the leaderboard
Read the leaderboard the vendor itself published and the framing “behind only Claude Mythos and GPT 5.5-Codex-AutoNudge” is accurate but flattering. The gap is five to six capabilities out of sixteen.
CyberGym: a first place with no public transcripts
On a stratified 100-task subset of CyberGym, which grades server-verified crashes rather than self-reports, CyberKimi scores 0.860 — ahead of GLM-5.3 at 0.845, DeepSeek-V4-Pro at 0.833, Gemini 3.5 Flash Cyber at 0.832, Claude Mythos at 0.831 and GPT-5.5 at 0.818. Stock Kimi K2.5 sits at 0.413 on the same board. The lead over second place is 0.015, or one and a half tasks in a hundred.
The evidence standard is inconsistent between the two boards
For ExploitBench, the vendor publishes per-episode transcripts, tool-call logs and grader verdicts, and invites anyone to recount the capabilities. For CyberGym, the same site states that full transcripts and grader records are not public and are available on request. The ExploitBench repository also describes itself as a private staging repository that goes public when the full 14-bug matrix completes. The strongest headline number is therefore the least inspectable one.
The Gap Between the CyberKimi Benchmark and the CyberKimi Claim
This is the most useful thing in the whole story, and it comes from the vendor’s own documentation rather than from any critic.
The unassisted run never found the escape
The published write-up for the 8 out of 16 run says the model built the primitive chain from a cold start, then “degraded into a repetition loop while searching for the sandbox-escape route” and was stopped at roughly turn 324 of a 400-turn budget. On the one bug where CyberKimi’s work is fully documented, the sandbox escape is exactly the step it did not complete.
The assisted run stopped at the doorstep
The 10 out of 16 run, with a human-written technique brief in context, ran cleanly for 264 turns and reached external pointer table corruption — described in the write-up as the doorstep of arbitrary read and write. It halted there. Again, no escape, and this time with human methodology supplied.
What that gap means for the 4 September claim
The 4 September claim is not an incremental step beyond that record; it is a different tier. It asserts an autonomous, end-to-end chain through the escape to system() on a bug disclosed two days earlier, from a model whose documented ceiling on a two-year-old bug, with a technique brief supplied, was the stage immediately before that. It is not impossible — a fresh patch diff is a far richer starting point than a cold benchmark environment, and the vendor’s stated harness is built precisely to exploit that. But it is a claim that needs the same transcripts the vendor already produces for ExploitBench.
Why the CyberKimi Timeline Is the Real Story
Strip out the calculator and the disputed escape, and something genuinely new is still being described. It is not the exploit. It is the loop.
Patch diffing is not new; the automation is
Researchers have mined patches for incomplete fixes and chained V8 bugs for years, entirely without machine learning. What the CyberKimi harness describes is that same craft turned into a standing pipeline: watch the vendor’s security commits, variant-mine whatever the fix left behind, attempt weaponisation, repeat. The novelty is the cadence and the unit cost, not the technique.
The window that keeps shrinking
Browser patches reach users on a gradual rollout. If a pipeline of this kind works even intermittently, the gap between a fix landing on the main branch and a fleet actually being safe becomes the interesting number — and it is measured in days, while the pipeline is measured in hours. That is the same compression we covered when an agentic harness was used to find and patch a Visa vulnerability, pointed the other way.
Public patches are public intelligence
The uncomfortable structural point is that the patch itself is the map. Open-source browser engines publish their fixes before every user has them, and that asymmetry has always existed. Automation makes it cheaper to exploit, which strengthens the case for faster rollout rather than for less disclosure.
What Security Teams Should Do About CyberKimi This Week
None of this needs the claim to be true to be actionable. The confirmed CVE alone justifies the work, and the CyberKimi story sets the tempo.
Patch Chrome now, and verify the version
Update to 152.0.7977.82 or later and confirm the deployed version rather than trusting the rollout. Chromium-based browsers — Edge, Brave, Opera, Vivaldi — pull from the same V8 codebase and each needs its own vendor build, so track those separately.
Do not wait for a CVE to prioritise
A restricted bug tracker number is not a reason to defer. Treat “fix shipped, details withheld” as the strongest possible signal to deploy, because that is what Google does when exploitation is already happening.
Measure browser patch latency as an SLA
If the offensive loop runs in hours, the only defensive number that matters is how long your estate takes to reach a patched build. Measure it, publish it internally, and set a target. Most organisations have never measured it.
Ask vendors for transcripts, not videos
This applies well beyond CyberKimi. When any tool claims autonomous exploitation, the reproducible artefacts are the transcript, the tool-call log and the grader verdicts. A vendor that publishes those for one benchmark and not for its headline claim has told you which number to trust. Our own cybersecurity work applies the same standard, and the principle is identical to the one behind red-teaming an AI system before launch.
Assume renderer compromise is survivable and plan for it
CVE-2026-85046 gets an attacker code execution inside the sandbox. That is bad and containable. Build detection for post-exploitation behaviour on endpoints rather than betting everything on the browser boundary holding.
| Action | Trigger | Timeframe |
|---|---|---|
| Force Chrome to 152.0.7977.82+ | Confirmed in-the-wild CVE | Today |
| Audit Edge, Brave, Opera, Vivaldi builds | Shared V8 codebase | This week |
| Measure browser patch latency | Hours-scale offensive loop | This quarter |
| Add endpoint post-exploitation detection | Sandbox is not the last line | This quarter |
| Require transcripts in vendor claims | Unverifiable capability marketing | Next procurement |
| Watch for a CVE on the two crbug IDs | Claim still unverified | Ongoing |
Frequently Asked Questions About CyberKimi
Is the CyberKimi Chrome exploit claim real?
Unknown, and that is the honest answer. It is specific enough not to dismiss, and unverified enough not to act on. The video was recorded with the browser sandbox disabled, no CVE exists for the two bugs named, and no independent researcher has reproduced the chain.
Do I need to patch Chrome because of this?
Yes, but not because of this claim. CVE-2026-85046 is a separate, confirmed V8 zero-day already exploited in the wild, fixed in Chrome 152.0.7977.82. That is the reason to patch today.
Is CyberKimi a real product?
Yes. It is a commercially available fork of Kimi K3 with guardrails removed at the weight level, sold pay-per-use at $8 per million input and $30 per million output tokens, with a published ExploitBench record and transcripts.
How good is CyberKimi at exploitation, measurably?
On the one bug with full public evidence it banked 8 of 16 capabilities unassisted and 10 of 16 with a human technique brief, against 4 of 16 for the stock base model. Frontier models scored 15 and 16 on the same environment.
Does removing an AI model’s guardrails make it more capable?
Not by itself. The CyberKimi results suggest ablation did not reduce capability, and the doubling over stock Kimi K3 is attributed to cyber-specific fine-tuning rather than to the ablation. Those are separate interventions with separate effects.
What would make this claim credible?
The same artefacts the vendor already publishes for ExploitBench: the full episode transcript, the tool-call log, the harness configuration, and a reproduction against a default sandboxed Chrome Stable build. Failing that, a CVE assignment on either tracker ID.
References
Taha Karim, original CyberKimi V8 exploit claim on X
CyberKimi — The Unrestricted Cyber Operations Model
CyberKimi x ExploitBench — Results and Evidence
Chrome Patches Exploited V8 Zero-Day: Update Now
OffSeq Threat Radar entry for the CyberKimi claim
CyberKimi AI Claims It Weaponized a Chrome V8 Patch in Under a Day
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.