Google Chrome CVE-2026-11635

Exploitation requires a prior compromise of the Chrome renderer process - this CVE is a sandbox-escape primitive, not an initial-access bug, so a separate renderer RCE or comparable in-renderer code execution must be chained first. The target must be running Google Chrome on macOS at a version below 149.0.7827.103; non-Mac Chrome builds are out of scope per the description. User interaction is required (UI:R): the victim must visit attacker-controlled web content that delivers the crafted HTML page driving the vulnerable Bluetooth code path. Attack complexity is High (AC:H), consistent with the timing/heap-grooming typical of use-after-free exploitation. No authentication to the browser is needed (PR:N at the web-content boundary). Limiting factors that reduce realistic risk: the renderer-compromise prerequisite, the macOS-only scope, and the need for the victim to load the attacker's page in a vulnerable Chrome build.

Real-world risk is meaningful but conditional. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H) scores 8.3 with High attack complexity, required user interaction, and changed scope - the scope change reflects the sandbox escape, which is the principal danger. Crucially, the description states the attacker must already have compromised the renderer process, so this is realistically the second link in an exploit chain (typically paired with a separate renderer RCE), not a standalone one-click bug; that is why AC is High. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV, but Chromium's own Critical severity rating, combined with the historical pattern of Chrome sandbox-escape bugs being chained by commercial exploit vendors, means defenders should treat this as priority patching for macOS fleets rather than a low-risk theoretical issue. EPSS data was not provided in the input and cannot be cited.

A user with a vulnerable Chrome on macOS visits an attacker-controlled or compromised site (the UI:R interaction), where a first-stage exploit - a separate, prior renderer RCE - gains code execution inside the sandboxed renderer. The attacker then loads a crafted HTML page that drives the Web Bluetooth IPC pathway to trigger the use-after-free, reclaims the freed object with attacker-controlled data, and pivots code execution into the browser process, escaping the sandbox to access the user's files, keychain-protected secrets, and persistent state. No public exploit has been identified at time of analysis.