Chrome CVE-2026-87491: close the gap between an installed update and a relaunched browser

What it is

Status as of 25 October 2026. Google's desktop release notice dated 8 September 2026 lists CVE-2026-87491, an out-of-bounds write in V8, and confirms exploitation in the wild. Its security releases are 153.0.8010.36 for Linux and 153.0.8010.36/.37 for Windows and Mac. These are the documented remediation releases, not a claim about the newest available browser. Re-check subsequent Stable notices and enterprise policy documentation before deployment; the cited notice has no separate visible revision date.

Why it matters

Google's update documentation distinguishes downloading an update from applying it through a browser restart. A fleet can therefore distribute the package while users continue browsing with an older process. Google's recommended-relaunch setting permits users to dismiss the prompt and continue using that old version. A required relaunch addresses this operational gap.

The following is a proposed closure workflow. Its evidence consists of the browser's displayed version, the effective policies and the relaunch result; it does not infer compromise from a version number or from a browser crash.

How to apply

• Identify the actual browser. Record the operating system, release channel and version displayed under Help > About Google Chrome. Compare against the applicable vendor release, then choose a current supported security baseline. Keep the Linux release number separate from the Windows/Mac pair.
• Permit delivery. On managed Windows devices, inspect Google Update > Applications and the Google Chrome application policy. Enable the update-policy override with updates allowed. Check for a target-version pin that prevents reaching the security baseline. Google warns that pins should be temporary. Linux administrators must deliver browser updates through their package manager.
• Require activation. Configure RelaunchNotification as required, value 2, and set RelaunchNotificationPeriod to the organization's approved deadline in milliseconds. Review RelaunchWindow alongside that deadline: scheduling a window can defer completion. Notify users so they can save unfinished work before enforcement.
• Verify effective configuration. After deploying policies and relaunching, open chrome://policy, select Reload policies and inspect RelaunchNotification, RelaunchNotificationPeriod and RelaunchWindow. Google specifies an OK status and values matching the intended policy. Investigate overrides instead of assuming the management console reflects the endpoint.
• Close with runtime evidence. Revisit About Google Chrome after relaunch and record its displayed version. Keep devices with failed downloads, pending restarts or missing inventory as unresolved exceptions. Record an owner and the next remediation action for each exception.

Pitfalls

Do not treat a relaunch notification as proof that a relaunch occurred. Google also notes that Windows computer policies require domain membership or device management. A configured policy on an unmanaged machine is insufficient evidence. The September version numbers establish a historical fix boundary, not permission to freeze there indefinitely. This article makes no claim about the vulnerability's ordinal position among the year's zero-days. No exploit reproduction is needed to verify deployment.