Chrome Zero-Day CVE-2026-125350: Update and Check

Google has patched another Chrome vulnerability that attackers were already exploiting. It is tracked as CVE-2026-125350, a use-after-free bug in Chrome's XML component, and the fix shipped on 9 November 2026. If your browser is older than the fixed build, a web page can be enough to trigger it.

The headlines say "execute malicious code remotely", which is true but easy to over-read. This article explains what has actually been confirmed, what has not, which versions are safe, and how to check every Chromium-based browser you and your team run, including the ones that don't look like browsers.

The short version

• Bug: CVE-2026-125350, use-after-free (CWE-416) in Chrome's XML component, rated High by Chrome.
• Exploited: Google says it is aware that an exploit for this CVE exists in the wild.
• Fixed in: Stable 157.0.8103.50 (Linux) and 157.0.8103.50/.51 (Windows, macOS); Extended Stable 156.0.8078.96.
• Your action: update, then relaunch the browser. The fix does not apply until the restart.

What is confirmed

What "remote code execution" means here

This is where the headlines run ahead of the evidence. The CISA catalog entry, as quoted by one write-up, describes a remote attacker running code inside the sandbox through a crafted web page. Chrome's sandbox is a separate layer that limits what a compromised renderer can do to the rest of the machine. A sandbox escape or full device compromise has not been publicly confirmed for this bug.

That is still serious. Real attacks on browsers are usually chains: one bug to get code running in the renderer, and a second one to break out. A bug exploited in the wild is often the first link of such a chain, though nobody has published what the second link was here. Treat the missing information as unknown, not as a reason to wait.

It also needs a user to visit a page. No account, no credentials, no prior access: just a link, an ad, a compromised site or an embedded frame. Google and CISA have not said who is using the exploit or against whom, so don't assume you are not a target because you are not a high-profile one.

Why a use-after-free bug is dangerous

A use-after-free happens when code keeps using memory after it has been released. If an attacker can control what gets placed in that freed memory, the program may end up reading or running attacker-chosen data. Browsers parse untrusted input constantly, in a language (C++) where this class of mistake is possible, so they see a steady supply of such bugs. That is why Chrome security updates arrive so often, and why running an old build is the real risk, not any single CVE.

BleepingComputer's headline calls this the eighth Chrome zero-day exploited in attacks this year. I could only read the headline, not the article, so I'm quoting it as reported.

Check your version in one minute

The fastest check is the browser itself: open chrome://version, or go to Help, then About Google Chrome, which also triggers the update download. Look for 157.0.8103.50 or newer.

From a terminal:

# Linux
google-chrome --version

# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --version

