Chrome 157.0.8103.50 Fixes 9 Flaws, One Under Active Attack

Google pushed Chrome's stable channel to version 157.0.8103.50/.51 on Windows and Mac and 157.0.8103.50 on Linux on Monday, November 9, 2026, the first security update for the Chrome 157 branch since it launched on November 3. The update patches nine security bugs, seven of them rated High severity, and Google says one of them – a use-after-free flaw in Chrome's XML handling tracked as CVE-2026-125350 – already has a working exploit circulating in the wild. The update is rolling out gradually over the coming days and weeks, so if you don't see it immediately, check back or force the check described below.

What shipped in the November 9 update

Chrome 157 itself first reached the stable channel on November 3, 2026, at version 157.0.8103.38/.39. The build published on November 9 is not a new major version – it's the first stability and security patch batch for that same 157 branch, bumping the build number to 157.0.8103.50/.51 for Windows and Mac and 157.0.8103.50 for Linux. Google confirmed the update on the official Chrome Releases blog, noting that the rollout "will roll out over the coming days/weeks" rather than hitting every installed copy of Chrome at once. A full list of code changes in the build is available in Google's internal change log, which the company links from the same post.

Google's update post was credited to Srinivas Sista of the Google Chrome team, and it follows the pattern Chrome has used all year: a major version ships, then a focused security-only update follows roughly a week later to close out whatever vulnerabilities were still in the review pipeline when the big release went out the door.

The 9 security fixes, in full

Google's "Security Fixes and Rewards" section lists nine entries this cycle: seven High-severity bugs and two rated Medium. As is standard practice, Google keeps some bug-tracker links and reward amounts restricted until a majority of users have updated, or until a fix lands in a third-party library other projects also depend on – which is why a couple of entries below show "N/A" or "TBD" for the reporter credit or bounty.

Google attributed the bug-tracker numbers and dates to its own internal security team for five of the nine issues, meaning Chrome's own engineers or automated fuzzing infrastructure caught them before anyone outside Google did. The remaining four came from external researchers: Arni Hardarson of Neonix Security, an anonymous reporter, and Vo Duc Thang, who uses the handle "ugvxb." Full technical write-ups for several of these bugs remain access-restricted on Chromium's public issue tracker while Google waits for the fix to reach most users, which is normal practice and not a sign anything is being hidden long-term.

The one bug Google says is already being attacked

The most urgent line in this release is a single sentence near the bottom of Google's post: "Google is aware that an exploit for CVE-2026-125350 exists in the wild." That bug is a use-after-free vulnerability in Chrome's XML processing code, reported anonymously on November 6, just three days before the fix shipped. Google has not published technical details of how the flaw is being abused, how widely, or against whom – which is consistent with its usual approach of restricting exploit details until the patched build has reached a majority of users. You can track the underlying report on Chromium's public issue tracker, though the technical body of the report itself is still sealed as of publication.

A second use-after-free in the same XML component, CVE-2026-125346, was fixed in the same update after being reported by external researcher Arni Hardarson in October; Google has not said whether the two bugs share a root cause, and nothing in the release notes links them. Full details on that report are also tracked on Chromium's bug tracker.

In-the-wild exploitation of a Chrome bug is not a routine occurrence – most of the dozens of CVEs Chrome patches every month are found internally or by bug-bounty researchers well before anyone weaponizes them. When Google explicitly flags active exploitation, as it has here, security teams generally treat that as the strongest possible signal to update immediately rather than waiting for an automatic background update to land on its own schedule.

What the other High-severity bugs touch

Beyond the exploited XML bug, the High-severity list spans several of the components that most commonly turn up in Chrome's security bulletins. CVE-2026-125345 is an uninitialized resource issue in WebGL, the browser's hardware-accelerated 3D graphics API – a class of bug that can sometimes be used to leak memory contents through a malicious web page. CVE-2026-125347 involves incorrect authorization in the FileSystem API, which governs how web pages request access to sandboxed storage. CVE-2026-125343 is a buffer overflow in Chrome's compositing pipeline, the layer that assembles what actually gets drawn to the screen, and CVE-2026-125348 is an out-of-bounds write in the GPU process. CVE-2026-125344, a type confusion bug in V8 (Chrome's JavaScript engine), rounds out the internally discovered High-severity fixes; type confusion bugs in V8 have historically been among the more serious classes of Chrome vulnerability because they can sometimes be chained into full remote code execution.

