Chrome Zero-Day CVE-2026-125350: Update Before You Log In

Google patched Chrome zero-day CVE-2026-125350 on 9 November 2026, a high-severity use-after-free in the browser XML component that is already exploited in the wild. If that browser opens wp-admin, a hosting panel, webmail, or a payment dashboard, update it and relaunch before the next login.

What happened in the 9 November Chrome update?

Google shipped a stable Chrome security update on Monday, 9 November 2026, and closed nine vulnerabilities. One of them, CVE-2026-125350, is already exploited in the wild.

The Hacker News, in a 10 November 2026 report by Ravie Lakshmanan, counted this as the eighth actively exploited Chrome zero-day of the year. We covered the sixth exploited Chrome zero-day of 2026 when that fix shipped.

An anonymous researcher reported the bug to Google on 6 November 2026. The stable fix followed on 9 November. Google says an exploit was already in use during that gap. It named no victim, sector, country, or malware family, and withheld the bug write-up until a majority of users are updated. Restrictions can also remain if the flaw sits in a third-party library other projects have not fixed. Google did not say this XML bug is in shared code.

That report listed seven earlier exploited cases and did not describe each bug: CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, CVE-2026-11645, CVE-2026-85046, and CVE-2026-87491. Only one of the nine fixes in this release is described as actively exploited. CISA later added CVE-2026-125350 to the Known Exploited Vulnerabilities catalog and set a 24 November 2026 deadline for federal agencies. Private organizations are not under that order.

What is Chrome zero-day CVE-2026-125350?

CVE-2026-125350 is a use-after-free in Chrome’s XML component, scored CVSS 8.8 and rated high severity.

The CVE.org text quoted by The Hacker News is the only formal description:

Use-after-free in XML in Google Chrome prior to 157.0.8103.50 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.

Every Chrome build older than 157.0.8103.50 is affected. The attacker is remote and needs no account on the computer. The trigger is a crafted HTML page. The stated result is arbitrary code execution inside the sandbox.

The sandbox separates the renderer, which handles web content, from the rest of Windows, macOS, or Linux. Code running there can reach pages in that process, including a login form. The public description stops at sandboxed code execution. A full operating-system takeover would normally need a second bug, such as a sandbox escape. Google did not describe the other eight fixes, so whether any escape is chained is not public.

A use-after-free means the program frees a block of memory and later uses a pointer that still aims at it. No memory layout, trigger sequence, or proof-of-concept for CVE-2026-125350 has been published.

Fixed builds are 157.0.8103.50 and 157.0.8103.51 for Windows and Apple macOS, and 157.0.8103.50 for Linux. Those numbers are desktop builds. Chrome on Android and on iOS follows a different version line, so a phone or tablet needs its own store update.

Why does this matter if you run a website?

The flaw sits in the browser that loads a page. WordPress, Joomla, PHP, and the server XML stack are a different product. The site files are a separate matter unless admin-account or panel logs say otherwise.

Update the machines that open wp-admin, cPanel or an equivalent hosting panel, webmail, and payment or DNS dashboards first. Those sessions are where a site password, an API token, or a recovery code gets typed. Treat the admin browser as safe only after it is on the fixed build and has been relaunched.

A crafted page can be a hostile site, a compromised page, a malicious ad, or an injected third-party script. A compromised page or injected script on your site could deliver that page to visitors, even though your theme and plugins have nothing to do with this CVE. Public reporting has not tied CVE-2026-125350 to a website malware campaign. Staff browsers are the ones you can update today.

Keep site administration off a shared kiosk profile. If several people share one Chrome profile for the panel, one bad page in that profile sits next to every saved login.

On incident work, what shows up is a new WordPress or Joomla administrator, an email change on an existing admin, a password reset the owner did not start, or a panel login from an unfamiliar address. None of those signs are published indicators for this bug. If you suspect a specific visit, preserve endpoint telemetry, history, and download records before you clear the profile.

