Google shipped the fix. That is the easy part. The harder part is proving that every browser capable of reaching company data has actually restarted into the fixed build.

Google’s September 3 desktop update fixes 12 security issues, including CVE-2026-85046, a high-severity type-confusion vulnerability in V8. Google says an exploit exists in the wild, while technical details remain restricted during rollout.

TL;DR

  • CVE-2026-85046 is a high-severity type-confusion flaw in Chrome’s V8 JavaScript engine.
  • Google is aware of exploitation in the wild but has not publicly described the campaign or complete exploit chain.
  • Fixed desktop versions are 152.0.7977.82/.83 for Windows and macOS and 152.0.7977.82 for Linux.
  • Downloading an update is not the same as running it; open browser processes may still use vulnerable code until restart.
  • Inventory every Chromium-based browser separately and verify its vendor advisory rather than assuming Chrome’s package updated it.

What Is Confirmed

Google credits Salvatore Gulizia, also known as Serotav, with reporting the V8 issue on August 4. The company describes the bug as type confusion: the engine handles an object as the wrong type, creating memory-safety conditions that may be useful for code execution.

That description does not reveal how current attackers deliver the exploit, which targets they selected, or whether another vulnerability is needed to escape Chrome’s sandbox. Google’s wording confirms an in-the-wild exploit, not every step of a complete endpoint takeover. Defenders should resist filling the gap with a fictional attack chain.

The safe model is simpler:

Attacker-controlled web content
        -> V8 processes crafted JavaScript
        -> memory corruption through type confusion
        -> attacker gains capabilities inside the browser process
        -> further impact depends on the exploit chain and sandbox boundary

The Restart Gap

Chrome can download an update in the background while the vulnerable process keeps running. A management console that reports a package as installed may therefore disagree with the browser users are actively using.

For a managed fleet, collect both installed and running versions. Confirm that the endpoint has no long-lived Chrome processes from before the update, and measure how many devices have missed policy check-in. Kiosks, virtual desktops, build agents, jump hosts, and rarely rebooted admin workstations deserve their own queue.

Unmanaged access creates a different problem. Contractors and personal devices may authenticate to SaaS without appearing in endpoint inventory. Conditional-access policy, device compliance, and browser/session controls are the places to close that gap. Blocking every unknown device may be operationally unrealistic; allowing it indefinitely because inventory is inconvenient is not a security strategy.

Chrome Is Not the Entire Chromium Fleet

V8 is shared across the Chromium ecosystem, but release timing and version numbers differ by browser vendor. Edge, Brave, Vivaldi, Opera, Electron applications, and embedded Chromium components should be tracked through their own release channels.

Do not infer that another product is vulnerable or fixed solely from the Chrome advisory. Instead, query software inventory by executable and publisher, then map each product to its vendor’s fixed version. The useful metric is not “Chrome deployment completed.” It is “no browser in scope is running a build its vendor identifies as affected.”

Detection Has Limits

Browser exploitation may leave little reliable network evidence, especially when malicious content is delivered through a legitimate site or advertising path. Useful signals include renderer crashes near suspicious navigation, browser child-process anomalies, exploit-protection events, newly created executables or persistence shortly after browser activity, and authentication from the endpoint after an unusual browser failure.

These signals support investigation. They do not replace patching, and the absence of a crash does not prove the exploit did not run.

Defensive Plan: Remove the Vulnerable Process

OwnerActionWhy it interrupts the attackHow to verify it worked
Endpoint engineeringDeploy the fixed Chrome version and enforce a relaunch deadline, with a shorter window for privileged and internet-facing workstations.Updating files on disk does not replace an already running vulnerable browser process. A relaunch loads the fixed V8 code.Query both the executable version on disk and active browser-process start times. No Chrome process should predate installation of the fixed build.
Asset managementInventory Chrome, other Chromium browsers, Electron applications, kiosks, virtual desktops, and portable installations by executable and publisher.Chrome’s advisory does not automatically establish the patch status of every product embedding Chromium or V8. An unmanaged second browser preserves exposure.Reconcile software inventory with EDR process telemetry and investigate every browser process that lacks a product owner and vendor-fixed-version decision.
Identity teamRequire managed-device or compliant-device signals for privileged SaaS and administration, and expire high-risk web sessions after fleet remediation.A contractor or personal device outside endpoint management can keep a vulnerable browser connected to sensitive data even when corporate endpoints show 100% compliance.Attempt access from a controlled non-compliant device and confirm policy blocks or limits the session; report active sessions issued before remediation.
SOCCorrelate renderer crashes, exploit-protection events, unusual browser child processes, new persistence, and subsequent credential use on the same endpoint.Public exploit details are limited. Post-exploitation behavior is more stable than a speculative network signature for one delivery page.Generate a safe test in which the browser launches a known benign child process under lab policy and confirm the correlation includes user, URL context where available, process tree, and later identity events.
Incident responseIf exploitation is plausible, isolate the endpoint, preserve browser and EDR telemetry, revoke sessions used from it, and hunt the same indicators across the fleet.A browser patch prevents another trigger but does not remove payloads, persistence, or stolen sessions created before remediation.Confirm isolation, evidence collection, session revocation, and fleet-wide search results in the case record before returning the device to service.

Use one closure metric: zero in-scope endpoints running a vendor-identified vulnerable browser build. Deployment percentage is useful progress reporting, not proof of protection.

Browser patching is a fleet-control problem disguised as a download button. The organization is protected only when the vulnerable process is gone.

Sources