The two Medium-severity bugs, CVE-2026-125349 and CVE-2026-125342, both involve uninitialized resources in the GPU process – conceptually similar to the WebGL issue above, but assessed by Google's security team as less severe or harder to reliably exploit.

How Google catches these before shipping

Google's release post credits much of this detection work to automated tooling rather than manual review alone: AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, and AFL are all named as the instrumentation Chrome's build and test infrastructure runs continuously to catch memory-safety and undefined-behavior bugs before they ever reach a stable release. That pipeline is why five of this cycle's nine fixes were found internally rather than reported by outside researchers – it's effectively Chrome fuzzing itself at scale, around the clock. External researchers who do find something first are compensated through Chrome's Vulnerability Rewards Program, which is the same page Google points to for anyone who wants to report a new issue or learn how reward amounts are determined.

How this fits into Chrome's release rhythm

Chrome ships a new major version roughly every four weeks, and this is now a familiar pattern: Chrome 157 launched November 3 with new features and platform changes, and less than a week later, a dedicated security update followed to close out vulnerabilities that were still working their way through Google's disclosure process when the initial 157 build locked. Pandromeda covered the same cadence last month when Chrome 156 shipped 52 security fixes, and the version before that followed the pattern Pandromeda detailed when Chrome 155 first reached the stable channel. Nine fixes is a comparatively light batch next to some of Chrome's larger monthly updates – Chrome 156's security update alone fixed 52 bugs, four of them critical – but raw bug count isn't the right way to judge urgency. A release with one actively exploited High-severity bug is arguably more pressing for an ordinary user to install quickly than a release with dozens of fixes for issues nobody has yet weaponized. Chrome's security team has said in the past that it treats "is this already being exploited" as a far stronger signal for urgency than the total number of CVEs in a given release, and this cycle is a clean example of that principle in practice: fewer bugs overall, but one of them demonstrably more dangerous than anything in the previous update.

Google isn't the only major software vendor leaning harder on automated security tooling and faster patch cycles this year; Pandromeda's software desk has also tracked how Google's own developer tooling has been evolving at a similarly rapid pace, part of a broader industry shift toward shipping fixes continuously rather than in rare, large batches.

What to do next: check and force your Chrome update

Because the rollout is staged rather than instant, you may not see the update the moment you read this. Here's how to check your version and, if needed, push the update yourself:

1. Check your current version: open a new tab and go to chrome://settings/help, or click the three-dot menu > Help > About Google Chrome. Chrome will automatically check for an update as soon as that page loads.
2. Confirm the fixed build: you want to see 157.0.8103.50 or higher on Windows, Mac or Linux (157.0.8103.51 is also valid on Windows/Mac). Anything lower than .50 does not yet contain these nine fixes.
3. Relaunch when prompted: Chrome downloads updates in the background but only applies them after you click the "Relaunch" button that appears on that same settings page, or the next time you fully close and reopen the browser.
4. If you don't see an update available: the staged rollout means your copy of Chrome may simply not have been offered the update yet. Checking again in a day or two, or downloading the latest installer directly from Google's official Chrome download page, will get you current.
5. On managed or enterprise devices: IT administrators may control rollout timing through Chrome Browser Cloud Management; if your version doesn't update on its own, check with your organization's IT or security team rather than installing manually.

Given that Google has confirmed active exploitation of CVE-2026-125350, this is a good update to apply promptly rather than letting it sit in the background queue, particularly on any machine that handles sensitive browsing, work accounts, or financial logins.

Quick answers before you update

A few things worth clarifying before you go check your version number. First, 157.0.8103.50/.51 is not a new major version of Chrome – it's a security patch on top of the Chrome 157 branch that launched November 3. The jump from .38/.39 to .50/.51 is the build number increasing, not the "157" changing. Second, "exploited in the wild" specifically means Google's own threat-intelligence or security teams have found evidence that CVE-2026-125350 is being used against real users somewhere, not just that a proof-of-concept exists in a research paper or conference talk. Google is deliberately vague about scope and targeting for bugs like this until the patch has had time to reach most of the installed base, which limits how useful the exploit remains to attackers once it's public knowledge that a fix exists. Third, severity ratings like "High" and "Medium" reflect Chrome's own internal assessment of how a bug could be abused and how much damage it could do, not a universal score like the CVSS numbers NVD assigns – Google traditionally ships its own severity label in the release post well before, if ever, a numeric CVSS score shows up on a public database entry for the same CVE.

Full answers to the most common follow-up questions, including what to do if the update doesn't appear right away, are in the FAQ section at the end of this article.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage