Volexity attributed a spear-phishing campaign against multiple non-governmental organizations on September 1, 2026 to a Chinese threat cluster it tracks as UTA0560, which chained three vulnerabilities in Google Chrome and Microsoft Windows to install a JavaScript backdoor called GRIMWEDGE. The emails asked recipients to click a link to a legitimate U.S.-based university website.

That link abused a reflected cross-site scripting flaw on the university site, which bounced visitors to threat-actor infrastructure hosting the exploit chain. If your staff hover over a link and see a recognized .edu domain, the destination looks safe. The redirect happens after the click.

The chain, referred to as BlueMoon, uses three separate flaws in sequence:

• CVE-2026-85046 to gain arbitrary read/write inside the Chrome V8 sandbox
• CVE-2026-87491 to escape the browser sandbox
• CVE-2026-85880, a Windows Advanced Local Procedure Call flaw, to inject code into the Chrome process and run arbitrary code

The exploit page only fires against systems browsing with Chrome on Windows, filtering out everything else. The end result is code execution on the endpoint from a single click, with no attachment to scan and no macro to block.

Volexity also observed a second China-nexus actor, JungleBamboo (also tracked as APT31), running the same chain in the same period to drop a loader named SUPERSTOMP, which installs LONGTALE, a credential-stealing Chrome extension also known as GemStone.

Two separate state-linked groups using an identical chain within days suggests the exploit was sold or shared by its developer. That matters for your risk assessment because commodity crimeware reuses known bugs, while this activity targeted NGOs with unpatched flaws and a reconnaissance-focused implant built for quiet file retrieval.

The Chrome fixes had landed in the open-source Chromium codebase but had not yet shipped in a stable Chrome release, so they functioned as zero-days against Chrome users at the time of the attacks.

Inside the Exploit Chain: From Chrome Renderer to Kernel Access

The chain, which Proofpoint documented under the name BlueMoon, runs three bugs in sequence, and each one solves a specific containment problem for the attacker. The first, CVE-2026-85046, gives arbitrary read and write access inside the V8 sandbox, the memory boundary Chrome uses to limit what JavaScript can touch. That alone yields code execution in the renderer process, which is still walled off from the rest of the machine.

Step two, CVE-2026-87491, breaks that wall by escaping the browser sandbox. Step three uses CVE-2026-85880, a flaw in the Windows Advanced Local Procedure Call (ALPC) subsystem, to inject code into the Chrome browser process and reach arbitrary code execution on the host. At that point the attacker is running with the privileges of the user who clicked, and everything that user can read, the attacker can read.

The exploit page is selective. It fingerprints the visitor and filters out anything that is not Chrome on Windows, so analysts opening the URL in a different browser or on a sandboxed non-Windows VM see nothing. That behaviour also means a single test from an unusual client will not reproduce the attack, which complicates after-the-fact triage of proxy logs.

The page carries three binary payloads as Base64 strings embedded directly in JavaScript:

• p1: shellcode that reflectively loads a DLL for host reconnaissance and fingerprinting
• p2: shellcode that reflectively loads a DLL handling Windows kernel privilege escalation
• pp: shellcode for browser process injection and payload download

Reflective loading (mapping a DLL into memory without writing it to disk) means the recon and escalation stages leave no file for disk-based scanning to catch.

The next stage lands as msgbox.exe, a loader that unpacks two things from itself: a legitimate signed Windows binary and a malicious DLL named wsc.dll. The legitimate binary is then launched so it loads the attacker's DLL from the same directory, classic side-loading (T1574.002). Process lineage is the tell here, since a signed Microsoft binary running from a user-writable path with an unexpected parent is not normal behaviour.

wsc.dll calls back to the same server and requests a text file named after the device's hostname, a value harvested during the earlier profiling step. The file is not text. It is an MSI installer whose custom actions execute an obfuscated JavaScript backdoor, which puts msiexec.exe in the execution chain (T1218.007) and keeps the payload inside a signed installer workflow that many environments treat as routine software deployment.

That backdoor is GRIMWEDGE. It runs a persistent polling loop against the command-and-control server at ocr.opusaccel[.]top, receiving instructions that execute in memory through eval(). Its command set covers Info, Dir, Mkdir, Del, Tasklist, Taskkill, Type (reads files up to 5 MB), Run (executes commands in a hidden window), and chunked Upload operations that assemble a Base64 buffer in memory before writing the finished file to disk.

"The code has no built-in persistence, lateral movement, or exfiltration mechanism beyond the file-read and upload commands," Volexity's researchers wrote, describing GRIMWEDGE as a foothold sufficient to survey the host, retrieve files of interest, and deploy further tooling.

Volexity separately confirmed a second China-nexus actor, JungleBamboo (APT31), running the same chain to drop the SUPERSTOMP loader and the LONGTALE credential-stealing Chrome extension. The assessment that the chain was sold or shared by its developer is stated as a possibility, not a confirmed finding.

The Broader APT31 Toolkit: BlueMoon, GemStone, LONGTALE and SUPERSTOMP

