Chrome zero-day number eight of 2026 lives in the XML parser. update, then actually relaunch (CVE-2026-125350)

Google shipped Chrome 157.0.8103.50 on Monday with nine security fixes, and one of them, CVE-2026-125350, already has an exploit in the wild. it is a use-after-free in XML. that is the whole public description. we know exactly as much as Google wants us to know, which is the usual amount: enough to be nervous, not enough to be interesting. the fix exists. the hard part, as always, is getting 4,000 people to close 300 tabs.

what Google actually said

the Stable Channel Update for Desktop, dated Monday, November 9, 2026, moves Stable to 157.0.8103.50/.51 for Windows and Mac and 157.0.8103.50 for Linux, “which will roll out over the coming days/weeks.” it lists nine security fixes. the one that matters today:

[N/A][582442907] High CVE-2026-125350: Use after free in XML. Reported by anonymous on 2026-11-06

followed by the sentence that ruins everyone’s Tuesday: “Google is aware that an exploit for CVE-2026-125350 exists in the wild.”

reported November 6, patched in Stable November 9. three days. say what you want about Google, the browser team moves faster than most vendors’ legal review of a disclosure email.

what we know, what we do not, and what we refuse to make up

known:

• bug class: use after free, in Chrome’s XML handling.
• trigger, per the CVE record: “a crafted HTML page.” so the delivery is a web page. no download, no attachment required by the description.
• impact, per the CVE record: arbitrary code execution “inside the sandbox.” that wording matters. it means the bug, by itself, gives code execution in a sandboxed renderer process, not the whole machine.
• Google rates it High on the Chromium severity scale.
• the reporter is anonymous. Google has not said who is exploiting it, against whom, or how.

not known:

• whether the in-the-wild exploit pairs this with a sandbox escape. renderer bugs usually need a second bug to own the host. the advisory does not say whether one was used, so we will not say it either.
• who the targets were. no attribution, no campaign name, no IOCs.
• a CVSS score. the CVE record published at 17:20 UTC today carries no CVSS metrics, and NVD had nothing for it when we checked.

if you see a vendor blog this week with a confident CVSS 8.8 and a threat actor name, ask where they got it. we checked. it was not from Google.

the rest of the release, briefly

the same update fixes eight more bugs. Google discovered most of them internally:

• High: CVE-2026-125345 uninitialized resource in WebGL; CVE-2026-125347 incorrect authorization in FileSystem; CVE-2026-125343 buffer overflow in Compositing; CVE-2026-125348 out of bounds write in GPU; CVE-2026-125344 type confusion in V8; CVE-2026-125346 use after free in XML (reported by Arni Hardarson, Neonix Security, on 2026-10-12)
• Medium: CVE-2026-125349 uninitialized resource in GPU; CVE-2026-125342 uninitialized resource in GPU (reported by Vo Duc Thang)

yes, two separate use-after-free bugs in XML in one release. the exploited one is 125350. if you see people mixing them up this week, now you know why.

eight this year

SecurityWeek and BleepingComputer both count this as the eighth exploited Chrome zero-day of 2026, after CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, CVE-2026-11645, CVE-2026-85046 and CVE-2026-87491. we have not independently re-verified every entry in that list, so treat the count as theirs. the trend line is not in dispute: the browser is the most attacked application on your endpoints, and it updates itself, and people still find a way to run old versions.

why “it auto-updates” is not a patch plan

Chrome downloads the update in the background. it does not run the new code until the browser restarts. the user who has had the same window open since the Ides of March is running the old binary, and Chrome shows them a polite little “Update” pill that they have learned to ignore.

on Linux it is even more fun: the package manager replaces the binary on disk while the old one keeps running from memory. the process is fully patched in your package inventory and fully vulnerable in reality. your vulnerability scanner reads the package version and congratulates you.

so there are three questions, not one:

1. is the fixed version installed?
2. is the running process the fixed version?
3. is there a policy that forces the relaunch, so you are not depending on vibes?

step 1: fleet and local check

the kit’s check script answers all three on a Linux host, and does fleet triage from a CSV export (host, browser, version) from whatever endpoint tool you have. Google Chrome rows are compared against 157.0.8103.50. anything that is not a Google Chrome build gets REVIEW, not OK or VULN, because Edge, Brave, Opera, Vivaldi, and distro Chromium packages ship their own builds on their own schedules with their own version numbers. the Edge row in our lab CSV (157.0.3112.45) is not comparable to Chrome’s 157.0.8103.50, and pretending otherwise is how people end up confidently wrong.

the local mode also walks running Chrome processes and checks whether /proc/<pid>/exe points at a deleted file, which is what you see on Linux when the binary was replaced under a running browser. any hit there means “patched on disk, not in memory. relaunch.”

step 2: force the relaunch

Chrome has enterprise policies for exactly this. RelaunchNotification set to 2 tells users a relaunch is required, and RelaunchNotificationPeriod sets how long they get, in milliseconds, before Chrome relaunches itself. the kit writes a managed policy file on Linux with a four-hour window. dry run by default. on Windows and macOS, push the same two keys through GPO, Intune, or your MDM profile.

check that it took at chrome://policy. then tell the help desk before you turn it on, because “my browser restarted itself” will become a ticket category by lunchtime.

what does not help

• blocking XML. you cannot meaningfully block “XML” on the web. it is everywhere: SVG, feeds, XHTML, XSLT, half of the enterprise apps your finance team uses. do not try.
• waiting for KEV. it is not on KEV as of catalog version 2026.11.09. Chrome zero-days usually get there, but a KEV listing is a deadline for federal agencies, not a starting gun for you.
• waiting for a CVSS. the score will show up eventually. the exploit did not wait for it.
• hunting for IOCs. there are none published. anyone selling you a “CVE-2026-125350 detection rule” today is selling you a version check with marketing.

what to do, in order

1. push Chrome 157.0.8103.50 (Linux) or 157.0.8103.50/.51 (Windows, Mac) to everything you manage.
2. force a relaunch with RelaunchNotification and a short RelaunchNotificationPeriod.
3. verify running versions, not installed versions, on Linux especially.
4. check each Chromium-based browser vendor for its own fix. do not map version numbers across vendors.
5. Android: Google released 157.0.8103.50 for Android the same day. make sure your MDM is not holding it.

download the Kali defensive kit

chrome-cve-2026-125350-defensive-kit.zip contains chrome-125350-check.sh (local versions, stale running binaries, relaunch policy check, fleet CSV mode), chrome-relaunch-policy.sh (dry run by default), a README, and the lab CSV from the screenshot. fixed versions are printed in every run. it makes no network connections and contains no exploit code.

sources

• Google, Chrome Releases: Stable Channel Update for Desktop (November 9, 2026)
• CVE-2026-125350 record (Chrome CNA, published 2026-11-10 17:20 UTC, no CVSS metrics)
• CISA Known Exploited Vulnerabilities catalog, version 2026.11.09, checked November 10, 2026 (not listed)
• SecurityWeek, “Chrome Update Patches Exploited XML Zero-Day, Eighth This Year” and BleepingComputer, “Google patches eighth Chrome zero-day exploited in attacks this year” (for the year-to-date count)
• Malwarebytes, “Update Chrome now to fix a flaw attackers are exploiting” (for the Android release)
• Google Chrome Enterprise policy list: RelaunchNotification and RelaunchNotificationPeriod