Google Chrome CVE-2026-106378

Exploitation requires the attacker to FIRST have compromised the Chrome renderer process (this is a sandbox escape, not an initial-access bug), then have the victim view a crafted HTML page on macOS running Chrome prior to 155.0.8059.39. Limiting factors: it is a chained second-stage exploit (cannot be used standalone), requires user interaction (UI:R - visiting the page), is platform-restricted to macOS, and CVSS AC:H plus SSVC 'Automatable: no' reflect the non-trivial renderer-compromise prerequisite. It affects default Chrome configurations (no special feature toggle needed) once the renderer is compromised.

Signals are mixed and point to a serious-but-not-emergency priority. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H) yields 8.3, but that score is misleading in isolation: this is a second-stage sandbox-escape (CWE-250, execution with unnecessary privileges) that per the description REQUIRES an already-compromised renderer process, which is why AC:H is set. It cannot be exploited alone - it must be chained with a separate renderer-RCE bug. This is consistent with SSVC (Exploitation: none, Automatable: no, Technical Impact: total): no observed exploitation and not automatable, but full impact once the chain succeeds. No EPSS score was provided, KEV status is not listed (treated as not present), and no public POC is referenced, so exploitation is 'no public exploit identified at time of analysis.' Note also that Google themselves rated the Chromium security severity as Medium, which conflicts with the 8.3 CVSS 'High' - the vendor's Medium rating reflects the renderer-compromise precondition that CVSS AC:H only partially captures. Net: a genuine high-impact escape worth patching promptly, but current real-world risk is moderate given the chaining requirement, no active exploitation, and not-automatable assessment.

An attacker first exploits a separate vulnerability to gain code execution inside Chrome's renderer process (e.g., via a malicious ad or compromised site), then lures a macOS user into viewing a crafted HTML page that triggers this sandbox flaw. The excessive privileges in the sandbox implementation let the attacker break out of the renderer sandbox and run arbitrary code with the browser's host-level privileges on the Mac. No public exploit code is identified at time of analysis, and the attack requires both a chained renderer compromise and user interaction.