# Windows (default install path)
(Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

To compare it against the fixed build in a script (a fleet audit, a CI image check), here is a small helper. It accepts either the whole version string or just the number:

#!/usr/bin/env bash
# usage: ./chk.sh "<version output from the browser>"
# Fixed builds for CVE-2026-125350: Stable 157.0.8103.50 or newer,
# Extended Stable 156.0.8078.96 or newer.
CUR="$(echo "$1" | grep -oE '[0-9]+(\.[0-9]+){3}' | head -1)"
[ -z "$CUR" ] && { echo "no version found in: $1"; exit 2; }
ge() { [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -1)" = "$2" ]; }
MAJOR="${CUR%%.*}"
if [ "$MAJOR" -ge 157 ] && ge "$CUR" 157.0.8103.50; then echo "$CUR: has the fix"
elif [ "$MAJOR" -eq 156 ] && ge "$CUR" 156.0.8078.96; then echo "$CUR: has the fix (Extended Stable line)"
elif [ "$MAJOR" -gt 157 ]; then echo "$CUR: newer major, assume fixed"
else echo "$CUR: older than the fixed builds, update"; fi

Running it:

$ ./chk.sh "Google Chrome 156.0.8078.96"
156.0.8078.96: has the fix (Extended Stable line)
$ ./chk.sh "157.0.8103.9"
157.0.8103.9: older than the fixed builds, update
$ ./chk.sh "153.0.8010.12"
153.0.8010.12: older than the fixed builds, update

The comparison uses sort -V, which compares dotted numbers correctly, so 157.0.8103.9 is treated as older than 157.0.8103.50. A plain string comparison would get that wrong. I tested the script against those cases, including a version-less input, which exits with an error.

How to update

• Desktop Chrome (Windows, macOS): Help, About Google Chrome, then Relaunch. Chrome downloads updates in the background, but the fix takes effect only after a restart. A browser that has run for weeks with a pending update is still vulnerable.
• Linux: use the package manager. For Google's apt repository, that is sudo apt update && sudo apt install --only-upgrade google-chrome-stable, then restart the browser. Use the equivalent command for your distribution if you installed Chromium from a distro package, and check that its maintainers have shipped the fix.
• Android: update through Google Play. One report lists the Android build as 157.0.8103.50, but the Android advisory does not list this CVE individually, so confirm the version on your own device.
• Managed fleets: use your endpoint management tool to read installed versions, and consider Chrome's enterprise relaunch notification policies so users are not left on a pending update indefinitely. Check the current policy documentation for exact names and behavior, since I did not test them.

Other Chromium browsers and apps

The vulnerable code lives in Chromium, the open-source engine, so Edge, Brave, Opera, Vivaldi and others may be affected until they ship a build based on the fix. Each vendor patches on its own schedule. Two data points from the sources I read:

• Microsoft's Edge release notes of 9 November said it was aware of exploits in the wild and was working on a fix, without naming the CVE, according to a secondary write-up. Check the Edge security notes for the current fixed build.
• I did not find a confirmed fixed version for Opera, Vivaldi or Brave in what I read. Look up each vendor's own advisory rather than assuming.

As developers we also run Chromium in places that don't look like browsers:

• Playwright, Puppeteer and Selenium test browsers. They download pinned Chromium builds. In my test environment, Playwright's bundled Chromium reported 153.0.8010.12, which is older than the fixed build. By the CVE's affected range that means it does not contain this fix. I did not test whether the exploit works against it. If your CI browses untrusted pages (scraping, link checking, screenshot services), update the browser package and the cached browser downloads.
• Electron apps. Each app bundles its own Chromium. Whether an app is exposed depends on its Electron version and on whether it loads untrusted content. Look at the vendor's release notes rather than your installed Chrome.
• Headless Chrome in containers. A Docker image built months ago keeps the browser version it was built with. Rebuild images that include Chrome or Chromium.

If you can't patch right away

Patching is the fix. Everything below only reduces exposure, and none of it replaces updating:

• Close long-running browser sessions and restart the browser, so a downloaded update is actually applied.
• Avoid opening untrusted links from email and chat on unpatched machines.
• Keep browser isolation features and the sandbox enabled. Don't launch Chrome with --no-sandbox outside a throwaway container, and if CI needs it, keep that CI away from untrusted pages.
• Restrict unapproved extensions, and use DNS or web-gateway filtering if your organization has them.
• Watch endpoint telemetry for unusual browser child processes, repeated browser crashes and odd outbound connections.

Common mistakes

• Updating without relaunching.
• Checking only Chrome and forgetting Edge, Brave, Electron apps and CI browsers.
• Assuming a sandboxed bug is harmless, or assuming it means total compromise. Neither is established.
• Waiting for details of the exploit before patching.
• Reading the CISA deadline as applying to everyone. The 24 November date is for US federal civilian agencies; for everyone else it is a useful priority signal.

Frequently asked questions

Is CVE-2026-125350 being exploited right now?

Google says it is aware that an exploit exists in the wild. It has not disclosed who is using it or how widely.

Do I need to do anything if Chrome updates itself?

Yes: relaunch. Check chrome://version afterwards and confirm the number is at least 157.0.8103.50 (or 156.0.8078.96 on Extended Stable).

Does it affect Firefox or Safari?

The sources I read describe a Chrome and Chromium bug. I did not find anything saying Firefox or Safari are affected, but I did not test them.

Did the attackers escape the sandbox?

Not publicly confirmed. Code execution in the sandbox is the confirmed description.

How do I know if I was attacked?

There are no public indicators of compromise that I could find. Google has not published any attacker details. The practical response is to patch and review endpoint telemetry for unusual browser behavior.

Related Dev Talk articles

• Malicious Claude Code Extension in the Cursor Marketplace: What Happened and How to Check Your Machine

Sources

• Cyber Security News: Google Chrome 0-Day Vulnerability in the Wild to Execute Malicious Code Remotely
• SOC Prime: CVE-2026-125350, Chrome XML Zero-Day Exploited in the Wild
• eSecurity Planet: Google Patches Exploited Chrome Zero-Day
• braindetox.kr: Chrome CVE-2026-125350 in KEV
• BleepingComputer: Google patches eighth Chrome zero-day exploited in attacks this year (headline only)

Originally published on DEV Talk.