Google has patched an actively exploited Chrome flaw across desktop and Android. Managed fleets need to run Chrome 153 at or above 153.0.8010.36 on Linux and Android, or 153.0.8010.36 or .37 on Windows and macOS, to receive the fix.
The flaw, CVE-2026-87491, is a medium-severity out-of-bounds write in V8, Chrome’s JavaScript and WebAssembly engine. Google states: “Google is aware that an exploit for CVE-2026-87491 exists in the wild.” CISA’s September 9 catalog entry gives federal civilian agencies a September 23 remediation deadline.
Crafted HTML reaches V8 memory
An out-of-bounds write occurs when software places data beyond the memory region intended to hold it. That can corrupt neighboring data or control state. CISA says a remote attacker can trigger this flaw through a crafted HTML page and execute arbitrary code inside Chrome’s sandbox.
Google and CISA have not said whether the public exploit escapes the sandbox or identified another vulnerability in an exploit chain. Google is also keeping the underlying bug details restricted while fixes reach users, so the public record does not expose the triggering V8 operation or a reliable exploit signature.
Jihyeon Jeong of Seoul National University’s Compsec Lab reported the bug on August 6 while working as a research intern. Google listed a $2,500 reward. The same Chrome 153 release contains 230 security fixes, but CVE-2026-87491 is the one Google explicitly identifies as having an exploit in the wild.
Fixed builds span four platforms
Google’s desktop release moved Linux to 153.0.8010.36 and Windows and macOS to 153.0.8010.36 or 153.0.8010.37. Its Android release moved Chrome to 153.0.8010.36 and says Android releases contain the same security fixes as their corresponding desktop releases unless Google notes otherwise.
Long description
The comparison matrix has rows for Linux, Windows, macOS, and Android. Linux points to Chrome 153.0.8010.36 and then to an active-process check. Windows and macOS point to 153.0.8010.36 or 153.0.8010.37 and then to a relaunched-process check. Android points to 153.0.8010.36 and then to an active-app check. Every verification box says that state reports a fixed build. A note explains that operators must measure the active browser version to confirm that a downloaded or staged update is running.
Both notices describe staged distribution. Desktop rolls out over days or weeks; Android becomes available through Google Play over several days.
Operators still need to confirm that the available update has been installed. They must also check that the old browser process has exited and the fixed code is running.
Other Chromium-based browsers may share the vulnerable engine code, as CISA notes, but Chrome’s build numbers do not establish Edge, Opera, or another vendor’s fix status. Their release records remain the authority for those products.
Public indicators remain unavailable
Google and CISA confirm exploitation without describing the attackers, targets, delivery path, exploit chain, victims, or geography. They publish no malicious domains, page patterns, crash signatures, file artifacts, or telemetry markers. CISA lists ransomware-campaign use as unknown and does not require forensic triage for this catalog entry.
That leaves defenders with a strong exposure check and a weak historical-compromise check. Browser crashes, renderer failures, unexpected child processes, and endpoint alerts may justify investigation in local context, but none is a published indicator for CVE-2026-87491. Treating those generic events as signatures would create false confidence in both positive and negative results.
Google’s restricted bug record may change this position after most users have updated. A disclosed proof of concept, attack telemetry, or incident report would supply the recognition evidence that is absent today. Until then, update affected browsers and preserve suspicious surrounding telemetry. With no published indicators, a clean indicator search cannot rule out exploitation.
Verify active browser versions
Collect the running Chrome version from managed Windows, macOS, Linux, and Android devices. Update and relaunch desktop browsers below the fixed line. On Android, confirm Google Play completed the rollout and the active app reports the new version.
Repeat the collection after the deployment window. The expected result is 153.0.8010.36 or later on Linux and Android, plus 153.0.8010.36, 153.0.8010.37, or a later release on Windows and macOS. Give every lagging device an owner and disposition; restrict ordinary browsing on systems whose update path cannot reach a fixed build.
The measured running version confirms that the vendor fix is active. It does not reconstruct what an earlier browser process encountered. Preserve relevant process, crash, network, and identity telemetry when another alert makes prior exploitation plausible, and reopen the incident question when Google, CISA, the researcher, or a responding organization publishes specific recognition evidence.
A successful rollout ends with fixed running versions across the in-scope fleet. Those version checks confirm the patch is running; earlier exploitation still requires investigation.