Chrome V8 Zero-Day CVE-2026-85046 Hits CISA KEV as Chromium Forks Race to Catch Up

Google shipped its sixth in-the-wild Chrome zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program., giving developers 'zero days' to fix it. fix of 2026 on 3 September, and by 4 September CISA had it in the Known Exploited Vulnerabilities catalog with an 18 September federal deadline. The bug itself is a familiar shape: a type confusionType Confusion🛡️A memory-safety bug (CWE-843) in which code accesses a resource using an incompatible type, such as reading a pointer as an integer. In JavaScript engines it typically arises when optimized code trusts an assumption about an object's shape that a callback has since invalidated, as in CVE-2026-85046. in V8, the JavaScript engine, that hands an attacker read and write access to the renderer's heap from a web page. What makes this one worth a closer look is the days that followed, when Microsoft Edge, Brave, Opera and Electron each shipped, or did not ship, the same fix on their own schedules. If your patch process starts and ends with the Chrome installer, CVE-2026-85046 is a good week to reread it.

What happened

Google's Stable Channel post of 3 September lists Chrome 152.0.7977.82/.83 for Windows and macOS and 152.0.7977.82 for Linux, with twelve security fixes. One of them carries the line every browser admin scans for: "Google is aware that an exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. for CVE-2026-85046 exists in the wild." The entry credits Salvatore Gulizia, who publishes as Serotav, with a report on 4 August 2026 and a $1,000 bounty. The same release fixes a second V8 bug, a race condition (CVE-2026-85045) reported by Brendan Dolan-Gavitt of XBOW, and a second Gulizia find in CacheStorage (CVE-2026-85053).

The CVE record, issued by the Chrome CNA on 3 September, describes the flaw as "Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page." It carries CVSS 3.1 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and CWE-843. The Chromium issue, 542403045, is still access-restricted.

CISA's KEV feed (catalog version 2026.09.04) records the addition on 4 September with a due date of 18 September, the standard 14-day window, and known ransomware use marked Unknown. As usual for browser bugs, Google has said nothing about who is exploiting it or against whom.

Who is affected

Everyone running a Chromium-based browser below the fixed build, which in practice means most desktop fleets. The affected surface splits into four groups with different patch owners:

• Google Chrome on Windows, macOS and Linux below 152.0.7977.82. Chrome for Android received a separate update the same day.
• Microsoft Edge. Microsoft's security release notes state that Edge Stable 152.0.4191.62, dated 2 September, "contains a fix" for CVE-2026-85046 and cites the Chromium team's in-the-wild report. A further Edge build, 152.0.4191.66, followed on 4 September. Read literally, Microsoft's page dates its fix one day before Google's public advisory.
• Brave and Opera. Brave 1.94.121, tagged 4 September, upgrades Chromium to 152.0.7977.83, and Brave described it as a fix for "a Chromium vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. found to be exploited in the wild." Opera's changelog for 4 September notes a backport of the CVE-2026-85046 fix to its 135 and 136 branches, which still sit on a Chromium 151 base. Brave's iOS build uses WebKit and is out of scope.
• Electron applications. Electron 44 is the only supported line on Chromium 152, and its newest release, 44.2.0 on 4 September, lists Chromium 152.0.7977.76, below the fixed build. We found no reference to CVE-2026-85046 in the Electron release notes as of publication. Every Electron-packaged desktop app in your estate (chat clients, editors, password managers, VPN front ends) is therefore a separate patch decision owned by that app's vendor, not by your browser policy. Electron also states that only the three most recent stable majors receive fixes, so anything on 41 or older will never get this one.

The WebView2WebView2🛡️Microsoft's control for embedding Chromium-based web content inside Windows applications. The Evergreen runtime updates alongside Microsoft Edge, while a Fixed Version runtime is bundled by the application vendor and receives Chromium security fixes only when the vendor ships a new package. runtime that backs many Windows line-of-business apps updates with Edge in Evergreen mode, but Microsoft's own documentation notes that a running app keeps using the old runtime until it restarts, and that Fixed Version deployments are updated only when the app vendor ships a new bundle.

Technical analysis

Gulizia's write-up, "When Sorting Leads To Confusion", describes the root cause. V8 tracks an "elements kind" for every array: PACKED_SMI_ELEMENTS for arrays that hold only small integers, PACKED_ELEMENTS for arrays that may hold arbitrary objects. Optimized code emitted by the Maglev compiler (Turbofan was affected too, per Gulizia) relies on that kind to decide whether a slot contains a raw integer or a tagged pointer.

When Maglev inlined Array.prototype.sort, it checked that the array's map still belonged to an accepted set after the user-supplied comparator ran, rather than checking that the map was unchanged. A comparator that calls Array.prototype.fill on the array being sorted can migrate the map backwards, from PACKED_ELEMENTS to PACKED_SMI_ELEMENTS, while the backing store keeps its object pointers. The compiled code now believes it is handling integers when it is handling pointers.

From there the write-up follows the standard V8 exploitation path. Reading a pointer as an integer leaks a heap address (an addrof primitive). Array.prototype.unshift, which the compiler treats as moving integers, shifts pointers without the write barrier the garbage collector expects, and that yields a fakeobj primitive. Together those give arbitrary read and write on the JavaScript heap, which is what the CVE description means by code execution "inside the sandbox". The post includes working fragments but not a complete exploit, and it was written while the CVE was still private.

