Google has patched a Chrome vulnerability that attackers were already exploiting. Desktop fleets need Chrome 152.0.7977.82/.83 on Windows and macOS or 152.0.7977.82 on Linux, followed by a browser relaunch, to move past the exposed builds.
The flaw, CVE-2026-85046, is a high-severity type confusion in V8, the engine that processes JavaScript and WebAssembly. Google’s September 3 release states: “Google is aware that an exploit for CVE-2026-85046 exists in the wild.” It does not identify the attackers, their targets, the delivery path, the exploit chain, or any completed harm.
Exploitation precedes public detail
Type confusion means code handles a value as the wrong kind of object. In a memory-managed engine such as V8, that mismatch can corrupt the assumptions used to read, write, or free memory. Google has kept the bug record restricted while users receive the fix, so the public record does not establish what primitive the exploit gains or whether another vulnerability is needed to escape Chrome’s sandbox.
That boundary matters because active exploitation establishes urgency without establishing prevalence. Google did not quantify attacks, victims, affected organizations, or geography. It also did not publish indicators, telemetry patterns, lure details, or a reliable test for prior compromise.
Security researcher Salvatore Gulizia, also known as Serotav, reported the flaw on August 4. Google assigned a $1,000 reward. The company’s release packages this fix with 11 other security repairs, but CVE-2026-85046 is the only flaw in the notice that Google explicitly says has an exploit in the wild.
Long description
The figure compares three desktop platforms. Windows and macOS move from any earlier Chrome 152 build to 152.0.7977.82 or 152.0.7977.83. Linux moves to 152.0.7977.82. Every row ends with the same activation step: relaunch the browser, then confirm the running version. A boundary note says the version check proves patch state but cannot determine whether exploitation happened before the update.
Fixed builds define exposure
Google’s version lines give defenders a practical exposure boundary. Windows and macOS devices below 152.0.7977.82 are behind the fixed release. Linux devices below 152.0.7977.82 are also behind it. Version 152.0.7977.83 is an additional fixed build listed for Windows and macOS.
The rollout occurs over “the coming days/weeks.” An endpoint that reports no update yet is therefore not proof that it is current. Managed-browser teams should compare policy and software inventory against the running build, then investigate why a device remains below the fixed version. The relevant causes may include a staged deployment ring, a pinned package repository, a disabled updater, an offline endpoint, or a restart that never happened.
The release covers Chrome Stable on Windows, macOS, and Linux. Google’s notice does not claim that every Chromium-based browser received the same fix on the same schedule. Administrators responsible for another browser should use that vendor’s release record and version line instead of treating Chrome’s build number as portable.
Verify the running browser
Inventory exposes devices that still need action. On each managed platform, collect the running Chrome version rather than relying only on the package that was downloaded. Update devices below the fixed build and force or schedule a relaunch within the organization’s emergency-patching policy.
Then repeat the version collection. The expected result is 152.0.7977.82 or later on Linux and 152.0.7977.82 or .83, or a later release, on Windows and macOS. Devices that remain behind should be isolated from ordinary web browsing until their update path is repaired according to local policy.
That version result proves the vendor fix is active in the running browser. It cannot prove that an earlier exploit attempt never occurred. Because Google has published no indicators or incident-specific recognition guidance, organizations with suspicious browser crashes, unexpected child processes, or other endpoint alerts around Chrome should preserve the surrounding process, network, and identity telemetry for investigation rather than treating a successful update as historical clearance.
The immediate operational goal is measurable: every in-scope desktop reports a fixed running build after relaunch. The unanswered incident question remains separate, and it should be reopened if Google, the researcher, or a responding organization publishes detection evidence or attack details.