The Fix Was Public. The Patch Was Not.

On 7 August a fix for a Chrome vulnerability was committed to the public Chromium source code. On 3 September it reached the stable version of Chrome that people actually run. In the 27 days between, someone built a working exploit, most likely by reading the public diff, packaged it with a Windows kernel flaw, and by 3 September five named espionage clusters were using it in phishing campaigns, the first from 28 August. Every organisation in that window was fully patched and exposed at the same time.

The instinct is to file this as a browser story. It is a supplier story. Chrome, Edge and every other Chromium-based browser inherit their security from an open-source project whose fixes are visible to attackers before they are installable by customers. That is a structural property of the platform most UK organisations run their working day through, and this month a well-resourced adversary demonstrated what it is worth.

What happened

Two threat intelligence firms published on 9 September, in coordination and with overlapping telemetry. Proofpoint named the kit BlueMoon. Volexity called the underlying problem what it is: a patch gap. The dates below are drawn from both reports and from the vendors' own advisories.

• 4 August 2026A private researcher reports CVE-2026-85046, a type confusion flaw in Chrome's V8 JavaScript engine, to the Chromium project.
• 7 August 2026The fix is committed to the open-source Chromium codebase. The change is public. No stable Chrome release carries it.
• 27 to 29 August 2026Build strings inside the exploit code place its development in this window, according to Volexity. Proofpoint notes the code retains verbose debugging comments, iterative revision notes and a reference to a markdown handover file, indicators it describes as consistent with AI-assisted development, though not conclusive.
• 28 August 2026Proofpoint observes the first use of BlueMoon by TA412, the China-aligned actor also tracked as APT31, JungleBamboo and Violet Typhoon, against NGOs, mining and commodity trading firms in the United States. Targets who click are shown a loading page while the browser is exploited, then redirected to a legitimate site.
• 1 September 2026Volexity detects a second Chinese actor, UTA0560, using the identical chain with byte-for-byte identical shellcode, against NGO customers, and finds JungleBamboo doing the same on separate infrastructure with a different payload.
• 2 to 3 September 2026Proofpoint sees three further clusters adopt the kit: UNK_LateNight against US aerospace and defence suppliers, delivering the ShadowPad backdoor; UNK_DoubleCheck against a Vietnamese manufacturer; UNK_QuietRacket against government, consulting and financial organisations in Indonesia and Singapore.
• 3 September 2026Google's stable Chrome release carrying the CVE-2026-85046 fix reaches users, 27 days after the commit.
• 8 September 2026Google ships Chrome 153.0.8010.36 fixing CVE-2026-87491, the second V8 flaw in the chain, and states that an exploit exists in the wild. The same day Microsoft's Patch Tuesday fixes CVE-2026-85880, the Windows kernel privilege escalation flaw that completes the chain. Proofpoint reports the compiled exploit for that flaw carries a 2025 timestamp it does not believe was forged.
• 9 September 2026Proofpoint and Volexity publish. CISA adds CVE-2026-87491 to its Known Exploited Vulnerabilities catalogue.

The exposure window ran from the public commit on 7 August to the stable release on 3 September. Attacks began on day 21. Sources: Volexity, Proofpoint, Google, Microsoft, CISA.

Why this one is different

Chrome zero-days are not rare. Google has fixed seven exploited in the wild this year. What is different here is not the bug but the economics around it, and three things stand out.

The attacker most likely did not need to find the vulnerability. Volexity assesses with medium confidence that the exploit developer reverse-engineered the public bug fix. Proofpoint calls the same conclusion likely. In that reading, the hardest part of a browser exploit chain, the discovery, was done for free by a security researcher acting in good faith, published by the vendor in the ordinary course of open-source development, and then weaponised in the interval before the vendor's own customers could benefit. The open development model that makes Chromium trustworthy is the same model that makes its fixes a roadmap. Google's own Chromium engineering blog has written about the problem; the industry calls it the patch gap, and this month it was 27 days wide.

