Google Fixed 230 Chrome Bugs. One Was Already in Attackers’ Hands.
Google fixed 230 security issues in Chrome 153. One sentence in the release notes matters more than the size of that list: an exploit for CVE-2026-87491 exists in the wild.
The vulnerability is an out-of-bounds write in V8, the JavaScript and WebAssembly engine inside Chrome. Google’s initial record said a remote attacker could trigger arbitrary code execution through a crafted HTML page. Proofpoint and Volexity now describe CVE-2026-87491 more specifically as the V8 sandbox-escape stage used after a separate type-confusion flaw had established read and write capability inside V8.
Google rates the issue Medium in its Chromium security table. That label should not be confused with operational priority. Confirmed exploitation means an attacker has already moved from theory to a working attack path, even while technical details remain restricted.
BlueMoon Chained the Chrome Zero-Days Into a Full Windows Compromise
Update, 11 September 2026: Proofpoint and Volexity have now documented the campaign that Google’s Chrome notice did not describe. The vulnerability covered in this article was one link in BlueMoon, an exploit chain that combined two V8 flaws with a Windows kernel vulnerability to move from a phishing link to code running outside the Chrome renderer sandbox.
The chain began with CVE-2026-85046, a V8 type-confusion flaw used to gain arbitrary read and write capability inside V8’s heap cage. It then used CVE-2026-87491, the out-of-bounds write covered in this article, to escape the V8 sandbox through WebAssembly metadata corruption. Finally, CVE-2026-85880 exploited the Windows kernel to elevate the renderer process and enable code injection into the parent browser process. From there, the operator could download and execute a chosen payload.
Proofpoint says it first observed the China-aligned group TA412, also tracked as JungleBamboo, Violet Typhoon and APT31, using BlueMoon on 28 August. Three more espionage-focused clusters adopted the same underlying kit within days:
- UNK_LateNight, assessed by Proofpoint as China-aligned, targeted US aerospace companies and delivered ShadowPad.
- UNK_DoubleCheck, not attributed by Proofpoint to a country, targeted a Vietnamese manufacturing organisation and delivered a Rust-based loader chain.
- UNK_QuietRacket, assessed by Proofpoint as suspected China-aligned, targeted government, consulting and financial organisations in Indonesia and Singapore.
Volexity independently documented the same exploitation chain in activity by UTA0560 and JungleBamboo. It reported byte-for-byte identical shellcode but different infrastructure and post-exploitation malware. Volexity assessed with low confidence that the exploit chain may have been sold or otherwise supplied to different users in China. Proofpoint says it is not known how the distinct actors obtained the kit and cautions that its use may not be exclusive to China-aligned groups.
The Windows stage narrows the systems on which the complete chain can succeed. Proofpoint lists Windows build 17763, builds 19041 through 19045, build 20348 and build 22000, covering Windows 10 1809 through 22H2, Windows Server 2019, Windows Server 2022 and the initial Windows 11 21H2 release. Volexity says builds above 22000 are rejected by the kernel-exploit stage. A newer Windows build therefore reduces exposure to this observed full chain, but it does not remove the need to patch the Chrome vulnerabilities.
BlueMoon also exposes the risk created by the gap between an open-source fix and a downstream browser release. Proofpoint says the fix for CVE-2026-85046 entered the public Chromium source on 7 August but did not reach the general stable build until 3 September. The researchers assess that the public patch likely helped the exploit developer weaponise the flaw before users had a stable Chrome update.
The rapid development history and verbose diagnostic material have prompted an AI question, but the evidence stops short of an answer. Proofpoint found extensive logging, comments documenting successive debugging decisions and a reference to a Markdown handover file. It says those artefacts are consistent with AI-assisted development, while explicitly stating that no single artefact proves it. Volexity discusses the broader way language models can increase patch-gap risk but does not establish that AI built BlueMoon.
For defenders, the update changes the incident-response scope. Updating and relaunching Chrome remains essential, but Windows must also contain the fix for CVE-2026-85880. Proofpoint recommends hunting for a default process chain in which chrome.exe starts cmd.exe, which starts curl.exe and then msgbox.exe; scheduled tasks named EdgeCore_AutoUpdate, MicrosoftEdgeUpdatesTaskMachine or Avpcheckup; the v8ctf_exp_attempt session-storage key; and ChromeUpdate.exe or msgbox.exe in %TEMP%. These indicators are useful leads, not proof that every BlueMoon deployment uses the default names.
Proofpoint also documented a malicious Chromium extension called GemStone in TA412 activity. It masqueraded as a Google Gemini companion and could collect cookies, keystrokes, browser storage, session metadata and screenshots. The payload varied between actors, so a hunt limited to that extension would miss other BlueMoon infections.
The severity label does not describe the whole risk
Security teams often use severity scores to decide which patches enter the next change window. That works when two vulnerabilities have similar exposure and exploitation evidence. It becomes less useful when one of them is already being used.
An out-of-bounds write allows software to place data outside the memory area intended for it. In a JavaScript engine, that can become a route from hostile web content to attacker-controlled code execution inside the renderer sandbox. Google’s release did not describe the attacks, their targets or the accompanying vulnerabilities. Proofpoint and Volexity supplied those campaign details on 9 September, as summarised in the dated update above.
The new research changes the documented chain without changing the evidence boundary around each vulnerability. CVE-2026-85046 established the initial V8 read and write primitives, CVE-2026-87491 escaped the V8 sandbox, and CVE-2026-85880 elevated the Windows process. The full compromise depended on the chain, a supported older Windows build and a target opening the exploit link. It remains inaccurate to attribute the complete Windows takeover to one Chrome flaw alone.
Chrome 153 is the new security baseline
Google released Chrome 153.0.8010.36 for Linux and 153.0.8010.36 or 153.0.8010.37 for Windows and macOS. The rollout is staged, so an available update can appear at different times across devices and managed environments.
The Android release is version 153.0.8010.36. Google says Android releases contain the same security fixes as the corresponding desktop release unless it states otherwise. Other Chromium-based browsers depend on the same upstream engine, but their fixed build numbers and release timing are controlled by their own vendors.
Administrators should verify the version reported by the running browser rather than assuming an update policy has completed. Chrome normally shows the installed version at chrome://settings/help. Enterprise teams can use browser-management reporting, software inventory or endpoint telemetry to identify devices that remain below the fixed line.
A browser restart is part of the patch
Downloading a Chrome update does not necessarily replace every running browser process immediately. Users may leave sessions open for days, while the corrected build waits for a restart.
That creates a familiar measurement problem. A management console may show that a package was delivered while the endpoint is still running the older code. Organisations with managed Chrome deployments should set an appropriate relaunch deadline, warn users before closing sessions and then confirm the version after relaunch.
Remote workers, test devices, shared workstations and rarely used laptops deserve particular attention. They often miss the first compliance snapshot because they were offline when the update was offered.
What defenders should do now
- Update Chrome to 153.0.8010.36 or later on Linux and to the fixed 153.0.8010.36 or 153.0.8010.37 line on Windows and macOS.
- Update Chrome for Android to version 153.0.8010.36 or later as it becomes available.
- Require a browser relaunch within a business-appropriate deadline and verify the version after restart.
- Check other Chromium-based browsers for their own vendor releases. Do not assume the Chrome version number applies to them.
- Identify unmanaged browsers and portable installations that may sit outside normal software deployment.
- Prioritise devices used for privileged administration, finance, development and access to sensitive cloud services.
- Do not wait for public exploit details before completing the update. Google may restrict bug information until a majority of users are protected.
- Install the Microsoft update for CVE-2026-85880, especially on Windows 10 1809 through 22H2, Server 2019, Server 2022 and Windows 11 21H2 systems identified in the observed chain.
- Hunt for the BlueMoon process, file, task and browser-storage indicators published by Proofpoint, while allowing for actor-specific payload and naming changes.
Google’s notice did not identify a campaign, actor, target sector or exploit chain. Proofpoint and Volexity now attribute specific observed activity and payloads to the clusters described above. Their assessments do not establish that every use of CVE-2026-87491 belongs to BlueMoon, that every BlueMoon user is China-aligned or that artificial intelligence developed the kit.
The useful conclusion is narrower and more urgent. A working exploit exists, vulnerable browsers routinely process untrusted content and the fixed build is available. That is enough to make version verification a current defensive task.
Sources
- Google Chrome Releases: Stable Channel Update for Desktop, published 8 September 2026 at 14:24:50 PDT, 23:24:50 CEST. Updated 8 September at 16:59:42 PDT, 9 September at 01:59:42 CEST.
- Official CVE record, published 9 September 2026 at 00:09:38 UTC and updated at 10:29:23 UTC.
- BleepingComputer: Google patches seventh Chrome zero-day exploited in attacks this year, published 9 September 2026 at 02:25 as displayed. The page does not state a timezone.
- Proofpoint: Once in a BlueMoon, published 9 September 2026. No publication time was provided.
- Volexity: Mind the Patch Gap, published 9 September 2026. No publication time was provided.


