CVE-2026-125350: Chrome XML Zero-Day Exploited in the Wild

Google has released an emergency security update addressing CVE-2026-125350, a high-severity zero-day vulnerability in the XML component of Google Chrome that is already being exploited in real-world attacks. The issue is classified as a use-after-free memory-safety flaw and was reported anonymously to Google on November 6, 2026.

Google confirmed on November 9 that an exploit for the vulnerability exists in the wild. However, the company has not disclosed how attackers are delivering the exploit, which organizations or individuals are being targeted, or whether the vulnerability is being chained with additional browser or sandbox escape flaws. Access to the underlying Chromium bug remains restricted while users deploy the security update.

The fix is included in Chrome Stable 157.0.8103.50/.51 for Windows and macOS and 157.0.8103.50 for Linux. Google also released Extended Stable 156.0.8078.96 for Windows and macOS with a fix for the same vulnerability.

Contact Sales

CVE-2026-125350 is the eighth Chrome zero-day known to have been exploited in the wild during 2026, following CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, CVE-2026-11645, CVE-2026-85046, and CVE-2026-87491. As of November 10, SecurityWeek reports that CISA has not yet added the newly disclosed flaw to its Known Exploited Vulnerabilities catalog.

Use-after-free vulnerabilities occur when software continues referencing memory after that memory has been released. Depending on the affected code and exploitation technique, such memory corruption can potentially result in browser crashes, data corruption, or attacker-controlled code execution. Google has not disclosed the exact impact achieved in the observed attacks, so defenders should avoid assuming that a publicly documented full system compromise chain already exists.

Security teams can use SOC Prime’s AI-Native Detection Intelligence Platform to strengthen detection coverage against browser exploitation, suspicious child processes, payload execution, and follow-on attacker behavior across SIEM, EDR, XDR, and Data Lake environments.

Detect CVE-2026-125350 by combining browser version inventory with endpoint and network telemetry, monitoring for suspicious processes launched by Chrome, abnormal browser crashes, unexpected payload downloads, and post-exploitation behavior occurring after visits to potentially malicious websites.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-125350 analysis

CVE-2026-125350 affects vulnerable Google Chrome releases containing the use-after-free condition in the browser’s XML component. Google rates the vulnerability High severity but has not published a CVSS score or vector in its November 9 advisory.

A use-after-free occurs when memory is released but software later attempts to access the same memory location. If an attacker can influence the contents subsequently placed in that memory, the stale reference can potentially be manipulated to alter program behavior.

In a web browser, memory-safety vulnerabilities are particularly important because attacker-controlled content is routinely processed by complex browser components. However, Google has not yet disclosed the exact XML object involved, the sequence required to trigger the bug, or the specific web content used by attackers.

The Chromium issue associated with the vulnerability is currently restricted. Google routinely limits access to technical bug details until a majority of users have received the patch, and restrictions can remain longer when a flaw also exists in third-party software.

As a result, several important technical details remain unknown. The available sources do not establish whether exploitation requires simply visiting a malicious page, opening specially crafted XML content, interacting with a page, or another delivery mechanism. They also do not confirm whether attackers are achieving code execution inside a Chrome renderer, escaping the browser sandbox, or combining the vulnerability with another flaw.

The Hacker News notes that use-after-free bugs can potentially lead to data corruption, crashes, or arbitrary code execution. This describes the general security impact of this vulnerability class rather than a Google-confirmed description of the exact exploitation chain used against CVE-2026-125350.

Google’s statement is nevertheless significant because the company explicitly confirms that an exploit exists in the wild. This means the vulnerability should be treated as an immediate patching priority even though technical information about the attacks remains limited.

The vulnerability was anonymously reported to Google on November 6, 2026. Only three days later, on November 9, Google released patched Stable builds for Windows, macOS, and Linux and acknowledged active exploitation.

The update containing the zero-day fix addresses nine security issues in total. Other high-severity flaws include an uninitialized resource issue in WebGL, incorrect authorization in FileSystem, a buffer overflow in Compositing, an out-of-bounds write in GPU, a type confusion vulnerability in V8, and another use-after-free issue in XML tracked as CVE-2026-125346. Two medium-severity GPU vulnerabilities were also patched.

The presence of CVE-2026-125346 in the same release is worth distinguishing from the actively exploited vulnerability. Both issues involve use-after-free conditions in Chrome’s XML functionality, but Google has only stated that CVE-2026-125350 is being exploited in the wild.

Google released the following fixed Stable versions:

Platform	Fixed Chrome Stable version
Windows	157.0.8103.50/.51
macOS	157.0.8103.50/.51
Linux	157.0.8103.50

Extended Stable users on Windows and macOS should move to version 156.0.8078.96 or later.

