---
title: "A Browser Zero-Day Is a Test of Your Company’s Response Time"
url: "https://florea.xyz/chrome-zero-day-response-time/"
date: "2026-11-10T16:30:16+02:00"
updated: "2026-11-10T16:30:16+02:00"
author: "Bogdan Florea"
topic: "Security"
---

# A Browser Zero-Day Is a Test of Your Company’s Response Time

On November 9, Google released a [Chrome security update](https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop_018223192.html) that fixes CVE-2026-125350, a high-severity use-after-free bug in Chrome's XML code. Google's release note says it "is aware that an exploit for CVE-2026-125350 exists in the wild." The bug was reported on November 6, so Google shipped the fix three days later.

For a business, the fix existing is the easy part. The hard part is getting it running in the browsers your people actually use, and knowing that it is. That's a test of how quickly your company responds, and it's worth taking honestly.

**TL;DR**

- The response is done when the fixed browser is running, not when the update has downloaded or a deployment task says complete.
- Google rolls the fix out "over the coming days/weeks", and by default Chrome only changes its menu icon until someone relaunches it. Waiting for automatic updates can take a while.
- Count devices in four groups: running a fixed build, waiting for an update or a relaunch, approved exceptions, and unknown. Don't fold the unknowns into the success rate.
- Set the relaunch deadline on purpose. Chrome's managed setting that forces a relaunch defaults to seven days.
- Patching closes the flaw. It doesn't tell you whether anyone used it before you patched.

## Which version counts as fixed

The fixed build depends on the platform and the release channel:

| Channel | Platform | Fixed in |
| --- | --- | --- |
| Stable | Windows and Mac | 157.0.8103.50 or .51 |
| Stable | Linux | 157.0.8103.50 |
| Stable | Android | 157.0.8103.50 |
| Extended Stable | Windows and Mac | 156.0.8078.96 |

Extended Stable is the slower channel some organizations use to change major versions less often. Its own [November 9 release](https://chromereleases.googleblog.com/2026/11/extended-stable-update-for-desktop_0910980127.html) includes the same fix. So a rule like "anything below 157 is vulnerable" would flag machines that are already fixed.

Chrome for Android 157.0.8103.50 came out the same day. Google says Android releases carry the same security fixes as the matching desktop release unless it notes otherwise, and it noted nothing here. ChromeOS has its own release track, so check it separately. Other browsers built on Chromium get their fixes from their own vendors, on their own schedules. A Chrome build number says nothing about them.

## The response ends with the running browser

Chrome updates itself, but not instantly. Google says both releases "will roll out over the coming days/weeks." Once an update has downloaded, it still waits for a relaunch: "The update applies the next time you restart Chrome," says [Google's help page](https://support.google.com/chrome/answer/95414). Someone who keeps the browser open for a week runs the old version for that week, whatever the deployment report says.

So I'd split the response into four steps, because each one can stall on its own and may have a different owner:

- **Notice.** Someone sees the advisory and decides it applies to you.
- **Download.** The update reaches the device.
- **Apply.** The browser relaunches on the new version.
- **Verify.** You have evidence that the device runs a fixed build.

On a single machine, opening About Chrome shows the running version and makes Chrome check for updates. That helps one person. It isn't fleet evidence.

## Know what the percentage represents

"97% updated" sounds good until someone asks what the other 3% are, and what the 100% was counted from.

The right denominator is every device that reaches company systems, including the ones you don't manage, with a clear rule for contractors and personal devices. A laptop that's been offline for two weeks isn't patched or unpatched. It's unknown, and it stays on the list until it reports again.

I'd report four groups:

- devices running a fixed build;
- devices waiting for the update or for a relaunch;
- approved exceptions, each with an owner and a review date;
- devices in an unknown state.

The last group is the one to watch. Folding it into the success number makes the report easier to present and harder to act on.

Every version reading also needs a timestamp. A device that last reported its version before November 9 tells you nothing about whether it's fixed now.

## Decide how much interruption you'll accept

Relaunching a browser sounds trivial. It isn't, for someone in the middle of a support call, a customer demo or a long form they can't easily get back. Those costs are real. The answer to them is a plan, not an open-ended delay: tell people when the relaunch is coming, help the ones who are blocked, and write down exceptions with an owner and a review time.

Chrome's [managed relaunch policies](https://support.google.com/chrome/a/answer/7679871) let you choose how hard to push:

- **Not set (the default):** the menu changes subtly, and nothing more.
- **Recommended:** a recurring warning that people can dismiss to put the relaunch off.
- **Required:** a recurring warning, then a forced relaunch when the notification period ends. Chrome restores the user's session afterwards.

The notification period defaults to seven days and can be as short as an hour. Seven days may be fine for a routine release. For a bug that's already being exploited, the period is a decision to make on purpose, not a default to inherit. I wouldn't turn a particular number of hours into a rule for everyone, though. The right deadline depends on who is exposed, what a forced relaunch would break, and what you can actually enforce.

Devices you don't manage need a decision too: under what conditions they can still reach business systems. Any restriction should be proportionate, come with help for the people affected, and be lifted once the device's state is known.

## Give leadership a short response record

The question I'd ask is whether the team can produce a record like this without inventing the process during the incident:

| Question | Evidence needed |
| --- | --- |
| What are we responding to? | The vendor advisory, the affected platforms and channels, and the fixed builds. |
| Which devices need action? | A current inventory, with unknown devices listed separately. |
| Who is responsible? | A response owner, the people handling deployment and user support, and an escalation path. |
| Has the change taken effect? | The running browser version on each device, with a recent timestamp. |
| What remains unresolved? | Named exceptions, blocked updates, offline devices, and the next review time. |

Record three times: when the fix was released for each channel, when you acted, and when the fixed build was confirmed running. The gaps between them show where your response is slow.

## Keep patching and investigation apart

Google's statement doesn't mean your company was attacked. And a successful update isn't evidence that nobody used the flaw before it.

Whether to investigate is a separate decision for the response owner, based on your exposure and the security evidence you have. The update closes the known flaw. It says nothing about what may have happened before.

That's what makes this a useful test. Can your company turn a vendor warning into a verified change quickly, without stopping people from working? A credible answer names the devices confirmed on a fixed build, the uncertainty that's left, and the person responsible for closing it.