Google rolled out an emergency security update on Thursday to fix a critical zero-day vulnerability that’s already being exploited. Tracked as CVE-2026-85046, the high-severity flaw (CVSS score: 8.8) sits in V8, the JavaScript and WebAssembly engine that powers Chrome and other Chromium-based browsers. It’s the sixth actively exploited Chrome zero-day Google has patched in 2026.
CVE-2026-85046: type confusion in V8
At the core of this vulnerability is a classic “type confusion” bug in V8’s Just-In-Time (JIT) compilers. In modern browser engines, JavaScript is dynamically typed: a variable can hold an integer, a string, or an object reference at different points during execution. To run code at near-native speed, V8 uses optimizing compilers like TurboFan and Maglev, which make aggressive assumptions about variable types based on profiling data gathered during earlier execution.
When these compilers incorrectly guess or lose track of an object’s type, a type confusion vulnerability occurs. In the case of CVE-2026-85046, the flaw allows a remote attacker to execute arbitrary code inside Chrome’s renderer sandbox by luring a victim to a crafted HTML page. The vulnerability was discovered and responsibly reported on August 4, 2026, by security researcher Salvatore Gulizia (known online as Serotav), who was awarded a $1,000 bug bounty by Google for the disclosure.
Technical analysis: how compiler bugs break the JavaScript heap
To understand the severity of this flaw, we must look under the hood of V8’s memory management and optimization strategies. V8 uses an internal mechanism called “Maps” (often referred to as hidden classes) to track the structure and element kinds of JavaScript objects. For arrays, V8 categorizes elements into specific “kinds” to optimize memory usage and access speed. Two common element kinds involved in this exploit are PACKED_SMI_ELEMENTS and PACKED_ELEMENTS.
PACKED_SMI_ELEMENTS is a dense array containing only Small Integers (SMIs). On 64-bit architectures, SMIs are usually stored inline in the memory slot itself, tagged with a specific bit pattern that distinguishes them from pointers and skips the overhead of heap allocation. Conversely, PACKED_ELEMENTS is a more generic array type designed to hold arbitrary JavaScript objects, HeapNumbers (floating-point values), and raw memory pointers.
According to Gulizia’s technical breakdown, the vulnerability occurs when the V8 compiler erroneously allows an array initialized as PACKED_ELEMENTS to receive the Map of a PACKED_SMI_ELEMENTS array. This mismatch breaks memory safety in two ways:
- The Read Primitive (Leaking Addresses): When the engine reads from the array, it consults the Map, which incorrectly claims the array holds SMIs. The underlying memory actually contains raw object pointers or HeapNumbers. V8 reads these raw bits, tags them as SMIs, and hands them back to JavaScript, letting an attacker leak real memory addresses and defeat Address Space Layout Randomization (ASLR).
- The Write Primitive (Heap Corruption): When writing to the array, V8 again trusts the SMI Map. An attacker can pass a carefully crafted integer representing a fake pointer. V8 un-tags the SMI and writes it directly into the backing store as a raw pointer.
By chaining these read and write primitives, an attacker achieves arbitrary read/write capabilities over the JavaScript heap. This is the holy grail for browser exploit chains. Once the heap is corrupted, attackers can manipulate adjacent memory structures, such as overwriting the byte length of an ArrayBuffer to read out-of-bounds memory, or altering object Maps to gain native code execution within the renderer process.
// Conceptual representation of triggering the V8 type confusion primitivelet arr = [1.1, 2.2, {}]; // V8 initializes as PACKED_ELEMENTS (holds doubles/objects)// ... JIT Compilation and Optimization Occurs ...// The compiler erroneously transitions the map to PACKED_SMI_ELEMENTS// Write Primitive: Writing an integer that represents a fake pointer// The engine writes the raw bits into the backing store as an object pointerarr[0] = fake_pointer_as_smi; // Read Primitive: Leaking an object address as an integer// The engine reads the raw pointer, tags it as an SMI, and returns it to JSlet leaked_address = arr[2];
Why Google withheld exploit details
As is standard protocol for actively exploited zero-days, Google’s official advisory acknowledged that an exploit for CVE-2026-85046 “exists in the wild” but withheld the technical specifics and proof-of-concept (PoC) code. The embargo on exploit details is a deliberate defensive measure: by keeping the exploit’s mechanics under wraps until most users have updated, Google shrinks the window for opportunistic attackers and automated botnets that scrape CVE disclosures to launch drive-by-download campaigns.
Chrome’s zero-day tally for 2026
While Chrome’s automated update mechanism works well, the volume of zero-days hitting the browser this year shows how complex modern JavaScript engines have gotten. With this patch, Google has addressed six actively exploited Chrome zero-days since January 2026: the other five are CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, and CVE-2026-11645.
Most of these bugs target V8, which is the largest and most complex attack surface in the browser. Because V8 runs untrusted code from the web at native speed, it needs a web of sandboxing and memory-safety guarantees. When an optimizing compiler like TurboFan or Maglev pushes for more performance, it occasionally introduces edge-case logic errors that sophisticated attackers, often state-sponsored groups or commercial surveillance vendors, are quick to weaponize.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →How to patch your browser now
Because this vulnerability is already being exploited, applying the patch isn’t optional. Google has released the fix in Chrome version 152.0.7977.82 and 152.0.7977.83 for Windows and macOS, and version 152.0.7977.82 for Linux.
To check whether you’re protected, follow these steps:
- Open Google Chrome.
- Click the three-dot menu icon in the top-right corner.
- Navigate to Help > About Google Chrome.
- The browser will automatically check for updates. If version 152.0.7977.82 (or higher) isn’t installed, click Relaunch to apply the patch and restart the browser.
What this means for other Chromium browsers
Chrome isn’t the only browser affected: anything built on Chromium shares the same V8 engine. Users of Microsoft Edge, Brave, Opera, and Vivaldi are equally exposed to CVE-2026-85046. These vendors run their own update schedules but typically pull in Chromium’s upstream security patches quickly. Administrators and users of other Chromium browsers should check their own “About” pages to confirm the latest upstream fix has landed.
Patching isn’t the whole defense
V8 zero-days keep surfacing because JIT compilers trade safety margin for speed: the faster TurboFan and Maglev get, the more edge cases slip through. For enterprise security teams, that means browser updates alone aren’t enough. Network segmentation, EDR tooling that can flag renderer-process anomalies, and site isolation still belong in the stack, because a sandbox escape is a matter of when, not if.









