Loading story…
Google’s Site Isolation architecture was designed to limit the impact of renderer compromise by placing different sites into separate sandboxed processes and preventing most cross-site data from reaching the wrong renderer. The defense was rolled out broadly across desktop Chrome and later expanded to cover additional scenarios including compromised renderers, extension isolation, and selected Android use cases, adding protection beyond the Same Origin Policy and Chrome’s existing sandbox against threats such as UXSS and side-channel attacks including Spectre.
Researchers later showed that a browser-process use-after-free in Chrome’s InstalledAppProvider Mojo interface, tracked as Issue 1062091, could let an attacker with a compromised renderer escape that sandbox entirely. The flaw stemmed from a stale RenderFrameHost pointer retained after destruction, and the published exploit demonstrated a reliable path to browser-process code execution and an unsandboxed renderer by appending --no-sandbox to Chrome’s command line; Chromium-based Microsoft Edge was also affected, and the bug was reachable on desktop systems in Chrome Stable 81 before being moved behind an experimental flag in Chrome 82.
See affected versions and whether adversaries are exploiting it.
8 events from the most recent confirmed update back to the earliest known activity.
Theori said the vulnerable functionality tied to Issue 1062091 was later moved behind an experimental flag in Chrome 82.0.4065.0, limiting its exposure after being reachable in Chrome Stable 81 on desktop.
Theori reported that the Chrome browser-process use-after-free tracked as Issue 1062091 was introduced in Chrome 81.0.4041.0, creating a sandbox-escape condition via InstalledAppProvider.
Theori published technical details for exploiting Issue 1062091, a browser-process use-after-free in Chrome's InstalledAppProvider Mojo interface that allows a compromised renderer to escape the sandbox. The write-up noted Chromium-based Microsoft Edge was also affected.
Chromium further expanded Site Isolation by adding support for <webview> in Chrome 110.
Chromium later expanded Site Isolation with extension isolation in Chrome 92, extending process separation protections to browser extensions.
Starting in Chrome 77, Chromium partially enabled Site Isolation on Android devices with at least 2 GB of RAM for logged-in sites.
In Chrome 77, Chromium expanded Site Isolation on desktop to defend against fully compromised renderer processes and universal cross-site scripting attacks.
Chromium enabled Site Isolation by default for all sites on desktop platforms in Chrome 67 as a defense-in-depth measure against browser vulnerabilities, UXSS, and data leaks across sites.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Google fixed **CVE-2026-95301**, a high-severity Chromium Site Isolation bypass in the extensions accessibility-automation infrastructure. A compromised, site-locked web renderer could bind the previously unprotected `RendererAutomationRegistry` interface and register a rogue automation receiver without browser-side authorization. If a legitimate `chrome.automation` consumer was active, the rogue receiver could obtain serialized accessibility-tree data from other origins and tabs, including visible page text, non-password form values, ARIA content, and cross-site frame URLs; the flaw also had potential cross-profile and Incognito exposure. Chromium now verifies that the calling renderer hosts an enabled extension with automation permission and terminates unauthorized renderers; the fix was targeted for Chrome M154 release notes.
Sep 23, 2026
Google disclosed and patched two high-severity Chrome vulnerabilities that could let a remote attacker escape the browser sandbox on Android after first compromising the renderer process with a crafted HTML page. **CVE-2026-6920** affects the GPU component and is an out-of-bounds read (`CWE-125`) in Chrome versions prior to `147.0.7727.117`, while **CVE-2026-7345** affects the Feedback component through insufficient validation of untrusted input (`CWE-20`) in versions prior to `147.0.7727.138`. Google and Chromium classified both issues as **High** severity. The CVE records show both flaws were later updated with revised CVSS v3.1 assessments that increased their reported impact, reflecting sandbox-escape risk with confidentiality, integrity, and availability consequences once the renderer had been compromised. Google referenced the Chrome Releases blog and Chromium issue tracker for the disclosures, indicating that users and enterprises should update Chrome on Android to versions `147.0.7727.117` and `147.0.7727.138` or later, depending on the affected build, to remediate the exposed attack paths.
Jun 29, 2026
Google publicly released proof-of-concept exploit code for a long-unfixed Chromium vulnerability in the Browser Fetch API, exposing Chrome, Microsoft Edge, Brave, Opera, and other Chromium-based browsers to abuse by any malicious website a user visits. Researcher **Lyra Rebane** reported the flaw in late 2022, but it remained unresolved for years despite being internally classified as serious. The bug lets an attacker register a Service Worker and create a background fetch task that can persist as a covert communication channel, enabling browser monitoring, anonymous proxying, traffic redirection, and potential browser-based botnets; some implementations reportedly keep the connection alive even after the browser closes or the device reboots. At the same time, Google issued Chrome Stable Channel updates for versions before `148.0.7778.178/179`, and government and vulnerability trackers highlighted multiple newly disclosed flaws fixed in that release. Those included `CVE-2026-9120`, a high-severity WebRTC use-after-free that could allow remote code execution in the browser sandbox via a crafted HTML page; `CVE-2026-9126`, a DOM use-after-free with similar impact; and `CVE-2026-9121`, a GPU out-of-bounds read that could lead to heap corruption. The contrast between patched Chrome memory-corruption bugs and the still-unfixed Browser Fetch issue raised concern because the published exploit code lowers the barrier to abuse across millions of Chromium users, prompting recommendations to restrict Service Worker use, disable background fetch where possible, monitor outbound browser traffic, and consider browser isolation in enterprise environments.
Jun 29, 2026