The Fix Was Public. The Patch Was Not.

The Fix Was Public. The Patch Was Not.

11 min read

On August 4, 2026, a private security researcher reported a type confusion in V8 to the Chromium project. A fix landed in the open source Chromium codebase, where anyone with a git clone can read it. By the last week of August, an exploit kit existed that chained that bug to two more and turned a phishing click into code execution in the Chrome browser process. Chrome users did not have the fix until September 3.

Nothing about this bug was secret. That is the part worth writing about.

Volexity published the first detailed account on September 9 and a second part on September 21. Proofpoint published its own analysis the same day as part one, naming the kit BlueMoon. The story reached a wider audience on September 24 through Lukas Olejnik’s post on X, which framed the mechanism in one paragraph:

Private researcher reported a security vulnerability to Chromium on August 4. The fix went into the public source code but Chrome users never got it due to patching timelines. Two Chinese groups, apparently read that public fix, built an exploit chain from it and started phishing NGOs on September 1 using identical code. Technically an N-day but for anyone actually running Chrome, a zero-day. Here the public patch knowledge worked as an instruction manual. Open source means everyone can read the fix. With AI, some people just operationalise the knowledge faster.

That post had 296 likes and 26,714 views at capture, and the link in it resolves to the Volexity writeup.

A zero-day for users, an n-day in the source

Proofpoint states the mechanism plainly: both V8 vulnerabilities were “patch-gap” zero-days at the time of the observed activity, meaning they were “known vulnerabilities already fixed in public upstream Chromium source code” that “remained unpatched in the latest stable releases of Chrome and Chromium-based browsers available to the public.” The kit developer “likely used these publicly available Chromium patches to weaponize the browser exploit chain.”

The versions pin the timeline. CVE-2026-85046, the type confusion in V8, covers Chrome “prior to 152.0.7977.82,” and Google’s Stable Channel Update for Desktop, dated September 3, 2026, lists that CVE in the 152.0.7977.82 build. Reported August 4, patched for users September 3, with a full month in between in which the fix was public and the binary was not. The second bug, CVE-2026-87491, was fixed later still, in 153.0.8010.36.

This is not a Google oversight that the internet discovered last week. Google documented it in The Chromium Chronicle #32, “Mind the patch gap,” in February 2023: the patch gap is “the critical time between when you land the security fix and when the fix is shipped to users in a Stable channel update,” and when you land a fix, “that fix is publicly available to anyone that monitors our source code repositories, including bad actors and exploit brokers.”

The mitigations Google asked its own engineers for are about speed, not secrecy. Land merges as soon as they are approved. Do not sit on details. And, explicitly: “Don’t attempt to hide or obfuscate code or commit messages. N-day attackers are smart and will work around this.”

Three bugs, one kit, and four clusters

The chain is worth reading as an architecture, because each layer has a different owner and a different patch clock.

  • CVE-2026-85046: type confusion in V8 in Chrome, Chromium severity High, fixed in 152.0.7977.82. Per Volexity, it grants arbitrary read and write inside the V8 sandbox.
  • CVE-2026-87491: the second V8 bug, used to escape the V8 sandbox. Proofpoint describes it as a V8 sandbox escape; NVD’s description is an out of bounds write in V8 fixed in 153.0.8010.36.
  • CVE-2026-85880: a Windows kernel local privilege escalation in RtlpCreateServerAcl, used to escape the sandboxed renderer and inject into the browser process. Volexity reports it only affected a defined set of older builds: Windows 10 1809 through 22H2, Server 2022, and Windows 11 21H2.

After the browser process is reached, the chain runs a command chosen by whichever actor owns the campaign. Proofpoint’s writeup notes the default is a curl that downloads the actor’s executable and runs it, which is a lot of detection signal for a state-aligned operation.

Proofpoint tracked four espionage-motivated clusters using the same kit within days of each other, the first on August 28, most with a suspected China nexus. Volexity documented UTA0560, which delivered the GRIMWEDGE JScript backdoor, and JungleBamboo (APT31, Violet Typhoon, TA412), which installed LONGTALE, a credential-stealing Chrome extension built to look like Google’s Gemini extension. Both campaigns used “byte-for-byte identical shellcode.” Part two added a third actor, UTA0565, which ran the same kit from spoofed news and think tank domains on September 3 and 4, while the vulnerabilities were still unpatched, and dropped a malware family Volexity tracks as CLEANGULP.

What is asserted rather than proven: Volexity assesses with low confidence that the chain may have been sold or otherwise provided to different end users in China, and with medium confidence that the short patch window forced the actors to reuse the core exploit without modification. Proofpoint says it remains unknown how the distinct actors obtained the kit. The shared shellcode is a fact. The supply chain behind it is an assessment.

The kit shipped with its own debug harness

The most revealing artifacts are not the exploits. They are the operator conveniences.

Volexity’s breakdown of the exploit landing page documents 13 URL parameters: beacon for phase telemetry, dry for a dry run with no payload, force2 and forcepp to skip fingerprint gates, p2step and step as breakpoints inside the kernel and injection stages, stopAfter to halt at a named phase, retry and runpayload toggles, and mode, which must be set to payload before the exploit does anything at all. Without mode=payload, the page is inert. That is a testing safety switch shipped to victims.

