TL;DR — Google has shipped an emergency Chrome update for CVE-2026-85046, a type confusion flaw in the V8 JavaScript engine that lets a remote attacker run arbitrary code inside the browser’s sandbox simply by getting a victim to open a booby-trapped web page. It is rated CVSS 8.8 (High) and tracked as CWE-843, and Google has confirmed an exploit already exists in the wild — the sixth actively exploited Chrome zero-day of 2026. The fix landed in Chrome 152.0.7977.82/.83 on 4 September 2026, and CISA added the bug to its Known Exploited Vulnerabilities catalog the same day with a federal remediation deadline of 18 September 2026. Update Chrome — and every other Chromium-based browser — now.

HIGHCVE-2026-85046Google Chrome V8 type confusion → sandbox RCECVSS 3.18.8 High (NVD / CIRCL)VECTORCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HWEAKNESSCWE-843 type confusion in the V8 engineAFFECTEDGoogle Chrome < 152.0.7977.82 — and Chromium-based browsersATTACK VECTORNetwork — remote, victim opens a crafted web page (UI required)FIXED INChrome 152.0.7977.82/.83 — released 4 Sep 2026EXPLOITEDYes — Google confirms an exploit exists in the wildCISA KEVListed 4 Sep 2026 — federal fix deadline 18 Sep 2026
At-a-glance threat summary for the Google Chrome V8 type confusion zero-day (CVE-2026-85046).

What Is the Chrome V8 Type Confusion Flaw (CVE-2026-85046)?

V8 is the engine inside Google Chrome that compiles and runs the JavaScript and WebAssembly on almost every web page you visit. Because it turns untrusted code from the open internet into fast native instructions, it is one of the most heavily attacked components in any browser — and it is exactly where CVE-2026-85046 lives. The flaw is a type confusion bug (CWE-843): V8’s optimising compiler can be tricked into treating a chunk of memory as one kind of object when it is really another, and that mismatch is the crack an attacker levers open.

Google rates the issue “High” severity, and the NVD/CIRCL CVSS 3.1 score is 8.8 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. In plain terms: the attack comes over the network, needs no privileges, and requires only that the victim open a malicious page — no clicking, no downloading, no dialog to dismiss. The official advisory description is blunt: “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.” The bug was reported by independent researcher Salvatore Gulizia (handle “Serotav”) on 4 August 2026 and earned a $1,000 bounty.

How the Chrome V8 Exploit Works

In plain terms: an attacker builds a web page containing JavaScript designed to confuse Chrome’s engine about what type of data it is handling. Once the engine is fooled, the attacker can read and write memory it was never meant to touch, and from there steer the browser into running code of their choosing. All the victim has to do is load the page.

Technically, the researcher’s own analysis describes a V8 compiler bug in which “an array containing PACKED_ELEMENTS [is made] to receive the map PACKED_SMI_ELEMENTS.” That is a classic type confusion: the engine believes an array holds one representation (small integers) while it actually holds another (arbitrary object pointers), and the two are laid out differently in memory. By exploiting that mismatch, an attacker turns the bug into an arbitrary read/write primitive on the JavaScript heap — the ability to read and overwrite memory at addresses of their choosing. From a strong read/write primitive, defeating in-process mitigations and achieving code execution in the renderer is a well-trodden path. The pre-conditions are minimal: a current, unpatched Chrome and a single visit to attacker-controlled content, whether that is a malicious site, a compromised legitimate one, or a hostile ad served into a trusted page.

A type confusion bug in V8 needs no exploit kit and no user mistake beyond loading a page — which is why browser zero-days are prized by everyone from commercial spyware vendors to state actors.

ATTACK CHAIN1Craft a malicious web pageAttacker builds an HTML page with JavaScript that triggers the V8 type confusion.2Lure the victim into opening itA link, a compromised site, or a malicious ad — the only interaction needed is loading the page.3Confuse V8 about an object’s type (CWE-843)PACKED_ELEMENTS is handled with a PACKED_SMI_ELEMENTS map — two incompatible memory layouts.4Gain arbitrary read/write on the JS heapThe type mismatch is levered into reading and overwriting memory at attacker-chosen addresses.5Execute code in the renderer — then chain a sandbox escapeCode runs inside the sandbox; full device compromise needs a second bug to break out of it.
From a single crafted page to code execution inside Chrome’s renderer — the type-confusion path behind CVE-2026-85046.

Impact Nuance: Sandboxed RCE, Not Automatic Device Takeover

It is worth being precise about what “remote code execution” means here, because the advisory itself is careful about it. The official wording is that the flaw allows code execution inside the sandbox. Chrome runs each site’s JavaScript in a heavily restricted renderer process, so on its own this bug gives an attacker control of that sandboxed process — not, by default, the whole operating system. Turning a renderer compromise into full device takeover generally requires a second vulnerability, a sandbox escape, chained onto this one.