Two points matterMatter🏠A new universal smart home standard backed by Apple, Google, and Amazon for cross-platform compatibility. for defenders. First, this is renderer-only: to touch the operating system, an attacker still needs a sandbox escapeSandbox Escape🛡️A second-stage exploit that breaks out of a restricted process, such as a browser renderer, into the more privileged browser process or the operating system. In-the-wild browser attacks usually chain a JavaScript-engine bug with a sandbox escape, which is why a renderer-only bug is rated as scope unchanged in CVSS., which is why the CVSS scope is Unchanged and why in-the-wild browser chains almost always pair a V8 bug with a second flaw. Second, the trigger is ordinary JavaScript that any site or ad slot can serve, so the only real mitigation is the patched build. The mechanics are covered in more depth in How V8 Type Confusion Bugs Turn JavaScript Into Memory Corruption.

Immediate actions

• Set the floor at 152.0.7977.82 for Chrome and verify it from inventory, not from the installer version. Chrome applies updates only after a relaunch, so a fleet that "updated" on 3 September but was never restarted is still running the vulnerable process. Chrome's RelaunchNotification policy set to Required, with a shortened RelaunchNotificationPeriod, enforces that; the default period is seven days.
• Treat Edge as done only at 152.0.4191.62 or later, and confirm the WebView2 runtime version separately on machines that run WebView2-based internal apps.
• Enumerate Electron apps. Each one bundles its own copy of Chromium that no browser policy touches; map every app to its vendor and the Electron major it ships, and open tickets for anything still on a build below the fix. Our guide How to Enforce Browser Updates Across a Managed Fleet walks through the policy and inventory side.
• Prioritize by exposure. Admin workstations, help-desk machines and anything that browses with privileged tokens loaded go first. If you already follow How to Triage a CISA KEVCISA KEV🛡️The Known Exploited Vulnerabilities catalog maintained by CISA, listing vulnerabilities actively exploited in attacks that federal agencies must patch by specific deadlines. Addition in 72 Hours, this entry fits the standard playbook with one twist: the vendor list is longer than the KEV row suggests.
• Watch for renderer crashes followed by unexpected child processes. Exploits for type confusion bugs are not always reliable, and a failed attempt often shows up as a crash in a Chrome, Edge or Electron renderer just before something else happens on the host.

Long-term outlook

Six exploited Chrome zero-days in eight months (CVE-2026-2441, -3909, -3910, -5281, -11645 and now -85046), five of them in V8 or graphics code, is not a trend that changes with any single patch. Google's own reporting cadence, a fix roughly every six weeks with an in-the-wild note, is now a planning input rather than an emergency.

The harder lesson is about the ecosystem. Chromium's fix landed in Edge, Brave and Opera within two days, which is good, but through three separate release trains with three version schemes. Electron, and the app vendors downstream of it, lag by design. Any organization that tracks "the browser" as one asset is under-counting its exposure by however many Chromium copies its desktop apps carry. The Chromium Downstream Problem: Tracking Patches in Forks and Embedded Browsers lays out how to build that inventory and what SLAs are realistic for each layer. Combine that with the reasoning in The Collapsing Patch-to-Exploit Window and the conclusion is uncomfortable but clear: a browser zero-day is a fleet-wide incident with a fourteen-day clock, not a Chrome ticket.

Sources

• Chrome Releases, Stable Channel Update for Desktop, 3 September 2026: https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html
• CVE record CVE-2026-85046 (Chrome CNA): https://cveawg.mitre.org/api/cve/CVE-2026-85046
• CISA Known Exploited Vulnerabilities JSON feed (catalog 2026.09.04): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• Serotav, "When Sorting Leads To Confusion": https://serotav.github.io/Writeups/v8/when-sorting-leads-to-confusion/
• Microsoft Edge security release notes: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnotes-security
• Microsoft Edge Stable Channel release notes: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel
• Brave release v1.94.121: https://github.com/brave/brave-browser/releases/tag/v1.94.121
• Opera 135 changelog: https://blogs.opera.com/desktop/changelog-for-135/
• Electron releases: https://github.com/electron/electron/releases
• Electron 44.0 release post: https://www.electronjs.org/blog/electron-44-0
• Electron release timelines: https://www.electronjs.org/docs/latest/tutorial/electron-timelines
• WebView2 distribution documentation: https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution
• Chrome Enterprise, Notify users to restart to apply pending updates: https://support.google.com/chrome/a/answer/7679871
• Help Net Security, 4 September 2026: https://www.helpnetsecurity.com/2026/09/04/google-chrome-zero-day-cve-2026-85046/
• The Hacker News, 4 September 2026: https://thehackernews.com/2026/09/google-releases-chrome-update-to-patch.html
• Security Affairs, 4 September 2026: https://securityaffairs.com/198405/security/google-fixes-the-sixth-actively-exploited-chrome-zero-day-of-2026.html
• PiunikaWeb on Brave 1.94.121, 5 September 2026: https://piunikaweb.com/2026/09/05/brave-emergency-update-zero-day-exploit/