The BlueMoon exploit page does not drop a single payload. It embeds three Base64-encoded binary blobs inside the JavaScript, each with a narrow job: p1 is shellcode that reflectively loads a DLL for host reconnaissance and fingerprinting, p2 reflectively loads a DLL that handles Windows kernel privilege escalation, and pp performs the browser process injection and pulls down the next stage. Splitting the work this way keeps each component small and lets the operator swap the final payload without touching the exploit code.

That modularity is what allowed two separate Chinese clusters to run the same chain with different endgames. UTA0560 fetched msgbox.exe, a loader that unpacks a legitimate signed Windows binary plus a malicious wsc.dll from itself and starts a DLL sideloading chain (MITRE T1574.002). The sideloaded DLL then requests a text file from the same server, named after the hostname the profiling stage collected earlier, so the operator controls exactly which machines receive a payload and which get nothing.

The file that comes back is an MSI installer, and the backdoor lives in its custom actions (T1218.007, Msiexec execution). GRIMWEDGE itself is obfuscated JavaScript that runs a polling loop against ocr.opusaccel[.]top and executes tasking in memory through eval(). Its command set is deliberately small:

• Info, Dir, Tasklist for host and process survey (T1082, T1057, T1083)
• Mkdir, Del, Type for file management, with reads capped at 5 MB
• Run to execute commands in a hidden window
• Upload (chunk) and Upload (commit), which assemble a Base64 stream in memory before writing the completed file to disk

Volexity noted the code carries no built-in persistence, no lateral movement, and no exfiltration path beyond file read and upload. That is a design choice rather than an oversight. GRIMWEDGE is a foothold for triage, and the Run and Upload pair is how heavier tooling arrives once the operator decides a host is worth the investment. For defenders, the practical consequence is that the first-stage implant leaves a thin footprint, and the interesting activity happens in whatever second-stage tooling follows.

The second cluster, JungleBamboo (tracked elsewhere as APT31), used the identical chain in the same period but delivered a loader called SUPERSTOMP, which installs LONGTALE, a credential-stealing Chrome extension also reported as GemStone. It poses as a Google Gemini extension under ID ckiknalbeplpcpofpnabcnhjcegckfei (T1176, browser extension persistence). LONGTALE logs keystrokes and form input, lifts cookies and session tokens, captures screenshots when page content matches C2-supplied keywords, and ships keystrokes, cookies, storage data, navigation history, and session metadata upstream at roughly 30-second intervals.

Stolen session cookies matter more than stolen passwords in most environments, because a valid session token bypasses the MFA prompt entirely and gives the operator access to your webmail and cloud apps as the user (T1539). LONGTALE has no remote code execution command at all. Volexity assessed the operator likely considered it unnecessary given how much the extension already collects, which points at sustained surveillance of specific people rather than broad network compromise.

Two distinct actors running the same three-bug chain within days suggests a shared supplier. The likely explanation is an exploit developer who reverse-engineered the Chromium source changes and sold or distributed the working chain. Combined with NGO targeting and tooling built around document retrieval, credential theft, and account session access, the intelligence objective reads as monitoring of staff communications and contacts.

What Zero-Day Exploitation by a State-Linked Actor Means for Affected Organisations

Your patching process was not the weak point in this campaign. The fixes for the two Chrome flaws had already landed in the open-source Chromium code, but they had not been rolled into a stable Chrome release, so a browser that reported itself fully up to date was still exploitable. Volexity describes this as a patch gap, and it turned two N-day bugs into working zero-days against every Chrome user on Windows.

That matters for how you talk about risk with your board. Until last week Chrome shipped major milestone releases on a four-week cycle, now shortened to two weeks, and the window between an upstream code change and a stable release is exactly where this activity fits. If your assurance reporting says "100 percent of endpoints on the latest browser version," that metric did not protect anyone here.

The access the attacker gained is narrow and deliberate. GRIMWEDGE supports directory listings, process enumeration, file reads up to 5 MB, command execution in a hidden window, and chunked file upload. Volexity notes it has no built-in persistence, lateral movement, or exfiltration beyond the file-read and upload commands, which tells you the objective is to survey the host, pull specific documents, and stage additional tooling.

That shape of intrusion is quiet. Nothing encrypts, nothing breaks, and your users see no disruption to their day. The backdoor runs as obfuscated JavaScript executed in memory through eval(), so the artefacts your investigators would normally rely on may not survive a reboot. Scoping questions your regulators and funders will ask, such as which files left the building and when, become genuinely hard to answer.

The parallel JungleBamboo activity shows the collection side of the same access. LONGTALE poses as a Google Gemini Chrome extension and performs keylogging and form capture, cookie and session theft, and screenshot capture triggered by keywords the operator supplies, then ships keystrokes, cookies, storage data, navigation history and session metadata to its C2 roughly every 30 seconds. Stolen session cookies let an attacker reuse an already authenticated session to your webmail, grant portals and cloud file stores, which means account access without a password reset event to alert you.

