Chrome CVE-2026-7910: Use-After-Free in Views (Site Isolation Bypass)

CVE-2026-7910 (CVSS 9.6) is a use-after-free in Chrome's Views component, flagged as a HIGH severity vulnerability by the Chromium team and exploitable from a compromised renderer to bypass site isolation — the fundamental security boundary that prevents a malicious site from reaching another site's data in the browser.

For organizations deploying Chrome at scale, this is a fast-push update: a malicious site capable of exploiting this CVE can potentially steal sessions, cookies, saved passwords, and authentication data from every other open tab.

Technical Details

The Views component

Views is Chrome's native UI library responsible for rendering interface components (tab bars, menus, dialog boxes, popups, omnibox). It runs in the main browser process — the most privileged process, which orchestrates the renderers (one per site under site isolation).

The bug

A use-after-free means an object is freed from memory while at least one pointer to it remains live. Subsequent use of the dangling pointer:

• On read: information disclosure (reads memory potentially reused for other data)
• On write: memory corruption, possible execution flow control
• With a reallocation gadget: arbitrary code execution

In CVE-2026-7910, exploitation assumes the renderer is already compromised — the attacker has already gained execution in the renderer sandbox (e.g., via another V8 or Blink exploit). From that renderer, the attacker can send malicious IPC messages to the browser process, trigger the UAF in Views, and gain execution in the un-sandboxed browser process.

Consequence: site isolation bypass

Site isolation guarantees that:

• Each site (origin) runs in its own sandboxed renderer process
• A site cannot read another site's memory, even if its renderer is compromised

CVE-2026-7910 breaks this guarantee: from a compromised renderer, the attacker escapes to the browser process, which sees all data from all sites that are open. Banking sessions, stored passwords, authenticated cookies — everything becomes accessible.

Characteristics

Affected Products and Versions

All Chromium-based browsers are potentially affected. Microsoft Edge, Brave, Opera, Vivaldi, Arc — all ship Chromium and inherit the vulnerability until they integrate the upstream fix.

Check your version

chrome://settings/help

Chrome auto-updates by default, but the actual rollout requires a browser restart. On an enterprise fleet without forced-restart GPO policy, hundreds of endpoints may run vulnerable versions for days.

Exploitation and Impact

Realistic attack scenario

1. Initial renderer compromise: the attacker hosts a page exploiting another Chrome CVE (V8, Blink, WebAssembly) to gain execution in the renderer sandbox. Such CVEs appear regularly (several per month on average).
2. Chained with CVE-2026-7910: from the compromised renderer, the attacker sends malicious IPC messages that trigger the UAF in Views.
3. Sandbox escape: execution in the browser process, which is not sandboxed.
4. Mass data theft: read session cookies from all sites, saved passwords, Chrome profile files, authentication tokens.
5. Persistence: modify Chrome configuration, install invisible extensions, capture keyboard via native APIs.

Why 9.6 and not 10

The CVSS score is slightly lowered by:

• UI:R (User interaction required) — the user must visit a malicious page
• S:C (Scope changed) — the exploit crosses the sandbox boundary to other components

But in practice, one visit is enough: any site, even an ad injected on a legitimate site via a compromised ad network, can serve as initial access.

Detection and IOCs

On endpoints

• Check deployed Chrome version across the fleet:

# Windows — via PowerShell
Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe" | \
  Select-Object @{N='Version';E={$_.VersionInfo.ProductVersion}}

# macOS
mdls -name kMDItemVersion "/Applications/Google Chrome.app"

# Linux
google-chrome --version

Network logs

• Chrome traffic to unusual CDNs/tracking sites
• Abnormal outbound HTTPS connections after certain page visits (pattern: visit → 10 min → bulk exfiltration to exotic IP)

Indicators of compromise

• Valid session cookies used from unusual IPs/agents (visible server-side on the affected app)
• Unexpected Chrome extensions appearing without user action
• Modified Chrome profiles (new signature in Local State or Preferences)

Mitigation and Patch

For individual users

1. Force the update: chrome://settings/help → wait for download → click Relaunch
2. Fully restart Chrome (not just close the window) for the update to apply

For IT administrators — fleet deployment

Windows (GPO + auto-update)

# Check auto-updates are active
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Update" -Name UpdateDefault

# Force a scheduled Chrome restart via GPO
# Computer Configuration → Administrative Templates → Google → Google Chrome → Restart...

macOS

# Check version across the fleet via MDM (Jamf, Kandji, Intune)
# Force-quit + relaunch policy after critical update

Linux

# Debian/Ubuntu
sudo apt update && sudo apt upgrade google-chrome-stable

# RHEL/Fedora
sudo dnf upgrade google-chrome-stable

Temporary workaround (no immediate update)

• Disable JavaScript on non-essential sites (major UX impact, unrealistic)
• Use a patched alternative browser in the meantime
• Restrict web access to whitelisted sites on sensitive endpoints

Why Continuous Monitoring of Browsers and Endpoints Matters

Browsers are the primary entry door for attacks on end users: 90% of malware comes through the web. Chrome receives, on average, 2 to 4 CRITICAL or HIGH CVEs per month, and the window between disclosure and public exploitation is days. A fleet where 30% of endpoints still run an unpatched Chrome is an immediate target.

With cveo.tech, inventory the browsers deployed across your fleet (Chrome, Edge, Firefox, Safari) and get automatic alerts when a critical CVE targets one of your exact versions — so you can push updates via GPO/MDM before exploits land at scale.