Because Chrome updates roll out progressively, an installed browser may not immediately receive the patched version. Users and administrators should therefore verify the actual running build instead of assuming that automatic updates have already remediated the issue.

The CVE-2026-125350 PoC situation also requires caution. Google confirms that attackers possess a working exploit, but neither Google nor the two supplied reports identifies a publicly released proof-of-concept reproducing the exploit. The Chromium bug details remain restricted, which limits defenders’ ability to reproduce the vulnerability or identify exploit-specific artifacts.

For CVE-2026-125350 detection, organizations should begin with exposure management. Security teams should inventory Chrome versions across endpoints and identify systems running builds older than the fixed releases. Internet-facing servers are not the primary concern here; employee workstations and other systems used for web browsing deserve immediate attention.

Endpoint telemetry can provide additional hunting opportunities. Defenders should investigate unusual processes originating from Chrome, particularly command interpreters, scripting engines, system utilities, or newly downloaded executables that appear immediately following browser activity.

Suspicious behavior can include unexpected execution of PowerShell, cmd.exe, Windows Script Host, mshta.exe, rundll32.exe, or other utilities from a Chrome-related process tree. Such activity is not specific to this vulnerability and should not by itself be treated as proof of exploitation, but it can provide a useful behavioral signal when combined with vulnerable browser versions and suspicious browsing activity.

Security teams should also examine endpoint telemetry for unusual Chrome crashes or renderer failures followed by new process execution, file creation, credential access, persistence, or network connections. Browser crashes alone are common and therefore require correlation with other evidence.

Web proxy, DNS, secure web gateway, and endpoint browser telemetry can help reconstruct user activity immediately before suspicious execution. Organizations should preserve relevant browsing history and network logs if exploitation is suspected, particularly because Google has not published information about the websites or infrastructure used in the observed attacks.

There are currently no vendor-published CVE-2026-125350 IOCs such as malicious domains, IP addresses, payload hashes, or attacker infrastructure. Google has also not disclosed the threat actors responsible, affected organizations, campaign scope, or geographic targeting.

This lack of static indicators makes behavior-based monitoring and rapid browser version management especially important. A hunt based exclusively on hashes or known domains cannot reliably determine whether an environment has encountered exploitation when the public attack infrastructure remains unknown.

Organizations using Chromium-based browsers such as Microsoft Edge, Brave, Opera, and Vivaldi should monitor their respective vendor advisories and deploy relevant security updates as they become available. The Hacker News specifically recommends that users of these browsers apply fixes when their vendors release them.

CVE-2026-125350 Mitigation

The primary remediation is to update Google Chrome immediately to a fixed version and restart the browser so the corrected build is running.

Google has released:

• Chrome 157.0.8103.50/.51 for Windows
• Chrome 157.0.8103.50/.51 for macOS
• Chrome 157.0.8103.50 for Linux
• Chrome Extended Stable 156.0.8078.96 for Windows and macOS

Chrome normally downloads updates automatically, but users must relaunch the browser for the updated build to replace the vulnerable running process. The Hacker News recommends opening More → Help → About Google Chrome and relaunching after the update is installed.

Enterprise security teams should take the following actions:

1. Inventory Chrome versions across managed endpoints.
2. Prioritize systems still running versions older than the fixed Stable or Extended Stable builds.
3. Force or accelerate Chrome updates through enterprise browser-management tooling.
4. Verify that browsers have actually restarted after receiving the patch.
5. Monitor endpoints that cannot be updated immediately for suspicious browser-originated processes.
6. Restrict access to known malicious or newly registered web infrastructure through existing web security controls.
7. Review security telemetry for suspicious Chrome activity that occurred before patch deployment.
8. Monitor vendor advisories for Chromium-based browsers and update those products when fixes become available.

Because exploitation has already occurred in the wild, patching should not be the only response for systems that may have been exposed. Administrators should consider reviewing recent endpoint activity on vulnerable machines, especially where security tools recorded unusual Chrome crashes, browser-spawned command execution, suspicious downloads, or connections to untrusted infrastructure.

If suspicious activity is discovered, isolate the affected endpoint and preserve browser, EDR, DNS, proxy, and network telemetry before remediation. Investigators should reconstruct the browser activity preceding the event and determine whether any follow-on payloads, credential theft, persistence, or lateral movement occurred.

Organizations should also verify whether the browser was running under an account with access to sensitive web sessions, enterprise applications, cloud consoles, or privileged credentials. Depending on evidence of compromise, session revocation and credential rotation may be appropriate.

Google’s restricted disclosure means defenders do not currently have enough public information to build a signature for the actual exploit. This reinforces the importance of patch management and generic exploitation detection rather than waiting for a reliable network or file signature.