Chrome Zero-Day CVE-2026-87491: What to Update and What Is Known

Quick answer

CVE-2026-87491 is an out-of-bounds write in V8, the engine used by Google Chrome to run JavaScript. Google's 8 September 2026 Chrome Stable release lists it as Medium severity and says it is aware that an exploit exists in the wild. That bulletin announced Chrome 153.0.8010.36 for Linux and 153.0.8010.36/.37 for Windows and Mac as Stable releases containing security fixes. The official CVE record describes the issue in Chrome versions before 153.0.8010.36 and says a crafted HTML page could execute code inside the sandbox. “Inside the sandbox” does not mean the browser host was automatically fully compromised.

What to do: update Chrome to the latest Stable version offered for your device, then relaunch it so the running browser actually uses the updated build. If you manage a fleet, confirm installed and running versions per supported platform; update packaged browsers and affected derivatives according to their own vendors' bulletins. Do not infer that every user of an older build was attacked.

Which date and platform information can be trusted?

Because public pages can outlive one release cycle, a good security guide separates the historic first fixed build from the current latest version. Never tell readers to downgrade from a newer Chrome version to a September build. Similarly, do not assume Chrome 153 details automatically apply to another Chromium-based product without its vendor's own advisory.

Google's separate 1 October 2026 desktop Stable bulletin lists 154.0.8037.97/.98 for Windows and Mac and 154.0.8037.97 for Linux, with a gradual rollout. Those October builds supersede the September announcement; the currently offered supported Stable build on a reader's device should always be checked again before updating. [3]

• Google's release date — 8 September 2026. — This is a September fix, not a 3 October zero-day announcement.
• Chrome Stable at the time — 153.0.8010.36 (Linux); 153.0.8010.36/.37 (Windows/Mac). — Rollout can take time; a later version may supersede these builds. Verify the current Stable bulletin before publishing an update instruction.
• Component and flaw — V8 out-of-bounds write. — Do not describe a confirmed escape from Chrome's sandbox without separate evidence.
• Exploitation — Google says it is aware that an exploit exists in the wild. — The bulletin does not name victims or an attack campaign.
• Scope of the CVE record — Chrome before 153.0.8010.36; crafted HTML could execute code inside the sandbox. — This record alone does not prove theft of passwords or persistence on an individual device.

How does the flaw relate to visiting a page?

V8 processes JavaScript and WebAssembly in webpages. An out-of-bounds write means the engine may write data beyond an intended memory region under certain conditions. The CVE description associates this flaw with specially crafted HTML and code execution within Chrome's sandbox. The public record reviewed here does not include an exploit walkthrough, reliable victim count or verified full-device takeover chain. Google may restrict bug details until enough users are updated. An educational article should explain what to patch rather than reproduce a weaponized test.

“Zero-day” in this context describes exploitation evidence known to the vendor at or before release of a fix. It is not a statement that every install is presently compromised. An organization should prioritize the update because Google itself flags an in-the-wild exploit, not because a site can prove its own visitors have been targeted.

How to check and install the update

On a desktop Chrome installation, open the browser's menu and navigate to Help → About Google Chrome. Allow Chrome to check for an update, then Relaunch when prompted. Confirm the version shown after relaunch and ensure it matches the latest release appropriate for the operating system and update channel. Some managed devices get Chrome through an enterprise policy or OS package instead; follow the organization's supported deployment channel rather than trying to bypass policy. This navigation is a generic user procedure, not a claim that a specific September version is the current build for all users.

For a device fleet, collect the OS, Chrome channel, installed build, active running build and last successful restart. Prioritize exposed browsing devices and systems where browser content can reach sensitive sites or credentials. A package download alone is not proof of protection if the running process is still the older version. Record update rollout failures and retest out-of-date endpoints after the assigned maintenance window. Preserve IT change records; don't paste employee browser histories into a public ticket.

What if an update is not available yet?

