Google: Chrome XML bug CVE-2026-125350 has an exploit in the wild; fixed in 157.0.8103.50, 3 days after report

Google dates the report 6 November and the fix release 9 November: 3 days, for a bug it says has an exploit in the wild

Google's Stable Channel Update for Desktop, published on Monday 9 November 2026, lists 9 security fixes for Chrome 157.0.8103.50. One line reads "[N/A][582442907] High CVE-2026-125350: Use after free in XML. Reported by anonymous on 2026-11-06". Under the list Google writes "Google is aware that an exploit for CVE-2026-125350 exists in the wild." The release came 3 days after that report date (derived: Friday 6 November to Monday 9 November, and the post prints dates without times, so the real gap is not known to the hour).

That sentence does not say who has the exploit, who it was used against, how often, since when, or how it works. A report date is not an exploit date: it does not say the 6 November report was the first moment anyone outside the attacker knew of the bug. The reporter is "anonymous", so the post does not say whether the exploit reached Google from a victim, a vendor or a researcher. It does not say whether the exploit needs a second flaw to get out of Chrome's sandbox, and it does not say which XML library the bug is in: the post names only the component, "XML".

Google makes Chrome, wrote the post, and credits itself as the reporter of 6 of the 9 bugs in it (derived count), so the only account of this exploit in the pages read is the vendor describing its own product. The Stable post was read on its own page and in the Chrome Releases feed, the Extended Stable post, the Android post and the Chrome Security page were read in full, and the CVE.org, NVD and CISA records were checked, all between 10:44 and 10:57 UTC on Tuesday 10 November 2026. Nothing here is a statement by an attacker, a victim or an independent researcher.

The nine fixes as printed, and where the exploited one sits

The post says the Stable channel has been updated 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". Chrome 157 itself reached Stable on 3 November, 6 days earlier (derived), at 157.0.8103.38 on Linux and 157.0.8103.38/.39 on Windows and Mac, so this is a point update to a release that was 6 days old. This site's brief on that 3 November release records 213 fixes, and the 3 November post says nothing about attacks.

Each line opens with a reward field in square brackets and a Chromium bug ID. The field reads N/A on 7 lines and TBD on the 2 lines credited to external researchers other than the anonymous one (derived counts). The post does not explain the field. Severity is Google's own label: 7 High and 2 Medium. The exploited bug is the youngest report on the list at 3 days, and the other 8 were 28 to 112 days old at the release date (derived); the median of all 9 is 52 days.

Zoom

Two use after free bugs in XML, and what the word XML leaves open

Both XML bugs in this release are High use after free bugs. CVE-2026-125346 was reported on 12 October by Neonix Security, and CVE-2026-125350 on 6 November by an anonymous source, 25 days later (derived). Google's exploitation sentence names only the second. Nothing in the post says the first was exploited, and nothing says it was not: the post is silent on it.

The previous Stable post, the one for 3 November, also carried two fixes labelled XML: CVE-2026-121124, High, "Improper adherence to coding standards in XML", reported by Google on 25 September, and CVE-2026-121054, Low, "Improper state validation in XML", reported by Neonix Security on 23 September. That makes 4 CVEs labelled XML across two Stable posts 6 days apart (derived). No page read says the four are related, and this site does not suggest it.

"XML" names a component, not a library. The post does not say whether the code is written inside Chromium or comes from a third party. Every post read carries a standard note that restrictions stay in place "if the bug exists in a third party library that other projects similarly depend on, but haven't yet fixed". That is boilerplate on the 3 November and 9 November posts alike and is not a statement about this bug.

Bug details are restricted for now. The post says access "may be kept restricted until a majority of users are updated with a fix". The Chrome Security page says "security bugs automatically become publicly visible 14 weeks after they are fixed". Counted from the release date that is 15 February 2027 (derived; the post does not date the code change, so the real date could be earlier). The issue tracker links in the post lead to a sign in page when this site's reader fetched one, so no tracker text was read.

The Extended Stable post: the same CVE, and no exploitation sentence

Organisations that run the Extended Stable channel read a different post. It went up about 8 minutes before the Stable post (derived) and lists 11 fixes for 156.0.8078.96, including CVE-2026-125350, but it prints no exploitation sentence anywhere. Extended Stable is one major version behind Stable here, 156 against 157, not two. Of its 11 fixes, 4 are shared with the Stable post, and the other 7 are CVEs that the Stable post of 3 November had already listed and that did not appear in the Extended Stable post of 3 November (derived by comparing the lists), so the Extended Stable post lists those 7 for the first time 6 days after the Stable post did. The ChromeOS post of 6 November, for browser 156.0.8078.93, already lists 5 of the 7, so the fixes may have reached some 156 builds earlier than this post suggests. Five of the Stable post's 9 fixes (the Compositing, V8 and three GPU bugs) are not in the Extended list, and the post does not say why.

Both posts show a last updated stamp about two hours after publication, and the feed does not say what changed. This site therefore cannot tell whether the exploitation sentence was in the first version of the Stable post. What can be said is that an administrator who reads only the Extended Stable post sees CVE-2026-125350 as one High bug among eleven, with no sign that Google says an exploit exists.

Other builds and other browsers, as far as the pages read go

Chrome's engine, Chromium, sits under many browsers, and each vendor ships its own builds. The table lists only what pages read on 10 November 2026 say. Edge and Brave publish their own notes, and a note that a vendor is working on a fix is not a fix.

The records that do not exist yet: CVE.org, NVD and CISA's list