The capability was shared, not hoarded. A working Chrome exploit chain has historically been a scarce and expensive asset, held tightly by one operator. This one appeared in the hands of five named espionage clusters within six days, from 28 August to 3 September, with identical core code and different payloads bolted on the end. Volexity assesses with low confidence that the chain was sold or otherwise supplied to multiple end users in China. Proofpoint offers a shared procurement chain or a central quartermaster as hypotheses, and notes the same pattern before the Exchange and SharePoint mass-exploitation events. Whichever explanation holds, the operational fact for a defender is that one exploit now equals many campaigns, each with its own lures, infrastructure and target list.

Identical exploit code, five named clusters, five payloads, six days. Attribution and cluster naming are Proofpoint's and Volexity's; the Windows stage only works on older builds.

It was rushed, noisy, and still worth doing. Proofpoint's analysis is unusually candid: the kit's default behaviour is to have the browser process run curl to download an executable and execute it, and in the observed campaigns that arrived via a command shell, which is about as visible as an intrusion gets to a competent endpoint product. The Windows stage only works on older builds: Windows 10, Server 2019 and 2022, and the first release of Windows 11. That narrows the viable targets and lowers the success rate. Proofpoint reads all of this as a capability deployed in a hurry to beat an anticipated patch, prioritising speed over stealth, and suggests it may reflect a falling cost of entry for this class of tooling as AI agents assist exploit development. The NCSC said something similar in May, when its chief technology officer warned organisations to prepare for a patch wave as AI accelerates flaw discovery. This is what the front of that wave looks like: less craftsmanship, more volume, and a willingness to burn a chain in a fortnight because another one is cheaper to make.

The commercial exposure for UK organisations

Regulatory. No UK organisation is named as a victim in either report, and the observed targeting was espionage against US, Vietnamese, Indonesian and Singaporean entities. That is not a reason to relax. The regulatory exposure is not the incident, it is the estate condition the incident exploited. The Windows builds the chain works on are, with one exception, out of mainstream support. An organisation running them in a browsing role is running a configuration that the ICO's Article 32 expectations, NIS2's vulnerability handling obligations for in-scope entities, and DORA's ICT risk requirements for financial firms would all struggle to describe as appropriate. The question a regulator asks after an incident is not whether Chrome had a patch on the day. It is why an unsupported operating system was on the desk of someone who opens email.

Financial. One of the observed payloads was built purely to steal credentials and sessions rather than to run commands. Volexity notes that JungleBamboo's browser extension, disguised as a Google Gemini tool, has no remote code execution at all: it logs keystrokes, harvests cookies and session tokens, and screenshots pages when they contain keywords the operator chooses. Stolen sessions turn into wire fraud, into mailbox rules, and into the kind of quiet access that surfaces months later as a supplier dispute or a regulatory notice. The cost is not the cleanup of the exploit. It is what an operator does with a finance director's live sessions in the weeks before anyone notices.

Contractual. Every managed service and outsourcing contract that promises patching within a fixed number of days from vendor release was honoured throughout this incident and protected no one, because for 27 days there was nothing to release. Buyers should read their supplier agreements for what they say about unsupported operating systems, browser update enforcement and extension control, and expect to find nothing. Those are the terms that would have mattered.

Governance. Boards have spent two years being told to fund patching cadence. This incident shows the limit of that investment: cadence is a measure of how fast you apply what you are given, and the exposure sat in the interval before anything was given. The governance question moves upstream. Which platform suppliers publish their fixes before they ship them, what is the organisation's exposure during that interval, and which controls do not depend on the supplier's release date at all.

What leaders should do now

