Google Patches Sixth Chrome Zero-Day of 2026 As V8 Flaw Comes Under Active Attack

Google has released an urgent security update for Chrome after confirming that attackers are actively exploiting a high-severity vulnerability in the browser’s V8 JavaScript and WebAssembly engine.

The vulnerability, tracked as CVE-2026-85046, is a type-confusion flaw that could allow a remote attacker to execute arbitrary code inside Chrome’s sandboxed renderer process after a user visits a maliciously crafted webpage.

Google addressed the zero-day as part of a broader Chrome 152 security update containing 12 fixes. The patched desktop versions are Chrome 152.0.7977.82 and 152.0.7977.83 for Windows and macOS, and 152.0.7977.82 for Linux.

The company is distributing the update gradually, but users and organizations should not wait for the browser’s normal automatic-update cycle. Chrome can be checked manually by opening the browser menu and selecting Help > About Google Chrome, or by visiting chrome://settings/help. The browser must be restarted after installation before the security fixes take effect.

“Google is aware that an exploit for CVE-2026-85046 exists in the wild,” the company said in its Chrome security advisory.

Google has not revealed who is exploiting the vulnerability, which users have been targeted, how the exploit is being delivered or whether it forms part of a larger attack chain. That absence of information means the scale and purpose of the campaign remain unknown.

CVE-2026-85046 affects V8, the open-source engine Chrome uses to process JavaScript and WebAssembly content embedded in webpages and web applications.

The vulnerability was reported to Google on August 4 by security researcher Salvatore Gulizia, who is also known online as “Serotav.” Google rated the issue as high severity and awarded the researcher a $1,000 bounty.

According to the vulnerability description published by the US National Vulnerability Database, Chrome versions before 152.0.7977.82 could allow a remote attacker to execute arbitrary code inside the browser sandbox through a specially crafted HTML page.

A type-confusion vulnerability occurs when software allocates or handles an object as one data type but later treats it as another. When this happens inside a performance-sensitive engine such as V8, the browser can make incorrect assumptions about an object’s structure, size or location in memory.

An attacker who can reliably manipulate that behavior may be able to read or write memory outside the boundaries intended by the browser. Depending on the vulnerable code and the attacker’s level of control, the resulting memory corruption may lead to a browser crash, exposure of data or execution of attacker-controlled code.

The likely delivery mechanism would involve directing a victim to malicious web content containing specially constructed JavaScript or WebAssembly. This could be hosted on an attacker-controlled website, placed on a compromised legitimate site or delivered through a malicious advertisement, link, document or phishing message.

Simply establishing that arbitrary code can run inside a renderer, however, does not necessarily provide complete control of the underlying computer.

Chrome uses a sandbox to restrict renderer processes and prevent compromised web content from directly reaching sensitive operating-system resources. An attacker seeking broader access may therefore need to combine CVE-2026-85046 with a second vulnerability capable of escaping the sandbox or elevating privileges.

Google has not said whether the observed attacks used CVE-2026-85046 independently or as one component of a multi-stage exploit chain.

Google is withholding detailed technical information about the flaw while the update reaches Chrome users and other products built from Chromium.

This is standard practice during an actively exploited browser vulnerability. Releasing proof-of-concept code or detailed analysis too early could allow additional attackers to reproduce the exploit while a large portion of the browser population remains exposed.

Google also commonly keeps Chromium bug-tracker entries restricted when a vulnerability affects a third-party library used by other projects. Access is generally expanded after a sufficient proportion of users have installed a secure version.

The disclosure delay protects users during the rollout, but it also limits defenders’ immediate visibility. Security teams currently have little public information with which to identify the exploit’s delivery method, targeted organizations, infrastructure or post-compromise behavior.

Organizations should therefore focus on confirming patch deployment and examining broader browser-related indicators, such as unexpected renderer crashes, suspicious child processes, abnormal downloads, browser-spawned command interpreters, unexplained credential access and unusual connections immediately following visits to untrusted websites.

Those signals are not specific to CVE-2026-85046, but they may help identify activity consistent with browser exploitation while more precise technical indicators remain unavailable.

Although CVE-2026-85046 presents the most immediate risk because exploitation has already been observed, the new Chrome release also addresses multiple other high-severity memory-safety and implementation vulnerabilities.

Google’s advisory identifies an out-of-bounds read in Chrome’s crash-reporting functionality, an incomplete-cleanup problem in the network component and a separate V8 race condition reported by Brendan Dolan-Gavitt of XBOW.

The release also fixes an out-of-bounds write vulnerability in WebGL, improper resource exposure in CacheStorage, use-after-free flaws affecting DevTools and the Skia graphics library, and another type-confusion issue in Chrome’s compositing functionality.

Two medium-severity vulnerabilities were publicly identified in the Transactions Platform and Chrome’s mobile code. Some additional fixes included in a Chrome release may result from internal audits, fuzzing systems or other security work and may not receive the same level of public detail.

Several of the newly patched vulnerabilities could affect how Chrome handles memory or untrusted web content. Even where active exploitation has not been reported, memory-corruption flaws in a browser can be valuable to attackers because browsers routinely process complex content obtained from untrusted sources.

Google uses multiple automated security technologies—including AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity and fuzzing frameworks—to identify flaws during development. Nevertheless, the size and complexity of modern browser codebases mean exploitable defects continue to reach stable releases.

