Google Chrome EUVD-2026-36347

Exploitation requires the attacker to have already compromised the Chrome renderer process via a separate vulnerability and to deliver a crafted HTML page that is processed by the Headless component - so this is strictly a second-stage sandbox-escape primitive, not a standalone remote bug. Practical limits: the victim must load attacker-controlled HTML (UI:R per the CVSS vector), Chrome must be on a version below 149.0.7827.115, and a working renderer exploit for the same Chrome build must be available. Headless-mode deployments (automation, CI, server-side rendering) that fetch untrusted URLs are particularly exposed because they automate the 'user interaction' step.

The headline CVSS 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) reflects worst-case impact assuming a renderer is already compromised, but the description itself confirms exploitation chains a prior renderer RCE - so PR:N somewhat understates the real precondition. EPSS at 0.03% (11th percentile) and the absence of any public POC or CISA KEV listing suggest no observed mass exploitation; the threat profile matches a sandbox-escape chain link that is most useful to targeted attackers (e.g., n-day chains by commercial vendors) rather than commodity malware. Real-world priority should still be high because Chrome auto-updates are widely deployed and a single chained renderer bug would convert this into full browser compromise - the gating factor is patch rollout, not raw probability.

An attacker hosts a malicious HTML page that first exploits a separate renderer-process vulnerability to gain code execution inside the sandboxed renderer, then triggers the Headless-component flaw to escape the sandbox into the more privileged browser process. In a Headless automation pipeline, a worker fetching attacker-controlled URLs (e.g., a screenshotting or PDF-rendering service) would be the most realistic target. No public exploit is identified at time of analysis, but the bug is a high-value link in a renderer-to-RCE chain.