The page also runs the exploit in a Web Worker rather than the main thread, so a failed attempt crashes a worker instead of the visible tab, and it stores an attempt counter in sessionStorage to retry up to five times. Dates in the script place development between August 27 and 29. The build tag reads b20260829a. Phishing emails started September 1.

Proofpoint’s read on this is the part that will follow the story around. It states that “no single artifact conclusively confirms AI-assisted development,” then lists indicators consistent with it: extensive diagnostic logging, a referenced markdown handover document, and detailed comments documenting successive debugging iterations and implementation decisions. Its conclusion is about cost, not certainty: this pattern “may reflect a falling cost and barrier to entry for this class of capability, as AI agents increasingly enable threat actors to develop exploits.”

Volexity is more direct, assessing with high confidence that as large language models become more popular and effective for rapid vulnerability research and exploit development, patch-gap vulnerabilities present an even greater risk. Google’s own threat intelligence arm reported in May 2026 that GTIG had, for the first time, identified a threat actor using a zero-day exploit it believes was developed with AI. Treat the specific BlueMoon claim as unconfirmed and the direction of travel as documented.

What the intuition gets wrong

Two instincts fail here.

The first is that a zero-day means nobody knew. In this case the vendor knew, the fix existed, the fix was committed in public, and the only thing missing was a binary on user machines. The vulnerability was not hidden from attackers. It was hidden from the people running the vulnerable code.

The second is that open source makes you less safe. The fix being public is what let defenders see the bug too. It is also what let the kit developer reverse the fix into an exploit in roughly three weeks. Both are consequences of the same property, and no amount of commit obfuscation changes it, as Google’s own guidance concedes.

What the defenders actually control is cadence. Every day between a landed fix and a shipped binary is a day the exploit is a specification anyone can read.

The operator consequence: your agent’s browser is a pinned image

Here the story stops being about desktop Chrome users and starts being about agent infrastructure.

I checked the browsers on this box while writing this:

$ google-chrome --version
Google Chrome 154.0.8037.57
$ chromium --version
Chromium 153.0.8010.36 snap
$ /home/dazeb/.cache/ms-playwright/chromium-1243/chrome-linux64/chrome --version
Google Chrome for Testing 153.0.8010.12

The desktop browser is current. The Playwright build that an agent framework would actually launch is 153.0.8010.12, which is below the 153.0.8010.36 boundary NVD defines as fixed for CVE-2026-87491, so it sits inside the affected range by version. That build is a chromium-1243 revision inside a cache directory, and the same pattern holds in a container: the browser is pinned by whatever image revision the stack was built against, and it moves when someone rebuilds, not when the stable channel updates.

A human’s Chrome auto-updates in days. An agent fleet’s Chromium updates when the image does. If your agent drives a browser, you own a browser patch pipeline whether or not you planned one, and its clock is the least monitored dependency in the stack.

The second half of the operator consequence is that the payload in these campaigns was an extension, not a backdoor. LONGTALE masquerades as a Google Gemini extension and takes keystrokes, form values, clipboard text, every cookie, plus localStorage and sessionStorage tokens. It screenshots pages matching C2-supplied keywords and exfiltrates on a roughly 30 second cycle. It has no remote code execution command at all, and Volexity assesses with low confidence that the actor did not need one, because the agent profile in the browser is where the authenticated sessions live.

Getting that extension installed was its own trust boundary failure. Volexity found that SUPERSTOMP copies the Secure Preferences file, removes the per-preference _encrypted_hash values and super_encrypted_hash, adds its extension, forges legacy HMAC values and a new super_mac, and writes the file back. On the next start Chrome sees no encrypted authenticators, falls back to the legacy MAC path, accepts the forged state, and then treats the profile as needing migration, generating fresh encrypted hashes for the modified state. The malicious extension ends up signed by the newer scheme. Chromium added the per-preference hashes in November 2025 and super_encrypted_hash in June 2026. Volexity notes the legacy fallback is enabled by default in Chrome releases as of September 8, 2026, and that only compiling Chromium from source disables it.

That is the sharpest lesson in the whole report, and it has nothing to do with the patch gap. An integrity migration with a compatibility fallback is a bypass, and the fallback usually outlives the migration.

The controls that follow from this are boring and specific. Treat the agent browser like any other pinned dependency with a security refresh cadence, and check the version the runtime actually launches rather than the one on your desktop. Give the agent its own browser profile with only the sessions it needs, never a copy of the human profile’s cookie store. Do not let an agent install extensions from a task instruction. And where you can disable legacy integrity fallbacks, do it, because the fallback is what turned a hardened preferences file into an accepted forgery.

Patch gap is not a disclosure policy problem. It is a release schedule observation, and the schedule belongs to whoever ships the binary you are running.

Sources:

Keep reading

The Sandbox Didn't Zero the Disk The AI Triage Called It 'Not a Bug.' It Was a Chrome RCE. The Guard Was Three Lines Above