A flaw fixed in Chromium's code was still open in Chrome, and Chinese espionage moved in

Between 1 and 12 September, two teams, Proofpoint and Volexity, separately documented the same thing: several suspected Chinese espionage groups running an exploit chain against Google Chrome and Windows whose main flaw was already fixed in the code, though not in the browser. The fix for that flaw had existed in the Chromium source code since early August. It had not reached the version of Chrome that people actually run. That delay left room for an attack.

Browser developers have a name for it: the patch gap, the interval between a fix landing in an open repository and that fix reaching end users. What stands out this time is not the gap itself, which has been understood for years, but who exploited it, how quickly, and with what help. The rest of this analysis rests on the reports from Proofpoint and Volexity, two teams with their own telemetry that reached the same activity separately.

The gap almost nobody was watching

Chromium is open source. When a researcher reports a flaw and Google fixes it, the change is published in the public Chromium tree before Chrome, Edge, Brave or Vivaldi package it into a stable release and ship it. That interval can last days or weeks. During that time the fix is visible to anyone following the repository, while users keep running the vulnerable code.

The campaign's central flaw, CVE-2026-85046, is a type confusion in V8, Chrome's JavaScript and WebAssembly engine. A researcher reported it on 4 August and the fix entered the Chromium code shortly afterwards. Google did not publish the stable Chrome release that carried it until 3 September, as Help Net Security reports. Volexity detected the first attack on 1 September. For Chrome users the flaw was a de facto zero-day even though the fix had sat in plain sight in open source for weeks.

Four facts that hold the analysis up

Two investigations, one chain

Volexity saw two groups —UTA0560 and JungleBamboo, the latter also known as APT31 or Violet Typhoon— exploiting the same chain from 1 September against NGOs and other targets, with byte-for-byte identical exploit code but different payloads. Proofpoint, which tracks the same activity under the name BlueMoon exploit kit, counted four espionage groups, most with a suspected China nexus, adopting it between 28 August and the first days of September. Two teams with different telemetry describing the same chain give the finding a weight a single report would not carry.

Three flaws chained together

The chain combines three vulnerabilities. CVE-2026-85046 gives arbitrary read and write inside V8's sandbox. A second, CVE-2026-87491, a WebAssembly defect, escapes that sandbox; Google fixed it on 8 September, again per Help Net Security, and it was Chrome's seventh zero-day of the year. The third, CVE-2026-85880, is a privilege escalation in the Windows kernel's ALPC mechanism that carries the attacker from a browser tab to SYSTEM. Microsoft patched it in the September Patch Tuesday, the largest in its history, and it was one of two flaws already under exploitation before the patch.

A timeline that does not fit handcrafted development

Both Chrome flaws were patch-gap zero-days. Volexity found dates in the exploit code itself that place its development between 27 and 29 August, only days before the first emails. A complete browser exploit chain has historically been a rare, expensive capability, the preserve of a few actors. Here it was developed, deployed and shared across several groups in a matter of days.

Signs that AI lowered the bar

Proofpoint recovered artefacts from the kit (extensive debug logging, comments documenting rounds of failure and revision, and a reference to a markdown handover file of the kind AI agents use to pass work between sessions) consistent with AI-assisted development, though no single artefact confirms it on its own. Volexity agrees that the developer reverse-engineered the fixes from Chromium source.

If that reading holds, it fits the pattern we described when AI began to invent attacks instead of copying them: AI does not add a new capability; it shortens the time between a public fix and a working exploit.

What has changed since a year ago

A year ago the patch gap was a theoretical problem that mainly worried the Chromium teams themselves. The practical barrier was never knowing the gap existed; it was the difficulty of turning a source-code diff into a reliable exploit before the stable release shut the door. That difficulty is exactly what a language model trims.

You can see the result in Chrome's year: seven zero-days in 2026, two of them within a week in September. And you can see it in how the attackers operated. Their chain was deliberately loud: the final stage downloaded an executable with a plain curl command, something an EDR with behavioural rules should catch without trouble. They prioritised arriving first over going unnoticed. When the time advantage is the asset, the operation is tuned for speed, not stealth.

What it means for defensive architecture

The first consequence is awkward for the usual hygiene message: "we're up to date on patches" stops being a complete answer when the public fix precedes the deployment. Between a fix being visible in open source and its reaching your fleet there can be days or weeks when you are exposed and cannot speed it up. The one lever left is to force the browser to restart so it applies the release that is already out.

The second is that the browser is a top-tier attack surface, not just another desktop application. The chain did not require the victim to download or open an attachment: a click on a link in a spear-phishing email and a page visit were enough. In two of the cases the ultimate target was not the machine but a malicious browser extension disguised as a Google Gemini assistant, built to steal credentials and sessions. It is the vector we examined in browser extensions and GenAI, now delivered through a chain of zero-days.

The third is a governance point. Many organisations treat browser updates as something the user sorts out alone. These campaigns depended on the browser not restarting to apply the patched version. Without a policy that forces the restart and measures which version each machine runs, the fix exists but does not protect.

Which controls still hold and which have expired

Browser update management still holds, understood as a measurable control rather than an act of faith: force a restart after every security release and check the deployed version across the fleet, above all on the older Windows branches, which is where the kernel escalation worked.

Behavioural detection also holds up, and here it was effective: the chain's default process tree was chrome.exe launching cmd.exe, cmd.exe launching curl.exe, and curl.exe downloading and running the binary, a sequence that has no business appearing under a browser. It is the same principle as detecting abuse of legitimate binaries: watch the whole execution chain instead of the file in isolation.

Extension control has not expired either. The two groups that installed a malicious extension had to tamper with Chrome's secure preferences file to defeat its integrity check; an enterprise policy that restricts which extensions may be installed cuts that step off. And the concrete indicators both teams publish are usable: scheduled tasks with names that mimic updaters (EdgeCore_AutoUpdate, GeForceService), session-storage keys such as v8ctf_exp_attempt, and stray executables in %TEMP%. Shipping endpoint and browser telemetry to the SIEM is what turns those indicators into detection.

What has expired is the idea that a CVSS score or a patch date describes your real exposure. Prioritisation by real risk has to fold in the actual deployment state, beyond the mere availability of the fix, along with monitoring of the patch gap in the open-source software you run. It is the urgency test the CISA BOD 26-04 already introduced: observed exploitation over theoretical score. All three vulnerabilities entered the KEV catalogue between 4 and 9 September.

What remains open

Neither Proofpoint nor Volexity knows for certain how several distinct groups obtained the same chain at almost the same time. The hypotheses range from a shared commercial supplier to a state intermediary that distributed it. Volexity rates this with low confidence, and that is the honest limit of the case today.

What is clear is the direction. The patch gap in open-source software is no longer a technicality: it is an exposure window that can be exploited, and reconstructing public fixes with AI help opens it faster.

So the metric that really describes the risk is how many days each patch takes to reach every machine once the fix is public. Few organisations measure it.

At Hard2bit we work this kind of exposure through vulnerability management and threat hunting, where the figure that matters is not the one in the advisory but the one measured across the fleet.

The techniques, timelines and indicators cited come from the reports of Proofpoint, Volexity, Google, Microsoft and CISA with the information available on 14 September 2026, and are described for detection and defence. Attributions to groups are those of the cited researchers and may evolve. No mention implies a design fault in the products cited beyond the vulnerabilities acknowledged by their vendors. Each organisation should validate the indicator hunts in its own environment before applying them.