First verify which browser and release channel is actually installed. The September Google announcement says the stable builds would roll out over the coming days or weeks. A delay may reflect channel, enterprise policy, platform packaging or a failed check. Do not claim an unsupported version number is safe. An administrator can use the vendor's official Chrome release and management channels to validate distribution; a consumer can check again and avoid untrusted “emergency patch” downloads from messages or advertisements. If a vendor-owned device is stuck, escalate to its administrator with the observed build and date; avoid bypassing managed update controls.

If you use another Chromium-based browser, follow that vendor's security release and version guidance. Shared components do not guarantee identical shipping or rollout dates, and this Chrome advisory should not be copied into a universal version matrix for all products.

If compromise is suspected, separate signs from proof

An outdated Chrome build and a malicious webpage in browsing history can justify investigation, but neither alone proves exploitation of this CVE. Gather managed endpoint alerts, process telemetry, browser crash and update logs, download and network records and the time of suspected malicious navigation. Preserve relevant artifacts under the organization's retention/privacy rules. Escalate to a qualified incident responder before wiping a device where doing so would destroy evidence.

Assess whether there is any separately observed sandbox escape, credential use, persistence or data export. The CVE's public description stops at code execution inside the sandbox, so do not label a password theft or whole-device compromise as a confirmed outcome merely because the browser was outdated. A patch prevents exposure to the flaw in updated builds, but it cannot retroactively prove whether a historical attack occurred.

India and general browser-hygiene context

India-based readers can use the same software-update principle: keep supported browsers current, do not install browser updates from a phishing attachment and report a confirmed or strongly suspected security incident through their organization's response channels. Applicability of any CERT-In reporting category depends on the entity and facts of an incident; a publicly disclosed CVE is not by itself a personal reporting determination. The CYBERoinfo zero-day explainer covers the difference between vulnerability disclosure and observed compromise, while the beginner cyber-hygiene guide offers routine update practices.

Questions readers ask

Is CVE-2026-87491 real? Yes. Google lists it in its September Stable bulletin, and it has an official CVE record.

Was it exploited? Google said it was aware of an exploit in the wild. This is a vendor statement about exploitation, not a public list of impacted companies or people.

Is 153.0.8010.36 the latest build now? Do not assume so. It was the Linux Stable version announced on 8 September. Follow the latest stable update offered for your operating system/channel.

Did the flaw break out of the browser sandbox? The official CVE description mentions code execution inside the sandbox. Any separate escape or full-host effect requires different evidence.

Decision checklist

• Verify the installed browser, operating system and Stable or managed enterprise channel before selecting an update.
• Use the vendor's supported Chrome update method and relaunch; confirm the running build after relaunch.
• Use the 8 September bulletin for first-fixed-build history, not as a current-latest-version claim.
• Check Google's latest Stable bulletin for the platform; the 1 October 154.0.8037.97/.98 update superseded September's announced build.
• For managed fleets, track device, installed build, running build, rollout status and restart completion without public browsing-history exposure.
• For other Chromium browsers, use their own vendor's version and patch guidance rather than copying Chrome's matrix.
• If exploitation is suspected, preserve endpoint evidence and separate in-sandbox code execution from any separately proven host compromise.

Limitations

• Google's 8 September bulletin states that an exploit exists in the wild but does not name victims or a campaign.
• The CVE describes code execution within the sandbox; full-host takeover or a sandbox escape needs separate evidence.
• September's Chrome 153 fixed versions were historical release builds and should not be described as latest on 3 October.
• Google's 1 October Chrome 154 Stable bulletin was the latest desktop bulletin found during this review, but rollout and future versions vary by device/channel.

Evidence sources

1. Google Chrome Releases — Stable Channel Update for Desktop (8 September 2026)
2. CVE Program — CVE-2026-87491 vulnerability record
3. Google Chrome Releases — Stable Channel Update for Desktop (1 October 2026)