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.
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.
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.
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
- Google Chrome Releases — Stable Channel Update for Desktop (4 Sep 2026 advisory, fixed builds, in-the-wild note)
- CIRCL Vulnerability Lookup — CVE-2026-85046 (CVSS 8.8, vector, CWE-843, official description)
- Help Net Security — Google patches actively exploited Chrome zero-day (CVE-2026-85046)
- BleepingComputer — Google warns of new Chrome zero-day flaw exploited in attacks
- The Hacker News — Google releases Chrome update to patch actively exploited V8 zero-day
- Cyber Security News — CISA warns of Chromium type confusion 0-day actively exploited
- CISA — Known Exploited Vulnerabilities Catalog
ZeroDayHub reports on vulnerabilities for defensive purposes only. This article deliberately omits working exploit code and technical detail that would aid attackers.





Leave a Reply