If the account and panel logs show nothing suspicious, the site files can stay as they are. If the logs show suspicious activity, rotate the exposed passwords from the updated browser, revoke sessions, and then inspect the site. Ongoing website protection watches the site while you finish the browser work.

Which version should the running Chrome process show?

After a relaunch, Windows and macOS should show 157.0.8103.50 or 157.0.8103.51. Linux should show 157.0.8103.50. Read that string from the process you are about to use for the panel.

Google’s path is More, then Help, then About Google Chrome, then Relaunch. On a fleet, open chrome://version or that About page and read the version of the running process, not the installer log. Installer logs can report success while an older process is still running. On a PC that keeps Chrome in the background, closing the last window can leave the old process alive. If a session restores at boot, confirm About after that restore, before anyone types a password.

Check each machine that can administer the site: the owner’s laptop, a shared office computer, and any host you use only occasionally, including the PC that only opens the registrar or the payment dashboard. If a company-managed browser still shows an older build, the update ring may be delaying it. Wait to use that browser for the panel until About matches the fixed build. Portable copies and a second Chrome channel need the same version check.

Use a dedicated browser profile for administration once the build is current. Casual browsing and privileged logins in the same profile share one cookie store. Move admin work to a fresh profile after the version is fixed, or remove extensions you do not recognize before the next login.

Microsoft Edge, Brave, Opera, and Vivaldi pick up the Chromium fix on their own calendars. The 10 November report did not list fixed build numbers for them. A Chromium version string inside Edge or Brave is the upstream base. The vendor build is what tells you whether CVE-2026-125350 is closed. Until that vendor build is installed and the browser has been restarted, keep wp-admin, hosting panels, and registrar logins in an updated Chrome window. Opera and Vivaldi follow the same split: their own release notes are the record that the XML fix is present.

After the browser is updated, check admin accounts and panel logs. The browser fix does not rewind anything that already happened on the site.

• Confirm the fixed build on every admin machine, including a laptop that was shut during the 9 November release. Read chrome://version or About on the running process: 157.0.8103.50 or 157.0.8103.51 on Windows and macOS, and 157.0.8103.50 on Linux.
• Review WordPress or Joomla users for new administrators and for role or email changes since 6 November.
• Review hosting and registrar sign-in logs for addresses you do not recognize from the days the old build was still in use.
• If those logs show nothing suspicious, leave the site files in place. The bug is in the client.
• If the logs show suspicious activity, rotate the exposed passwords from the patched browser, revoke sessions, and then look at files and plugins.

Browser version and site monitoring catch different failures. Pair the relaunch with antivirus website protection when admin credentials live on the same PCs you just patched. Who is exploiting CVE-2026-125350, how the page is delivered, and whether any sandbox escape is chained are still unpublished.

FAQ

What is CVE-2026-125350 in Google Chrome?

It is a high-severity use-after-free in Chrome's XML component, scored CVSS 8.8. On every Chrome build older than 157.0.8103.50, a remote attacker could run arbitrary code inside the sandbox by getting the browser to open a crafted HTML page.

Is the Chrome zero-day of November 2026 being exploited?

Yes. Google said it is aware that an exploit for CVE-2026-125350 exists in the wild. It has not named the attacker, the victims, or the delivery method, and CISA added the bug to the Known Exploited Vulnerabilities catalog.

Which Chrome version fixes CVE-2026-125350?

Windows and macOS are fixed in 157.0.8103.50 and 157.0.8103.51. Linux is fixed in 157.0.8103.50. Every Chrome build older than 157.0.8103.50 is vulnerable, and the new code loads when you relaunch Chrome. Chrome on Android and iOS follows a different version line.

Does CVE-2026-125350 affect Microsoft Edge, Brave, Opera, or Vivaldi?

Those browsers inherit the Chromium fix on their own release schedules. The 10 November report did not list fixed build numbers for them. Confirm each product from its own About page and vendor update before using it for wp-admin or hosting-panel logins.

If the admin browser was behind during this Chrome zero-day, pair the relaunch with a look at the site itself. SiteGuarding can watch the files and admin side through website protection while you confirm every login machine is on the fixed build.