CVE-2026-85046: Chrome's Sixth Zero-Day of 2026, and the Free Policy Most IT Teams Never Turn On

A malicious ad or a compromised WordPress page is now enough to run attacker code inside Chrome's sandbox, no click required beyond loading the page. Google shipped the fix on September 3. It is the sixth Chrome zero-day exploited in the wild this year, and CISA added it to the Known Exploited Vulnerabilities catalog the next day.

If every browser on your network already updated past 152.0.7977.82 and your organization enforces a relaunch within a day or two of a security release, this one is already closed and you can skip to the next advisory. If you do not know whether that is true across your fleet right now, six days after the fifth zero-day of the year, stop and find out, because the gap between "Chrome patched it" and "every installed copy of Chrome actually restarted" is exactly where this class of bug does its damage.

A one-line compiler bug became a sandboxed code-execution primitive

CVE-2026-85046 is a type confusion vulnerability in V8, Chrome's JavaScript and WebAssembly engine, rated CVSS 8.8. Researcher Salvatore Gulizia, known as Serotav, reported it to Google on August 4 and was paid a $1,000 bounty. The root cause is narrow and specific: a V8 compiler optimization can let a PACKED_ELEMENTS array end up carrying a PACKED_SMI_ELEMENTS map, so the engine reads and writes the array's contents using the wrong type layout. Get that mismatch in front of attacker-controlled JavaScript and it becomes an arbitrary heap read/write inside the renderer, the standard first stage of a browser exploit chain. Google's advisory states plainly that an exploit for this bug already exists in the wild, and, following its usual practice, withheld further technical detail until update adoption caught up.

The fix landed in Chrome 152.0.7977.82/.83 for Windows and macOS and 152.0.7977.82 for Linux, via the September 3 stable channel update. CISA added the CVE to the KEV catalog on September 4 under Binding Operational Directive 26-04, which sets a remediation deadline of September 18 for federal civilian agencies. Chromium-based browsers you may also be running, Edge, Brave, Opera, and most Electron apps, inherit the same V8 engine and typically ship their own point release within days.

What this buys an attacker, and what it still requires

Code execution from CVE-2026-85046 lands inside the renderer sandbox, the same containment boundary every tab runs in, not directly on the host operating system. A full device compromise still needs a second bug capable of escaping that sandbox, and no such chain has been publicly disclosed alongside this CVE. That distinction matters for triage: a machine hit by this bug alone is looking at renderer-scoped exposure, session data, and whatever the page's own origin can reach, not automatically a domain-wide incident. It does not make the bug low priority. It tells you what to actually go check.

Google has not published the in-the-wild exploitation technique, so there is no exploit signature to hunt for yet. What you can hunt for is behavior: unexpected Chrome renderer crashes in chrome://crashes or your crash-reporting pipeline, a renderer process spawning an unrelated child process, and EDR memory-corruption alerts tied to chrome.exe around the time a user browsed to an unfamiliar or newly registered domain. None of that requires Google's technical writeup to act on.

Six zero-days in nine months is the pattern, not the exception

Chrome has now patched six actively exploited zero-days in 2026: CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, CVE-2026-11645, and now CVE-2026-85046. Use-after-free defects remain the most persistent memory-corruption class behind that list, and this one adds type confusion to the same family of bug: the browser trusting an assumption about an object's shape that attacker-supplied JavaScript has already invalidated. Google's own patch cadence has held up every time. The auto-update mechanism checks in the background roughly every five hours and downloads the fix long before most users notice a release happened. That is the part of this story that gets covered every time and matters least to your actual exposure.

What determines whether a given install is protected on day six versus day forty is a second, quieter mechanism: Chrome does not apply a downloaded update until the browser restarts. A user with forty tabs open, a video call running, or a habit of sleeping their laptop instead of shutting it down can sit on a fully downloaded fix for weeks without ever loading it. Verizon's and Mandiant's incident telemetry both point at exactly this window, not the initial patch delay, as where opportunistic browser exploitation actually lands. The fix ships fast. The restart does not happen on its own.

What a managed fleet does differently

