China-linked hackers chained two Chrome bugs and a Windows flaw to plant a backdoor on NGOs
Volexity found a three-bug chain, BlueMoon, that went from a phishing link to code running outside the browser sandbox, in the gap between an upstream Chromium fix and the stable Chrome release.
A China-linked threat actor exploited a chain of two Google Chrome vulnerabilities and one Windows flaw to compromise non-governmental organisations, according to a report by The Hacker News on 15 September 2026. Researchers at Volexity, who track the actor as UTA0560, said the campaign began on 1 September 2026 with spear-phishing emails that linked to a compromised university website. Visiting the page with a vulnerable browser triggered an exploit chain the researchers named BlueMoon.
The chain used three vulnerabilities in sequence. CVE-2026-85046 gave the attackers arbitrary read and write inside Chrome's V8 JavaScript engine sandbox. CVE-2026-87491 then escaped the browser sandbox. Finally CVE-2026-85880, a flaw in the Windows Advanced Local Procedure Call facility, was used to inject code into the Chrome process. The result was a JavaScript backdoor Volexity calls GRIMWEDGE, which supports host reconnaissance, file and process management, command execution and payload delivery through a small command set including Info, Dir, Mkdir, Del, Tasklist, Taskkill, Type, Run and a chunked Upload. It communicated with a command-and-control server at ocr.opusaccel[.]top and had no built-in persistence, lateral movement or exfiltration capability beyond file operations.
Volexity also observed a second China-nexus group, JungleBamboo, also known as APT31, deploying a different payload named LONGTALE, or GemStone. That implant masqueraded as a Google Gemini Chrome extension and performed keylogging, form capture, cookie and session theft and screenshots, exfiltrating data in bulk roughly every 30 seconds.
According to the report, patches for the Chromium bugs existed upstream but had not yet reached the stable Chrome release, and the browser's four-week release cycle created the window in which the exploitation occurred. The research was credited to Ankur Saini, Conor Quigley, Sean Koessel, Steven Adair and Tom Lancaster of Volexity.
Why it matters
Browser exploit chains of this kind are expensive to build and are usually reserved for high-value espionage targets, which is exactly what NGOs working on sensitive issues are to state-aligned groups. The more instructive detail is the timing: the bugs were already fixed in the open-source Chromium code but had not yet shipped to users, and attackers read upstream commits too. For defenders this removes the comfortable assumption that "patched upstream" means "safe". It puts real weight on how quickly browser updates actually reach the machines in your organisation, and on what an attacker can do from inside a browser once they are there.
Spear-phishing email
Targets at NGOs receive a link to a compromised university website.
V8 memory bug (CVE-2026-85046)
Arbitrary read and write inside Chrome's JavaScript engine sandbox.
Sandbox escape (CVE-2026-87491)
Attacker code breaks out of the browser sandbox.
Windows ALPC flaw (CVE-2026-85880)
Used to inject code into the Chrome process.
GRIMWEDGE backdoor
Recon, file and process control, command execution and payload delivery via ocr.opusaccel[.]top.
What you can learn from this
- Sandboxes are layers, and an exploit chain peels them one at a time. Modern Chrome runs JavaScript inside the V8 sandbox, which lives inside a renderer process, which is confined by the operating system sandbox. Each layer assumes the one inside it may already be compromised. BlueMoon needed one bug per layer: a V8 memory primitive to control the renderer, a sandbox escape to reach the wider system, and a Windows flaw to move code into a trusted process. That is why a single browser bug is rarely enough on its own, and why defence in depth genuinely works: it raises the price of an attack from one vulnerability to three.
- Arbitrary read and write is the currency of memory exploitation. CVE-2026-85046 gave the attackers the ability to read and write memory inside the V8 sandbox at will. That primitive is powerful because once you can corrupt the right data structure, such as a function pointer or an object's type information, you can redirect execution to code of your choosing. JavaScript engines are prime targets because they perform just-in-time compilation, turning attacker-supplied scripts into machine code under complex assumptions that occasionally break.
- Inter-process communication is attack surface too. ALPC is a Windows mechanism that lets processes send messages to one another. Facilities like this exist so that sandboxed processes can ask more privileged components to do things on their behalf, and the receiving side is supposed to validate every request. When that validation fails, the sandbox boundary is only as strong as the weakest message handler. The same lesson applies to any IPC surface, including browser extension messaging and mobile app intents.
- The release pipeline is part of your attack window. Open-source projects fix bugs in public. Anyone can diff the Chromium repository, spot a security-relevant change, and work backwards to a working exploit before the fix reaches users. The industry calls this patch-gapping. Vendors answer with faster release cadences and out-of-band updates, but the window never fully closes, so the defensive question becomes how quickly your fleet moves from "update available" to "update applied".
- Malicious extensions are a theft layer of their own. LONGTALE posed as a Gemini extension and harvested keystrokes, form contents, cookies and screenshots. Extensions run with broad access to every page you visit, and a stolen session cookie lets an attacker act as you without ever seeing your password or your MFA prompt. That is why extension allow-listing and short session lifetimes are meaningful controls rather than tidiness.
We teach this
How to use this in practice
- Measure how fast Chrome actually updates on your machine. Open chrome://version and compare it with the current stable release on the Chrome Releases blog, then check chrome://policy to see whether updates are managed. Done looks like knowing, in days, the gap between a Chrome release and the version on your desk, and knowing who controls it. If you manage other people's machines, pull that number for the whole fleet.
- Audit your extensions in ten minutes. Visit chrome://extensions and for every entry ask three questions: do I remember installing it, is the publisher who I think it is, and what permissions does it hold. Remove anything that fails. LONGTALE impersonated a well-known brand, so a familiar name is not evidence. Done looks like a shorter list where you can justify every item.
- Read one real exploit chain write-up end to end. Pick a published Chrome exploit analysis from Google Project Zero or a similar research team and trace the chain step by step: which bug gives which primitive, and how each primitive enables the next. Write a one-paragraph summary in your own words. Done looks like being able to explain to a colleague why a sandbox escape is a separate bug from a renderer bug.
- Practise reading a diff for security intent. Open the Chromium repository or another large open-source project, find a recent commit labelled as a security fix, and work out what input the change now rejects. You are not writing an exploit; you are learning how attackers read patches. Done looks like a two-sentence note naming the bug class the fix addresses.
Sources
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report