Google Chrome CVE-2026-8001

Exploitation requires attackers to already control the Chrome renderer process through a prior, separate vulnerability - this is NOT a standalone exploit. The victim must visit the attacker's crafted HTML page and trigger the printing subsystem (through print preview, print dialog, or programmatic print API calls). The use-after-free is specifically exploitable on Linux, macOS, and ChromeOS builds of Chrome below 148.0.7778.96; Windows builds are not vulnerable. The two-stage attack chain (initial renderer compromise + sandbox escape) significantly limits exploitation compared to single-stage remote code execution vulnerabilities. Requires user interaction (UI:R in CVSS vector) to visit the malicious page and high attack complexity (AC:H) due to the prerequisite renderer exploit and precise heap manipulation timing needed to trigger the use-after-free.

Real-world risk assessment reveals significant nuance beyond the 8.3 CVSS score. The CVSS vector (AV:N/AC:H/PR:N/UI:R/S:C) indicates network-based attack with high complexity requiring user interaction and scope change (sandbox escape), which correctly captures the two-stage nature. However, Chromium's own Low severity rating reflects critical context: exploitation requires the attacker to FIRST compromise the renderer process through a separate vulnerability, then leverage this use-after-free for sandbox escape. This prerequisite substantially reduces real-world exploitability compared to a standalone remote code execution. The high attack complexity (AC:H) aligns with this multi-stage requirement. No EPSS score, KEV listing, or POC availability signals suggest limited immediate threat. The required user interaction (UI:R) adds friction - victims must visit the malicious page and trigger print functionality. For security teams, this is a defense-in-depth concern rather than an emergency: patch during regular update cycles, but recognize that successful exploitation requires chaining with another renderer exploit, making it primarily relevant to targeted attack scenarios rather than opportunistic mass exploitation.

An attacker first compromises Chrome's renderer process through a separate vulnerability (e.g., JavaScript engine exploit delivered via malicious website). With renderer access established, the attacker serves a second-stage crafted HTML page that triggers the printing subsystem's use-after-free flaw. By manipulating heap memory through carefully timed print operations, the attacker executes code outside the sandbox, gaining full system privileges and ability to install malware, access local files, or pivot to network resources. No public exploit identified at time of analysis.