Enterprises that run Chrome under centralized management do not leave the restart to chance. A managed browser fleet enrolls every endpoint in a cloud or on-prem management console, sets the RelaunchNotification policy to 2 (Required) rather than leaving it unset, and shortens RelaunchNotificationPeriod from the default seven days down to something closer to 24 to 48 hours for anything CISA has already flagged as exploited. Past that window, the browser forces the relaunch itself, no user click required. IT gets a compliance report showing exactly which machines are still on a vulnerable build, instead of finding out from an incident.

The same console usually enforces a second, quieter control: an extension allowlist. Several of the browser extensions that promise to keep a session alive or block "annoying" restart prompts do exactly what they advertise, and a managed fleet blocks that category outright with ExtensionInstallBlocklist so an employee's convenience setting cannot silently cancel the relaunch policy IT just enabled.

None of that requires a large security budget. It requires the policy being turned on, and in most small organizations, it is not.

Chrome Enterprise Core puts the same lever in reach for zero dollars

Google offers the management layer that makes forced relaunch possible as Chrome Enterprise Core, and Core is free: no license cost, no seat minimum, sign-up through the Google Admin console. The setup is three steps: create a Google Workspace or Cloud Identity account if you do not already have one, generate a cloud management enrollment token under Chrome browser management, and push that token to your machines with whatever you already use to run scripts across the fleet, a GPO startup script, an RMM job, or by hand on a handful of laptops. Once a browser enrolls, you get a single console covering Windows, macOS, Linux, iOS, and Android, over 100 enforceable policies, and a live version report across every browser you manage, all at no additional cost beyond the time it takes to enable it. A five-person accounting firm and a five-thousand-person bank have access to the identical policy.

For a shop with a small number of unmanaged machines, or one that does not want to enroll in cloud management at all, the same RelaunchNotification policy can be set locally through Group Policy on Windows, a configuration profile on Mac, or a JSON policy file on Linux, with no Google account or enrollment step involved.

Either path leaves you with the same open question: which of your machines are still running the vulnerable build right now. A PowerShell sweep against Active Directory answers that in one pass, whether or not you have deployed the policy yet:

# Flag domain-joined machines still below the CVE-2026-85046 fix,
# and confirm whether forced relaunch is actually configured.
$fixed = [version]"152.0.7977.82"

Get-ADComputer -Filter {Enabled -eq $true} -Properties DNSHostName |
  ForEach-Object {
    $check = Invoke-Command -ComputerName $_.DNSHostName -ErrorAction SilentlyContinue -ScriptBlock {
      $exe = Get-ChildItem "$env:ProgramFiles\Google\Chrome\Application",
                            "${env:ProgramFiles(x86)}\Google\Chrome\Application" `
        -Filter chrome.exe -Recurse -ErrorAction SilentlyContinue | Select-Object -First 1
      $policy = Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Chrome" -ErrorAction SilentlyContinue
      [PSCustomObject]@{
        Version          = $exe.VersionInfo.ProductVersion
        RelaunchRequired = $policy.RelaunchNotification -eq 2
      }
    }
    [PSCustomObject]@{
      Host             = $_.DNSHostName
      Version          = $check.Version
      Patched          = ($check.Version -as [version]) -ge $fixed
      RelaunchEnforced = [bool]$check.RelaunchRequired
    }
  } | Where-Object { -not $_.Patched -or -not $_.RelaunchEnforced } |
  Format-Table Host, Version, Patched, RelaunchEnforced -AutoSize

Anything the sweep returns is either still exploitable or one skipped restart away from becoming exploitable again on the next zero-day, which history says is not far off.

Turn On Forced Relaunch Before the Seventh Zero-Day

Patch every machine the sweep flags today; that part is not optional and CISA's September 18 date is the federal floor, not a target to aim for. Then do the part that actually changes the outcome next time: enroll in Chrome Enterprise Core, or push the local policy if you will not enroll, and set RelaunchNotification to Required with a 24- to 48-hour window in place of the default seven days. A sixth zero-day patched fast and then left uninstalled on half the fleet protects nobody. The seventh one is coming, and the fix for it will already be sitting on every affected machine the day Google ships it, waiting for a restart that only happens if you made it mandatory.