Google has patched a high-severity Chrome zero-day, CVE-2025-2783, that was exploited to escape the browser's sandbox during an espionage campaign against Russian media outlets and education organizations. Kaspersky researchers who discovered the flaw describe it as an "incorrect handle provided in unspecified circumstances in Mojo on Windows," and they link the exploit chain to a phishing operation they call Operation ForumTroll. Fixed Windows builds are 134.0.6998.178 in the Stable Desktop channel, and Google says technical details will remain restricted until most users have updated.
What Google disclosed
The fix arrived in a security advisory published Tuesday. In it, Google confirmed that an exploit for CVE-2025-2783 exists in the wild, but the company did not publish specifics about the attacks themselves. Instead, it said that "access to bug details and links may be kept restricted until a majority of users are updated with a fix," a standard delay meant to limit reverse engineering while the installed base catches up.
The patched build for Windows is 134.0.6998.178. Google describes the rollout as staged, arriving over days and weeks, though the update was already being served when BleepingComputer checked. Users who do not want to wait for the automatic check can open the Chrome menu, go to Help, then About Google Chrome, and restart the browser once the download completes. Chrome also checks for updates on its own and applies them at the next launch, so simply restarting the browser periodically is usually enough.
This is the first Chrome zero-day patched since the start of 2025. In the preceding year, Google fixed 10 zero-days that were either exploited in real attacks or demonstrated during the Pwn2Own hacking contest, a pace that has made browser sandbox escapes a recurring concern for defenders.
How Operation ForumTroll chains the exploits
Kaspersky's Boris Larin and Igor Kuznetsov traced the attacks to spear-phishing messages that posed as invitations from the organizers of a scientific and expert forum called "Primakov Readings." The emails targeted media outlets, educational institutions, and government organizations in Russia, and the campaign name Operation ForumTroll comes directly from that lure.
Victims who followed the links were redirected to primakovreadings[.]info, a lookalike domain built to resemble the legitimate event. From there, the attack relied on two separate exploits: CVE-2025-2783 to break out of Chrome's sandbox, and a second exploit that provided remote code execution on the compromised machine. Kaspersky has not released details about that second component, and no CVE has been attached to it in the published material.
What makes CVE-2025-2783 notable is how little the exploit appeared to do. The researchers said the bug initially baffled them because, without any obviously malicious or forbidden action, it let attackers bypass Chrome's sandbox protection as though it did not exist. The end product was sophisticated malware, and Kaspersky assesses the objective as espionage based on its functionality, though the investigation is still ongoing.
Because the sandbox escape is the gateway for the rest of the chain, installing the updated build removes the attackers' entry point. Google's patch therefore disables the full exploit sequence, even though the second RCE flaw remains undocumented publicly.
Technical background: why Mojo handle bugs matter
Chrome's sandbox depends on process separation. The renderer, which parses untrusted web content, runs with severely restricted privileges, while a more privileged browser process performs operations such as file access and network activity. The two sides communicate through Mojo, Chrome's inter-process communication system, which passes messages and operating-system handles between processes.
On Windows, those handles are kernel objects, and the broker process is responsible for duplicating and validating them before they reach a privileged context. When a handle is supplied incorrectly, a compromised renderer may be able to reference an object it should never have been granted, effectively turning a low-privilege IPC message into privileged access. Bugs of this class are especially dangerous because they can be triggered through ordinary browsing, and because the renderer is the component an attacker already controls after a separate memory-corruption compromise.
The public description of CVE-2025-2783 stops at "incorrect handle provided in unspecified circumstances in Mojo on Windows." No root-cause write-up, crash sample, or proof-of-concept has been released, and this post does not speculate about the exact handle type or code path involved.
Detection and mitigation
The primary mitigation is straightforward: confirm that every managed and unmanaged Windows endpoint is running 134.0.6998.178 or later. The following checks are generic verification steps rather than indicators published for this campaign.
(Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion
Get-ChildItem "C:\Program Files\Google\Chrome\Application" -Directory |
Select-Object -ExpandProperty Name
Inside the browser, chrome://version reports the full version string, and chrome://settings/help triggers an update check. For fleets, use the enterprise update controls already in place and verify compliance through your software inventory rather than relying on user-initiated updates.
On the network side, alert on or block DNS lookups and HTTP requests to primakovreadings[.]info, and review mail logs for messages referencing Primakov Readings sent to media, education, or government recipients. On the endpoint, look for chrome.exe spawning unexpected child processes or writing executables outside its normal update paths, which is consistent with a sandbox escape handing off to a second-stage payload. Because the RCE component is undocumented, behavioral detection around browser process trees is more reliable than signature matching.
Finally, treat the phishing lure as the earliest observable stage. Mail filtering that inspects intent and context, rather than only attachments and known-bad URLs, is the layer most likely to catch this chain before Chrome is ever reached.