The Hacker News post that called CVE-2026-85046 a sandbox RCE reached 344 points in under four hours. Its headline compressed two separate security events into one. Google's record says a crafted HTML page can trigger type confusion in V8 and execute arbitrary code inside Chrome's sandbox. Neither the Chrome advisory nor the National Vulnerability Database entry says that code escaped the sandbox and reached the host operating system.
That distinction does not make this a routine bug. Google says an exploit already exists in the wild. On September 3, it moved desktop Chrome to 152.0.7977.82/.83 on Windows and macOS and 152.0.7977.82 on Linux. The release fixes 12 security issues, including CVE-2026-85046, which Google rates High. A browser restart is the line between downloading that fix and running it.
What "inside the sandbox" means
The NVD description is short and unusually useful here. A remote attacker can use a crafted HTML page to execute arbitrary code inside the sandbox on Chrome versions before 152.0.7977.82. Its CVSS 3.1 assessment is 8.8: network reachable, low attack complexity, no privileges required, and user interaction required. The public entry does not specify whether that interaction is limited to opening a page or requires another action.
V8 is the JavaScript and WebAssembly engine in Chrome. A type-confusion flaw, categorized as CWE-843 in the CVE record, lets software handle a resource as an incompatible type. In a memory-unsafe engine, that mistake can give an attacker memory access the program never intended. Google's advisory does not publish the proof of concept or the faulty code path, so the exact route from type confusion to native code execution remains private.
Chrome has more than one containment boundary around V8. The V8 team's explanation of its heap sandbox says recent 64-bit Chrome builds isolate V8's heap within the renderer process. That inner sandbox assumes an attacker may gain arbitrary read and write access to its memory and tries to keep the corruption from spreading through the rest of the process. Chrome then places renderer processes inside an operating-system sandbox with limited access to files and other machine resources.
The CVE notice does not say which V8 protections the exploit must defeat. It does establish the result: arbitrary code runs inside a sandboxed process. Chromium's own renderer threat model calls this a compromised renderer, where an attacker runs native code rather than JavaScript alone. That position gives the attacker far more control over the renderer while leaving other browser defenses in play.
Chromium uses a stricter definition for the next step. Its security guidance for the browser's content layer describes a sandbox escape as a compromised renderer abusing a more privileged browser-process interface to read local files or run code on the host OS. No published record for CVE-2026-85046 establishes that second vulnerability or an exploit chain that crosses the process boundary.
Why a renderer compromise is serious
Chrome's architecture is designed around the possibility that hostile web content may take over a renderer. The browser sandbox, IPC validation, and Site Isolation then restrict what that process can reach. According to the Chromium threat model, a compromised renderer can forge IPC messages and attempt to impersonate an extension content script. More privileged components are supposed to reject requests the renderer is not authorized to make.
That makes CVE-2026-85046 a useful first stage for an attacker. A second flaw in IPC handling, the browser process, a driver, or the operating system could take the attack farther. The current advisories do not report such a chain. They also do not identify the targets, delivery method, or scale of the observed exploitation. Google's precise statement is only that it is aware of an exploit in the wild, while the underlying Chromium issue remains access restricted.
The exploitation evidence was strong enough for the US Cybersecurity and Infrastructure Security Agency to add the flaw to its Known Exploited Vulnerabilities catalog on September 4, one day after Google's release. CISA set a September 18 remediation deadline for covered federal systems. Its entry lists ransomware use as unknown and says the bug could affect several Chromium browsers, naming Chrome, Microsoft Edge, and Opera.
CISA's wording also shows why "all Chromium versions" is too broad. A shared V8 codebase creates potential exposure across browsers, but each vendor ships its own builds and security updates. Google's 152.0.7977.82 threshold is a Chrome version, not a universal version number for Edge or Opera. Administrators need the matching advisory from every browser vendor in their fleet.
Patch behavior is part of the exposure
Google says the fixed desktop release will roll out over days or weeks. Chrome can fetch updates in the background, but its update instructions say the new build takes effect after the browser relaunches. A laptop with Chrome left open for days may therefore have downloaded a security release without applying it. Opening Help > About Google Chrome checks the version and offers a Relaunch button when an update is pending.
For Windows and macOS, the September 3 advisory lists 152.0.7977.82/.83 as the fixed stable builds. Linux is listed at 152.0.7977.82, and Google's help page tells Linux users to update through their package manager. Managed environments should verify the running version after restart rather than treating a successful download or software-distribution job as proof that the vulnerable process has gone away.
The cited Google release covers desktop Chrome. CISA's catalog supplies the broader warning for Chromium-based products but does not supply each vendor's fixed build. Teams should inventory alternate browsers and kiosk installations, then use the version guidance issued by those vendors. Copying Chrome's version threshold into a fleet-wide compliance rule would produce false results for products with different numbering.
CISA directs covered agencies to apply vendor mitigations by September 18 under its current risk-based patching directive. For everyone else, that deadline is still a useful signal about priority: the catalog only includes vulnerabilities with evidence of exploitation. The CISA entry does not provide a workaround, so updating and restarting the affected browser is the documented response.
The evidence gap is deliberate
Google credits researcher Salvatore Gulizia, also known as Serotav, with reporting the bug on August 4 and lists a $1,000 reward. The company says it may keep bug details and links restricted until most users have the fix. Restrictions may last longer when the same flaw exists in a third-party library whose other users have not yet patched it. That policy explains why the public record has a CVE description and fixed versions but no technical exploit narrative.
The NVD score should be read alongside the live-exploitation finding. Its 8.8 rating describes technical conditions and possible impact, including high effects on confidentiality, integrity, and availability within the scored scope. CISA separately marks exploitation as active. Neither record says how many people were attacked, and neither identifies a campaign. "In the wild" supports urgent patching; it does not support claims of a mass compromise.
The public facts now support a narrow conclusion. CVE-2026-85046 can turn a malicious page into native code execution in Chrome's renderer sandbox, and someone has used an exploit outside a lab. Chrome has shipped a fix, while CISA warns that other Chromium browsers may be affected. Evidence of a sandbox escape, host takeover, or a complete multi-bug chain has not been published.
Watch the individual browser advisories next, especially fixed build numbers for Chromium products beyond Chrome. Google's restricted issue may later reveal the faulty V8 path and whether the exploit crossed the V8 heap sandbox before landing in the renderer. CISA can also revise its catalog entry if ransomware use or forensic guidance changes. Until those records move, the defensible response is simple: update every affected browser, restart it, and verify the version that is actually running.