1. Retire the Windows builds this chain runs on from any role that browses or reads email. The kernel stage works on Windows 10, Server 2019, Server 2022 and Windows 11 21H2. Windows 10 left mainstream support in October 2025. Set a date, fund it, and treat any exception as a risk acceptance signed by a named executive rather than an IT backlog item.
2. Make browser updates land, not just release. A released Chrome update protects nothing until the browser restarts. Enterprise policies exist to force relaunch within a set window; most organisations have not set one. Measure the actual time from Google's release to fleet-wide installed version, and report it monthly alongside server patch cadence.
3. Put browser extensions on an allowlist. One payload in this campaign was a malicious extension installed by tampering with Chrome's preferences file, a technique that bypasses the integrity checks Chromium added in November 2025 and June 2026 because a legacy fallback remains enabled by default. Managed browsers can block any extension not explicitly approved. This is a policy change, not a project.
4. Detect the shape, not the sample. The default chain has Chrome launch a command shell that runs curl and then executes what it downloaded. Ask the endpoint provider to confirm that a browser spawning a shell, a shell spawning curl, or a newly downloaded executable running from a temporary directory, would alert today. If the answer requires a new rule, that is a cheap afternoon.
5. Add the patch gap to the supplier risk register. For each platform the organisation depends on, record whether fixes are visible before they ship, how long the vendor's typical release interval is, and what compensating control covers that interval. Chromium is the obvious entry. It is not the only one.

Five decisions an executive can take that do not depend on a vendor's release date. Garzon Cyber Solutions, September 2026.

Three questions for the board

1. How many devices in this organisation run an operating system build that is out of mainstream support, and which of them are used by people who open email?
2. When Google released a Chrome security update on 3 September and again on 8 September, how many days did it take for 95% of our browsers to be running it, and who knows that number?
3. Which of our critical platforms publish their security fixes before they ship them, and what protects us during that interval?

The strategic takeaway

The reassuring version of this story is that Google and Microsoft have shipped patches, the kit is now detectable, and no UK victims are named. The accurate version is that a state-aligned adversary just showed it can turn a public bug fix into a shared, multi-campaign capability in under three weeks, and that the same model is likely to be repeated against any open platform with a release lag. Organisations that respond by tightening patch cadence are optimising the wrong interval. The ones that will be in a defensible position next time are those that decide, this quarter, which unsupported systems are no longer allowed near a browser, how fast a released update actually lands, and what watches the browser when the vendor cannot.

Confidence note

Confirmed. The three CVE identifiers are common to both reports. The 4 August report date is Volexity's. The 7 August commit, the 3 September stable release and the nearly four-week window are Proofpoint's. The 8 September Chrome 153.0.8010.36 release fixing CVE-2026-87491 and Google's statement that an exploit exists in the wild are from Google's stable channel advisory as reported by BleepingComputer. The 8 September Microsoft fix for CVE-2026-85880 is from Microsoft's Patch Tuesday release. CISA's addition of CVE-2026-87491 to the KEV catalogue is dated 9 September. The affected Windows builds, the default curl download behaviour and the extension installation technique are documented in both vendor reports. The NCSC patch wave warning is Ollie Whitehouse's blog of 1 May 2026.

Assessed. That the exploit developer reverse-engineered the public fix is Volexity's medium-confidence assessment and Proofpoint's "likely". That the chain was sold or supplied to multiple end users is Volexity's low-confidence assessment. AI-assisted development is a hypothesis Proofpoint supports with indicators and explicitly does not confirm. Attribution of TA412, JungleBamboo, UTA0560, UNK_LateNight and UNK_QuietRacket to China-aligned espionage is the two firms' own; UNK_DoubleCheck is unattributed. Proofpoint's expectation that the kit will spread to financially motivated actors is a forecast, not an observation.

Scope. Proofpoint names four clusters. Volexity names two, one of which (JungleBamboo) is Proofpoint's TA412 and one of which (UTA0560) Proofpoint does not list. Across the two reports that is five named clusters, and that is the figure we use; BleepingComputer's count of four omits UNK_QuietRacket. The six-day adoption window runs from Proofpoint's first TA412 observation on 28 August to its first UNK_QuietRacket observation on 3 September. Neither report gives a victim count, and neither names a UK or European target. The 27-day figure is our calculation from the two dates Proofpoint states.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and Americas. We are a young firm and we publish our own research. Founded by Jonathan Garzon, whose career was spent selling cybersecurity, compliance and technology to security and technology buyers.