One of the fixes in Google's November 9 Chrome release closes a flaw that attackers are already using. The Chrome desktop Stable build is 157.0.8103.50 or 157.0.8103.51 on Windows and Mac, and 157.0.8103.50 on Linux. Google is releasing it over the coming days and weeks, so two computers in the same office can be on different versions this week.

The exploited flaw sets the pace

Google's release post says it is aware that an exploit for CVE-2026-125350 exists in the wild. Google rates the flaw High, and CISA describes it as a use-after-free vulnerability in Chromium's XML component that could let a remote attacker run code inside the browser's sandbox through a specially crafted webpage.

CISA classifies it as CWE-416. MITRE's Common Weakness Enumeration explains that a use-after-free happens when software keeps using a reference to memory after that memory has been released. The memory may by then hold something else, so the stale reference can corrupt data, leak information, crash the program or, if an attacker controls what now sits there, redirect execution to malicious code.

The exploit description says the code would run inside the browser's sandbox, which limits what it can reach directly. It is still an attack that works through an ordinary webpage, and a flaw that is already being used is one to close quickly.

CISA added the flaw to its Known Exploited Vulnerabilities catalog on November 10 with a due date of November 24. That deadline applies only to federal civilian executive branch agencies. CISA's catalog page says organizations should use the catalog as an input to their vulnerability management prioritization. For a small office, the sensible target is this week, not whenever browsers next happen to restart.

Google's post counts nine security fixes but lists eight CVEs, six rated High and two rated Medium, in XML, WebGL, GPU, V8, Compositing and FileSystem. Google may keep bug details restricted until a majority of users have the fix.

Know which version to look for

The version that counts depends on the device and the release channel it uses:

  • Chrome Stable on Windows or Mac should show 157.0.8103.50, 157.0.8103.51 or later.
  • Chrome Stable on Linux should show 157.0.8103.50 or later.
  • Chrome Extended Stable on Windows or Mac should show 156.0.8078.96 or later, a build whose post lists 11 security fixes, including CVE-2026-125350.
  • Google sent an early Chrome 158 build, 158.0.8127.18 or .19, to a small percentage of Windows users on November 4, with Mac to follow. That post does not mention security fixes, so treat a computer showing one of those builds as an open item and check it again in a few days.
  • Chrome 157.0.8103.50 for Android reaches Google Play over a few days, and Google says Android releases contain the same security fixes as the matching desktop release unless otherwise noted.
  • Chromebooks get Chrome through ChromeOS updates, as Google's help page notes, so they belong on their own checklist. The desktop release post does not describe a ChromeOS rollout.

Extended Stable is a separate channel with its own release posts, which is why it has its own version target. Browser updates arrive often, so treat this check as a routine rather than a one-off.

If you are unsure which channel a computer uses, ask whoever installed Chrome. Extended Stable is something an administrator chooses on purpose, with the Target Channel override setting in Google Update policy, so a laptop nobody has configured is normally on regular Stable.

A downloaded update is not a running one

For a small business, the practical question is how long an update sits waiting for a restart. Chrome can download an update while someone works, but Google's help page says Chrome usually updates when the browser is restarted. Until then the old version keeps running, so the relaunch, not the download, is the step to verify.

That is why a person who never closes Chrome is the most likely to be behind. Google's help page says that if you rarely close Chrome, a pending update may stay unapplied until you relaunch.

To check a single computer, have the person using it do this:

  • Open Chrome and select the three-dot More menu at the top right, then Help, then About Google Chrome.
  • Read the version number on that page.
  • Select Relaunch if it appears. Selecting Not now instead leaves the update waiting until Chrome next restarts.
  • If there is no Relaunch button and the number is still below the list above, check again the next day, since the rollout is staged.

What to tell staff

Send those steps with a deadline, such as noon today, and ask everyone to reply with the version number they see. Tell them to save anything typed into web forms first. Google says open tabs and windows reopen after a restart, but Incognito windows do not. On a managed computer, they should also follow any update prompts from the organization.

Add one warning. Chrome updates itself, so any web page, pop-up or email telling staff to download a browser update should be reported, not clicked. Updates arrive through the About page, not through a download from a link.

Settings for managed browsers

If your browsers are not managed through an admin console or policy, the staff note and a follow-up check are the whole process. The rest of this section applies to organizations that manage Chrome.

In the Google Admin console, go to Devices, then Chrome, then Settings. Open Chrome updates and select Relaunch notification. In Chrome Enterprise Core, the path starts at Chrome browser, then Settings. Google says this requires the Mobile Device Management administrator privilege. The options are No relaunch notification, Show notification recommending relaunch, and Force relaunch after a period. Without this setting, nothing pushes people to relaunch, so a pending update can wait for a long time.

In the Admin console the notification period can be set from 1 to 168 hours, and leaving it unset uses the 168-hour default, which is seven days. Google's help page also describes a relaunch window with a start time and a duration in minutes, which controls when relaunches begin once the period ends. The underlying policies are named RelaunchNotification, RelaunchNotificationPeriod and RelaunchWindow.

Seven days is a long wait when a flaw is already being exploited, so 24 to 48 hours is a reasonable forced period, though the staff note is still the quickest route for this release. Remember that a forced relaunch closes the browser on whoever is using it, so pick a period that gives people time to save work and, if you use a window, one that falls outside the working day.

To confirm the change, Google says to have users relaunch Chrome first, because the settings do not take effect until then. Then open chrome://policy on a managed computer, click Reload policies, select Show policies with no value set, and check that RelaunchNotification, RelaunchNotificationPeriod and RelaunchWindow show a status of OK with the values you set.