At 10:45 UTC on 10 November 2026, and again at 10:57 UTC with the same answers, the CVE.org record service answered that the record for CVE-2026-125350 does not exist, and the NVD API returned zero results for it (and for CVE-2026-125346). So there is no CVSS score, no weakness class and no affected version range in either database as read. The "High" on the post's line is Google's label, and this site found no CVSS vector from anyone.

The CISA Known Exploited Vulnerabilities catalogue did not list CVE-2026-125350 either. The copy the lead saved is version 2026.11.09 with 1,773 entries, released 19:54:37 UTC on 9 November, which is before both Chrome posts went up (20:45 and 20:52 UTC, derived), so its silence then was expected. This site fetched the file again at 10:47 UTC on 10 November and it was byte for byte the same, still version 2026.11.09. That says nothing about whether CISA will add the bug.

For context, the saved KEV copy holds 7 entries with a 2026 date added whose product field is Chromium, Chromium V8, Skia or Dawn (derived count, listed below). That is KEV's list, not Google's count of exploited Chrome bugs, and the two need not match: no page read gives a running count of exploited Chrome bugs in 2026.

What Google states, and what it does not

Zoom

Labels doing the work of a control

"The Stable channel has been updated" is a statement about the channel, not about any machine. The same sentence says the update will roll out over the coming days or weeks, so a laptop can sit on an older build while the post reads as finished. The post does not mention restarting the browser. This site's general knowledge, not from a page read, is that Chrome installs a downloaded update when the browser is relaunched, so a browser left open for days can stay on the old build.

"High" is Google's severity word, and "in the wild" is Google's phrase for an exploit it knows of. Neither is a CVSS score or a statement that your users were targeted. A control would be a checked version on each device, and the post offers nothing to check against except the build number.

What to do, in order

Google's posts contain no defender guidance beyond the builds, so this list is this site's suggestion, built on the build numbers the posts print.

Technical details

Google prints no indicator of compromise for this exploit: no hash, address, domain, file name, crash signature or log pattern. There is no proof of concept in the pages read, and this site publishes none. The blocks below are what the pages do print, copied as published, with the version strings a defender checks against.

Version strings and rollout wording. These are the fixed builds and the rollout sentence. A defender compares the browser version on each device with them, on the right channel.

The Stable channel has been updated to 157.0.8103.50/.51 for Windows and Mac and 157.0.8103.50 to Linux which will roll out over the coming days/weeks.
The Extended Stable channel has been updated to 156.0.8078.96 for Windows and Mac which will roll out over the coming days/weeks.
Android releases contain the same security fixes as their corresponding Desktop releases (Windows & Mac: 157.0.8103.50/.51 Linux: 157.0.8103.50) unless otherwise noted.

The exploited line and the exploitation sentence. This block holds the exploited bug's line and the 6 lines credited to Google, copied as printed, with the sentence under them. The post's 2 other lines credit external researchers by name; this site does not print individuals' names, so those two lines are left out, not altered.

[N/A][550525698] High CVE-2026-125345: Uninitialized resource in WebGL. Reported by Google on 2026-08-21
[N/A][561996724] High CVE-2026-125347: Incorrect authorization in FileSystem. Reported by Google on 2026-09-15
[N/A][561998123] High CVE-2026-125343: Buffer overflow in Compositing. Reported by Google on 2026-09-15
[N/A][563358700] High CVE-2026-125348: Out of bounds write in GPU. Reported by Google on 2026-09-18
[N/A][568893995] High CVE-2026-125344: Type confusion in V8. Reported by Google on 2026-10-02
[N/A][582442907] High CVE-2026-125350: Use after free in XML. Reported by anonymous on 2026-11-06
[N/A][536663516] Medium CVE-2026-125349: Uninitialized resource in GPU. Reported by Google on 2026-07-20
Google is aware that an exploit for CVE-2026-125350 exists in the wild.

The Extended Stable list. This is the whole list from the post for 156.0.8078.96. Seven of these CVEs are not in the Stable post of 9 November, and none carries an exploitation sentence.

[577327383] High CVE-2026-121068
[578670966] High CVE-2026-121076
[558111285] High CVE-2026-121095
[577402416] High CVE-2026-121208
[574762568] High CVE-2026-121213
[552757015] High CVE-2026-121233
[550525698] High CVE-2026-125345
[572578603] High CVE-2026-125346
[561996724] High CVE-2026-125347
[582442907] High CVE-2026-125350
[565681451] Medium CVE-2026-121184

The records as read. The first line is the CVE.org record service answer for CVE-2026-125350 and the second is the NVD answer for the same ID, both at 10:45 UTC on 10 November 2026. A defender rechecks both for a score and affected range.

{"error":"CVE_RECORD_DNE","message":"The cve record for the cve id does not exist."}
{"resultsPerPage":0,"startIndex":0,"totalResults":0,"format":"NVD_CVE","version":"2.0","timestamp":"2026-11-10T10:45:29.191","vulnerabilities":[]}

Other vendors. These are the Edge and Brave lines. Neither names a CVE, so neither is shown to be about this bug.

Microsoft is aware of the recent exploits existing in the wild. We are actively working on releasing a security fix.
Upgraded Chromium to 157.0.8103.39.

The question the post leaves open

Google says an exploit exists, credits the report to an anonymous source, and ships the fix 3 days later with no indicator, no actor and no method. What would a defender have looked for in their own logs before 9 November, and who outside Google can say whether their users were among the targets?

Key facts