That nuance is a reason for calm precision, not complacency. In-the-wild browser exploitation almost always arrives as a chain, and the actors who burn a Chrome zero-day — commercial spyware vendors and nation-state operators among them — typically have the escape bug to pair with it. A sandboxed read/write primitive is also enough on its own to steal session tokens, saved data and anything else the renderer can reach for the sites you have open. Google confirming that an exploit exists in the wild, rather than merely a proof-of-concept, is the signal that matters: this is being used, and the sandbox is a speed bump, not a guarantee.

Active Exploitation of CVE-2026-85046

Google’s advisory states plainly that it “is aware that an exploit for CVE-2026-85046 exists in the wild.” As is standard for an actively exploited browser bug still rolling out to billions of installs, Google has withheld technical specifics on the attacks — who is being targeted and by whom — to buy the wider user base time to update. What is confirmed is that this is the sixth actively exploited Chrome zero-day of 2026, following CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 and CVE-2026-11645, and that several of this year’s V8 bugs have followed the same type-confusion pattern.

CISA added CVE-2026-85046 to its Known Exploited Vulnerabilities (KEV) catalog on 4 September 2026, setting a federal remediation deadline of 18 September 2026 under Binding Operational Directive 22-01. The KEV listing is the authoritative “this is being exploited, patch it” flag for defenders. Because the same V8 engine ships inside every Chromium-based browser, the exposure is not limited to Chrome — Microsoft Edge, Opera, Brave, Vivaldi and others inherit the flaw and must pick up their own updated builds.

DISCLOSURE TIMELINE4 Aug 2026Researcher “Serotav” reports the V8 type confusion to Google ($1,000 bounty)4 Sep 2026Google ships Chrome 152.0.7977.82/.83; confirms an in-the-wild exploit4 Sep 2026CISA adds CVE-2026-85046 to the KEV catalog5 Sep 2026Reported as the sixth actively exploited Chrome zero-day of 202618 Sep 2026CISA federal remediation deadline (BOD 22-01)
From private report to KEV deadline in five weeks — the compressed lifecycle of an actively exploited Chrome zero-day.

Remediation & Mitigation: Patching Chrome

Update now. Move Chrome to 152.0.7977.82 or later (Windows and macOS receive 152.0.7977.82/.83; Linux receives 152.0.7977.82), released 4 September 2026. Chrome usually updates itself in the background, but the patch only takes effect after a restart — and a browser left open for days may still be running the vulnerable build. The key actions:

  • Force the update and relaunch. Open chrome://settings/help, let Chrome fetch the latest version, then click Relaunch. Confirm the version reads 152.0.7977.82 or higher afterwards — the fix is not live until the browser has been restarted.
  • Do not forget the other Chromium browsers. Microsoft Edge, Brave, Opera, Vivaldi and friends share V8 and are affected. Update each one to the build that incorporates this fix; they ship on their own schedules, so an up-to-date Chrome does not patch your Edge.
  • Roll it out at scale. In managed environments, push the update through your browser management policy or endpoint tooling rather than trusting per-user restarts, and prioritise internet-facing and high-value users to beat the 18 September KEV deadline.

Reduce exposure while you roll out. There is no configuration workaround for the bug itself — patching is the fix — but you can shrink the window of risk:

  • Restart browsers deliberately. Tell users to close and reopen Chrome (and Chromium siblings) today rather than leaving long-lived sessions running, so the downloaded update actually applies.
  • Lean on defence in depth. Keep Enhanced Safe Browsing on, block risky ad and script sources where feasible, and ensure OS-level exploit mitigations are current — a sandbox escape needs a second bug, so a hardened host raises the cost of a full chain.
  • Assume nothing if a target was already hit. For a genuinely targeted user, treat exposure as possible session-token and credential theft: rotate credentials and invalidate active sessions for sensitive accounts used in that browser.

Related ZeroDayHub Coverage

CVE-2026-85046 is the latest reminder that memory-safety bugs remain the sharp end of remote code execution. We saw the same class of flaw turned into RCE in NGINX’s HTTP/3 use-after-free (CVE-2026-42530), and again in the Windows IKE double-free exploited in the wild (CVE-2026-33824). Different products, the same root cause: when software mishandles the type or lifetime of memory, attacker-controlled input becomes attacker-controlled code.

Sources & Further Reading

ZeroDayHub reports on vulnerabilities for defensive purposes only. This article deliberately omits working exploit code and technical detail that would aid attackers.

One response to “Google Chrome V8 Zero-Day Exploited in the Wild – CVE-2026-85046”

  1. […] no mistake from the victim are the ones worth watching. See our coverage of the actively-exploited Google Chrome V8 zero-day (CVE-2026-85046), another client-side flaw abused in the wild against ordinary users, and the macOS Screen Sharing […]

Leave a Reply

Trending

Discover more from Zerodayhub

Subscribe now to keep reading and get access to the full archive.

Continue reading