Check the whole fleet and chase exceptions

The Admin console's versions report, under Devices, then Chrome, then Reports, then Versions, shows how many browsers run each Chrome version. It needs Chrome browser reporting turned on and an administrator account with the Chrome administrator privilege. It only includes browsers that reported in the previous 28 days, so a laptop left unused for four weeks will not appear.

To keep a record, select Export at the top right. When the link appears under Your tasks, select Download CSV and open the file in a spreadsheet. Google notes that multiple browsers on one device, such as Stable and Beta, are counted separately, so a computer can appear twice.

Common reasons a computer falls behind:

  • A browser pinned with Target version prefix updates only after a version is fully released to Stable, so it can trail the staged rollout. Google says pins should be temporary.
  • An Update policy override set to Disable updates stops browser updates, and Google says it does not recommend turning them off.
  • A version that never moves may mean the computer is below Google's system requirements, currently Windows 10 or later on Intel processors (Windows 11 on Arm) and macOS 13 Ventura or later.
  • On Linux, Google's help page says Chrome is updated through the package manager, so a stalled system update also stalls Chrome.
  • A computer that is rarely switched on or rarely connected to the internet simply has not had the chance to update.

Microsoft Edge needs a separate check

CISA's catalog entry says the flaw could affect other browsers built on Chromium, including Microsoft Edge and Opera. Microsoft's Edge security release notes now show progress. On November 9, Microsoft said it is aware of recent exploits in the wild and is working on a security fix, without naming a CVE. On November 11, it listed Edge for Android version 157.0.4341.53 as including the fix for CVE-2026-125350.

For desktop Edge, the newest Stable entry in those notes as of November 11 is still version 157.0.4341.42, dated November 5, which is before Google's release and has no CVEs listed. Until Microsoft lists a fixed desktop build, keep desktop Edge as an open item, and add Opera or any other Chromium-based browser your staff use to the same list.

To check Edge, open Settings and more, then Help and feedback, then About Microsoft Edge, and select Restart if it appears. The Edge security notes page is not always in date order, so read the dates on each entry instead of trusting the position on the page.

Common mistakes and how to spot them

These habits leave a visible trace, so you can spot them.

  • Treating a downloaded update as installed. The sign is a More icon that has changed color, or an About page that shows a Relaunch button.
  • Checking only the main laptop. Spare laptops, a shared front-desk computer and a manager's home computer used for work are often missed. The sign is a version report with fewer browsers than the office has people.
  • Trusting the Admin console count alone. A computer that has not reported in 28 days is absent from the report, so compare the count to your equipment list.
  • Forgetting browsers other than Chrome. Edge, Opera and other Chromium-based browsers can carry the same flaw.
  • Following the wrong version list. A computer on Extended Stable is compared with 156.0.8078.96, not with the Stable build numbers.
  • Clicking a fake update message. The sign is a download prompt that comes from a web page or email rather than from the About page.

How to verify the result

Verification is a short list, and each item produces something you can record.

  • Every person has replied with a version number that meets or exceeds the target for their channel and operating system.
  • On managed computers, the versions report shows no browsers on the older builds, or each remaining one has a named reason.
  • On managed computers, chrome://policy shows the relaunch settings with a status of OK.
  • Android phones show the new Chrome version after updating from Google Play.
  • Desktop Edge is on a build that Microsoft's notes list as fixed, or it stays on the open list.

A worked example

Imagine a ten-person accounting office with eight Windows laptops and two Macs on Chrome Stable. The office manager sends the staff note in the morning and asks for version numbers by noon.

Seven computers report the new build. One shows an older number and a Relaunch button because its owner chose Not now, and a relaunch fixes it. One Mac shows a much older version with no Relaunch button and turns out to run a macOS release below Google's requirement, so it goes on the list for a macOS upgrade, or for replacement if the hardware cannot run macOS 13. The tenth person is out until Thursday, so that laptop goes on Thursday's list.

The manager also asks Android phone users to update Chrome from Google Play and notes which laptops run Edge. Two people use Edge for client portals, so those laptops stay on the open list until Microsoft's notes show a fixed desktop build. The day ends with a named list of exceptions instead of a guess.

Because the office uses the Admin console, the manager also changes the relaunch notification to Force relaunch after a period, set to 48 hours, so the next update does not depend on anyone remembering to restart.

Quick answers

A few questions come up in almost every office after a notice like this.

Staff do not lose their open tabs when they relaunch, because Chrome restores tabs and windows. Anything typed into a web form that has not been submitted, and any Incognito window, can still be lost.

A computer that cannot reach the target version because of its age is a replacement or operating system upgrade decision, not a browser setting. Until it is dealt with, restrict what it is used for.

What to do this week

  • Send the staff note with a deadline and collect version numbers.
  • Shorten the relaunch notification period on managed browsers.
  • Work through each exception, including Android phones, Chromebooks and Edge.
  • Recheck Microsoft's Edge security notes until they list a fixed desktop build.
  • Compare the versions report with your equipment list for computers that have not reported.
  • Review any Target version prefix pins and remove the ones nobody can explain.
  • Record what you checked and when, so the next update starts from a known list.

Where ALCO can help

If you would rather not run this check yourself, the ALCO help desk can work through it with your staff. It is staffed 24 hours a day, including holidays, and calls are answered by a person. ALCO lists Google Workspace among its services, described as covering Gmail, Drive, Calendar and the admin console, and mobile device management for managed phones and laptops. To talk it over in person, book a time first at the Caldwell office or call ahead.

Sources