The underlying vulnerability is located in V8 rather than a Chrome-only interface, meaning other Chromium-based browsers may also be affected if they incorporate a vulnerable version of the engine.

Users of Microsoft Edge, Brave, Opera, Vivaldi and other Chromium-derived browsers should monitor their vendors’ release channels and install the corresponding security updates as soon as they become available.

Chromium-based browsers do not always receive the patched engine at exactly the same time as Google Chrome. Each vendor maintains its own release, testing and deployment process, which can create a short delay between Google’s disclosure and the arrival of a product-specific update.

Switching away from Chrome to another Chromium browser does not by itself eliminate exposure if that browser still contains the vulnerable V8 code. The important factor is whether the installed browser version incorporates the upstream fix.

Organizations should check every Chromium-based product in use rather than limiting their response to systems on which Google Chrome is the default browser. This includes secondary browsers installed by users, test systems, virtual desktops, kiosks and applications that embed Chromium or the Chromium Embedded Framework.

Chrome 152.0.7977.82 has also been released for Android, with Google indicating that it will become available through Google Play over several days. The company’s Chrome release channel also repeats the warning that an exploit for CVE-2026-85046 exists in the wild.

Chrome on iOS uses Apple’s browser engine under Apple’s platform rules rather than Google’s full V8-based Chromium engine, so the technical exposure is not necessarily identical to Chrome on desktop or Android.

CVE-2026-85046 is the sixth Chrome vulnerability Google has identified as exploited in the wild during 2026.

The first was CVE-2026-2441, an iterator-invalidation vulnerability affecting Chrome’s implementation of CSS font-feature values. Google patched that issue in February after detecting active exploitation.

In March, the company addressed two additional zero-days: CVE-2026-3909, an out-of-bounds write in the Skia 2D graphics library, and CVE-2026-3910, an inappropriate-implementation vulnerability in V8.

Google then patched CVE-2026-5281, a use-after-free vulnerability in Dawn, the cross-platform implementation used by Chromium for WebGPU. The company’s March 2026 release record confirms that an exploit for that vulnerability existed in the wild.

The fifth exploited flaw, CVE-2026-11645, was an out-of-bounds read-and-write vulnerability in V8 addressed in June. CVE-2026-85046 now brings the publicly reported total to six.

That sequence does not necessarily mean all six vulnerabilities were connected or exploited by the same threat actors. Google has not published evidence linking the latest campaign to the earlier attacks.

Browser zero-days are frequently used in highly targeted operations because they can provide an initial entry point with limited interaction from a victim. In some campaigns, attackers need only persuade a target to open a link or visit a compromised page. Browser exploits may also be combined with sandbox escapes and operating-system privilege-escalation vulnerabilities to produce a more complete compromise chain.

Advanced exploit chains of this kind are costly to develop and may initially be reserved for intelligence collection, surveillance or other targeted operations. Once a vendor publishes a patch, however, attackers can compare the vulnerable and corrected code—a process known as patch diffing—to understand what changed and develop their own exploits.

That creates a race between defenders deploying the update and other attackers reverse-engineering the fix.

For individual users, updating Chrome is generally straightforward. Enterprise environments face a more complicated problem because they may operate thousands of browser installations across managed laptops, remote devices, virtual machines, development systems and servers with graphical interfaces.

Security teams should verify the installed version using endpoint-management or software-inventory tools rather than assuming automatic updates have succeeded. Browsers left open for long periods may download an update without activating it because the user has not restarted the application.

Organizations should identify endpoints running versions earlier than Chrome 152.0.7977.82 and prioritize systems used by administrators, developers, executives and personnel with access to sensitive data or high-value cloud services.

Administrators should also check whether update policies, application-control rules, proxy configurations, offline devices or unsupported operating systems are preventing the new release from being installed.

The danger is particularly acute on systems running operating systems no longer supported by current Chrome releases. A browser that cannot receive the patched build may remain permanently exposed, requiring an operating-system upgrade, hardware replacement or migration to another actively supported browser.

Security teams should consider shortening browser-restart deadlines during zero-day events. A downloaded update provides no protection until the new browser process is launched, so repeatedly deferring a restart can leave users running the vulnerable code despite the apparent presence of an update.

The immediate priority is to ensure that Chrome has been upgraded to version 152.0.7977.82 or later and restarted. Windows and macOS systems may display either 152.0.7977.82 or 152.0.7977.83, depending on the build delivered by Google.

Managed organizations should confirm deployment through centralized reporting, search for vulnerable or stale browser installations and investigate endpoints that fail to update. Equivalent patched versions of Edge, Brave, Opera, Vivaldi and other Chromium-derived products should be deployed as their vendors release them.

Organizations with heightened exposure should review browser telemetry and endpoint alerts for evidence of suspicious activity preceding the patch. If exploitation is suspected, updating the browser alone is not sufficient because an attacker may already have established persistence or stolen authentication material.

Potentially compromised systems should be isolated and investigated, active sessions reviewed, high-value credentials rotated where appropriate and affected accounts checked for unauthorized access.

The current absence of public details about the attacks should not be interpreted as evidence that exploitation is limited or low impact. Google’s confirmation means functioning exploit code was observed outside a controlled research environment before the vulnerability was publicly disclosed.

CVE-2026-85046 therefore represents a patch-now issue. For users and organizations that rely on Chrome or other Chromium-based browsers, rapidly deploying the corrected version is presently the most reliable protection against a zero-day whose exploitation method and targets remain largely undisclosed.