Cyberkimi's 24-Hour Chrome Exploit Claim Has a --no-sandbox Problem

TL;DR

An X account (@lordx64) running an unrestricted fork of Moonshot’s Kimi K3, branded “Cyberkimi,” claims it turned a V8 security patch from 2026-09-02 into a working Chrome exploit chain in under 24 hours. The demo ran with --no-sandbox, no CVE has been matched to the bugs, and the same account posted a near-identical 24-hour claim four days ago. The genuinely confirmed Chrome news this week is CVE-2026-85046, an actively exploited V8 type-confusion bug (CVSS 8.8) that Google patched on 2026-09-04 and CISA added to KEV the same day, with no AI involvement reported. Patch your browser; discount the video.

The Cyberkimi demo ran Chrome with --no-sandbox, then demonstrated command execution. The sandbox is the control that decides whether a V8 memory-corruption bug ends as a browser crash or as a compromised machine, and it was switched off before the run started.

That single flag is the reason to treat the claim as unproven. The pitch is strong: an unrestricted fork of Kimi K3 watches public V8 patch diffs, picks a bug out of one, and produces a chain (memory corruption, forged pointers, a RegExp-based control-flow hijack, command execution) inside a day. The write-up that carries the most detail, OffSeq’s Threat Radar entry, also records that no third party has confirmed which bugs were exploited or whether any assigned CVE matches.

A note on provenance before going further: the Reddit link behind this piece is a share short-code that could not be resolved. The post it points to is understood to be an r/hacking submission from today, cross-posted by the same author to r/cybersecurity, matching on title, author and date. Treat that identification as a strong guess. The r/hacking copy had one upvote and zero comments, so there is no thread discussion to report.

What is actually confirmed about Chrome this week

Google shipped Chrome 152.0.7977.82/.83 on 2026-09-04 to fix CVE-2026-85046, a V8 type-confusion bug rated CVSS 8.8 that Google says is exploited in the wild. CISA added it to the Known Exploited Vulnerabilities catalog the same day with a remediation deadline of 2026-09-18.

Nothing links that bug to Cyberkimi or to any AI-assisted discovery. It was found and reported through ordinary channels. Two Chrome stories landing in the same week does not make them one story, and the verified one is the one that should move your patch schedule.

The credible version of this capability already exists

The interesting claim here is not new, and the best-documented instance of it is more useful than the viral one. In April, a researcher published I Let Claude Opus Write a Chrome Exploit, describing an AI-produced V8 exploit chain built from patch diffs. The write-up gives the numbers: $2,283 in API spend, roughly 20 hours of human steering, dozens of failed attempts, and a target bug already patched in a newer release.

Those numbers are what make it believable, and they also deflate the framing. One Hacker News commenter put the arithmetic plainly: “20 hours, a week of work, 2283$ spent and over 2 trillion tokens, is not very 10x-ing as we were promised.” The capability is real. The economics are still ordinary.

Simon Willison has tracked the same trend from the defensive side. Vulnerability Research Is Cooked relays Thomas Ptacek’s argument that coding agents restructure exploit-development costs. Last week’s Just a rumour of a bug is enough collects reports from OCaml maintainer Anil Madhavapeddy and rclone maintainer Nick Craig-Wood on shrinking time-to-exploit and CVE-assignment backlogs. Named maintainers describing their own projects beats an anonymous demo video, every time.

Four red flags on an AI exploit claim

The Cyberkimi post supplies a usable checklist, since it trips most of it:

Defences disabled for the demo. --no-sandbox removes the step that decides whether the bug matters. If a chain is demonstrated with a mitigation switched off, the chain has not been shown to work.
No CVE or bug ID matched by anyone else. OffSeq cites two internal Google tracker numbers, 554421904 and 530292883, which nobody has checked against the Chromium issue tracker.
A repeat pattern of the same claim. The same account posted a similarly framed 24-hour result four days ago, said to target CVE-2026-79236. That CVE appears in an HKCERT bulletin from 2026-08-26 as part of a routine batch of Chrome fixes rather than a flagged in-the-wild zero-day, though that bulletin could not be read directly and the detail is unconfirmed.
Costs and failures undisclosed. The Hacktron write-up states its spend, its hours and its dead ends. A claim that reports only the win is reporting a highlight reel.

The demo may well be genuine. As it stands the claim carries no evidential weight, and a security team that reprioritises on the strength of it is responding to a video rather than a finding.

The chain of custody matters too. The original X post could not be retrieved in research, so its contents reach here only through OffSeq’s summary. Every strong statement about what Cyberkimi did is currently secondhand.

What to do

Update Chrome to 152.0.7977.82 or later, today, because of CVE-2026-85046 and its KEV deadline. Then treat the wider pattern as a planning input rather than an emergency: assume the safe window between a public patch diff and a working exploit for it keeps shrinking, and shorten your own patch cycle to match. That change is worth making on the strength of the Hacktron numbers and the maintainer reports alone. It does not need the video.

Sources: Chrome patches actively exploited V8 zero-day • OffSeq Threat Radar: Cyberkimi claim • I Let Claude Opus Write a Chrome Exploit • Vulnerability Research Is Cooked • Just a rumour of a bug

Coverage: r/hacking thread • Hacker News on the Claude Opus exploit