SURIQ
Chrome versions before 157.0.8103.50 contain CVE-2026-125350, a use-after-free bug in the browser's XML component that attackers are already exploiting, and the fix is to get every Chromium copy you run onto 157.0.8103.50 or later. For desktop Chrome that is a restart. The harder part is the headless Chromium sitting on servers, which no browser auto-update ever touches.
Google shipped the fix in its November 9 stable channel update and said an exploit exists in the wild. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on November 10, giving US federal agencies until November 24 to remediate. CISA's entry notes that Microsoft Edge, Opera and other browsers built on Chromium can carry the same bug.
Which Chrome versions does CVE-2026-125350 affect?
Every Chrome build before 157.0.8103.50 is affected, according to the NVD record Google filed as the CVE authority. Linux gets 157.0.8103.50; Windows and macOS get 157.0.8103.50 or .51. A crafted HTML page can trigger the use-after-free, a memory bug where code keeps using memory after releasing it, and run attacker code inside the renderer sandbox.
Google rates it High, and the CVSS 3.1 score is 8.8. The score assumes the victim has to load the page, which is why it stops short of critical. For a browser that loads untrusted pages all day, that condition is not much of a barrier. A researcher who asked to remain anonymous reported the bug on November 6, per SecurityWeek, whose running tally makes it the eighth exploited Chrome zero-day of 2026. Google has not said who is using it or against whom. CISA lists ransomware use as unknown.
Three days passed between the report and the fix, and the KEV listing followed a day later. The gap that matters now is between Google's release and the moment each copy of Chromium in your estate is running it.
Why a browser bug belongs on a server checklist
Most coverage of this zero-day treats it as an endpoint story: update Chrome, relaunch, done. Hosting and web teams carry a second copy of the same engine that never shows up in that advice. PDF invoice generators, screenshot and link-preview services, SEO crawlers and end-to-end test runners all drive headless Chromium, and many of them render pages a customer or a stranger supplied. That is the exact precondition this bug needs: a crafted page reaching the renderer.
Those copies do not update like a desktop browser. Automation libraries such as Puppeteer and Playwright download a pinned browser build into a cache directory and keep it until someone bumps the library version. Container images freeze whatever Chromium was current on the day they were built. Neither path reads Google's release blog, and neither is visible to the OS package manager, the same blind spot we tallied in six fixes that sat outside the package manager in a single week.
The sandbox caveat also weakens on servers. "Code execution inside the sandbox" is a contained outcome on a laptop, where an attacker still needs a second bug to escape, the way the Bad Epoll kernel flaw was used to go from sandbox to root. Container setups often launch Chromium with the --no-sandbox flag to avoid permission errors. On those hosts the renderer runs with the full rights of the process that started it, so there is no inner wall left to escape.
Find every Chromium below 157.0.8103.50
On desktops, open chrome://version and confirm the build, then relaunch: Chrome downloads updates in the background but only applies them on restart. Edge, Opera, Brave and other Chromium browsers ship their own fixes on their own schedule, so check each vendor's release notes rather than assuming Chrome's version number carries over. On Linux servers, the sweep below lists every Chrome or Chromium binary on the filesystem with its version, including copies unpacked into automation caches.
find / -xdev -type f -perm -u+x \( -name chrome -o -name chromium -o -name chromium-browser -o -name chrome-headless-shell -o -name headless_shell \) 2>/dev/null | while read -r b; do printf '%s ' "$b"; "$b" --version 2>/dev/null || echo "(no version output)"; done ls -d ~/.cache/puppeteer/chrome*/* ~/.cache/ms-playwright/* 2>/dev/null grep -rl -- "--no-sandbox" /etc/systemd /opt /srv /var/www 2>/dev/null
The first command catches distro packages, Google's packages and bundled copies alike. The second shows which pinned builds your automation libraries have cached for the current user; run it as each service account that drives a headless browser. The third flags configs that launch Chromium with its sandbox disabled, which are the hosts to fix first. Tracking that inventory continuously across a fleet is the job of vulnerability detection, but this sweep finds the stragglers today.
If a headless renderer cannot be rebuilt today
Updating a pinned browser usually means bumping a library and redeploying, which can take longer than a desktop restart. Until that ships, narrow what the renderer will load. Restrict it to your own templates or an allowlist of domains instead of arbitrary customer URLs, run it as an unprivileged user in a container with the sandbox turned back on, and keep it off internal networks so a compromised renderer has nowhere useful to go.
Google has withheld exploitation details, and no indicators of compromise have been published, so there are no signatures to match. MITRE ATT&CK files this delivery method under Drive-by Compromise (T1189). The observables worth watching are renderer crashes on a headless host followed by unexpected child processes, and outbound connections from a rendering service to destinations it has no reason to contact. Treat any of those on an unpatched host as a lead to investigate, not just a crash to restart.
This is the second exploited Chrome engine bug we have covered since September, after the V8 type confusion CVE-2026-85046. Google's release cadence has been getting faster, as we noted when its AI-assisted bug fixing doubled the patch pace. The slow link is no longer Google. It is the forgotten Chromium inside a service you deployed last year and never rebuilt.