The targets were non-governmental organisations, and the exposure inside that kind of body concentrates in a few roles. Programme and research staff hold beneficiary lists, field contacts and partner correspondence. Grants and finance staff hold contract terms and funder reporting. IT administrators hold browser sessions to consoles that govern everything else. If your organisation handles data on individuals in sensitive regions, the harm from that correspondence leaking is not financial in the first instance.

Your compliance exposure follows the data classes involved. Personal data on staff, donors or beneficiaries in scope of a file-read and upload sequence puts you into breach-notification territory under applicable privacy law, and the burden falls on you to show what was accessed. Where you hold controlled or contract-restricted information under a government grant, reporting obligations to the awarding body are usually contractual and shorter than statutory deadlines.

There is a third-party dimension too. The redirect abused a reflected cross-site scripting flaw on a legitimate U.S. university website, so an organisation that was never the intended target still had its domain used to lend credibility to the lure. Partners who received traffic through that domain will ask questions, and answering them takes staff time and legal review.

Patching, Hunting and Containment Steps for CVE-2026-85046, CVE-2026-85880 and CVE-2026-87491

Force the Chrome update first, and confirm it actually applied. Chrome downloads a new build in the background but only swaps it in on relaunch, so a fleet that shows the patched version in your software inventory can still be running the vulnerable binary in long-lived browser sessions. Check chrome://version on a sample of hosts, push a forced relaunch through your browser management policy, and repeat the check on contractor and BYOD machines that your patch tooling does not touch.

Apply the Windows update that fixes the ALPC flaw on the same pass. The privilege escalation step is what turns a browser compromise into kernel-level access, so an endpoint patched for Chrome but not Windows still gives an operator most of what the chain was built to deliver.

Then block and hunt. Sinkhole or deny ocr.opusaccel[.]top at your DNS resolver and web proxy, and search historical proxy and DNS logs back to at least late August 2026 for any resolution of that domain. Alongside that, look for:

• msgbox.exe on disk or in execution telemetry, and any wsc.dll loaded from a directory a user can write to.
• HTTP requests where the requested filename matches a local hostname, which is how the second stage retrieves its MSI.
• msiexec.exe running with custom actions that spawn a script interpreter, rather than installing software your change records account for.
• Chrome extension inventory containing ID ckiknalbeplpcpofpnabcnhjcegckfei, which impersonates a Google Gemini extension.

If you find any of those artefacts, do not reboot the host. GRIMWEDGE has no built-in persistence and runs its command loop in memory, so a restart destroys the best evidence you have and tells you nothing about what was taken. Isolate the machine at the network layer, capture a memory image, then escalate to your incident response contact with the collected proxy logs attached.

Over the next few weeks, run targeted hunts on process lineage from browser processes. Any non-renderer child of a Chrome process, or any injected thread inside one, deserves a look. In environments Capstone manages, SentinelOne provides the process ancestry and in-memory injection telemetry these hunts depend on, and the same telemetry surfaces attempts to disable endpoint protection once the kernel escalation step succeeds. Confirm tamper protection is enabled on every agent, since an operator with kernel access will try to turn the agent off before staging further tooling.

Check how far back your EDR telemetry actually goes. If retention is 14 or 30 days and the campaign activity predates that window, your hunt has a blind spot you should document rather than treat as a clean result. On any host you suspect, assume browser-stored credentials, cookies, and session tokens are gone: invalidate sessions centrally, rotate the passwords behind them, and review privileged account activity for logins that follow the suspected compromise date.

For the longer term, reduce what the browser can reach. Set an extension allowlist by ID so unapproved extensions cannot install, keep site isolation enforced, and apply application control rules (WDAC or AppLocker) that block DLL loading from user-writable paths, which is the condition the sideloading chain depends on. Finish with an assumed-breach exercise that starts from a compromised browser process and measures whether your team detects the sideload and the outbound poll, not whether the initial link was blocked.

Priorities for the Next Reporting Cycle

The one action that matters from this campaign is confirmation, not effort. Verify that the fixes for CVE-2026-85046, CVE-2026-87491 and CVE-2026-85880 are actually live on every Windows host running Chrome, then look backwards for signs of exploitation dated before those fixes reached your fleet. The exposure window opened when the Chromium commits landed, so activity predating your patch record is in scope.

Current reporting leaves real gaps you should track. Volexity has not published the number of NGOs affected, and the follow-on tooling UTA0560 delivered through the backdoor's Run and Upload commands is not documented, which means the deepest part of these intrusions is still unmapped. GRIMWEDGE itself carries no persistence, lateral movement or exfiltration beyond reading and uploading files, so what an operator did after establishing that foothold determines your actual loss.

The attribution question also stays open. Two separate China-nexus clusters ran the same chain within days of each other, and Volexity raises the possibility that a single exploit developer sold or supplied it after reverse-engineering the Chromium source changes. If that holds, expect other customers of the same developer to surface in later reporting with different final payloads.

Volexity's closing point is the one worth carrying into your next risk review: patch-gap bugs create an extra exploitation window, and the researchers expect that window to be used faster as large language models improve at vulnerability research and exploit development. Watch for updated indicators as Volexity and Proofpoint publish further analysis, and reassess whether your browser update path depends on a vendor release cycle you do not control.