Google Chrome CVE-2026-106320

Exploitation requires that the attacker has FIRST compromised Chrome's renderer process through a separate vulnerability - this is the primary gating prerequisite and makes the flaw a post-exploitation capability, not an initial entry point. Beyond that, the victim must load a crafted HTML page (UI:R in the vector), and the high attack complexity (AC:H) implies non-trivial timing or state conditions to win the use-after-free. The impact is limited to spoofing UI elements (misleading the user), not direct code execution or data theft. Limiting factors: no standalone remote exploitation is possible without the prior renderer compromise, user interaction is mandatory, and all fixed versions at or above 155.0.8059.39 are unaffected.

This is a genuinely low-priority issue despite being a network-vector Chrome flaw, and the signals are consistent in pointing that way. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L) yields only 4.2, and Google/Chromium independently rated the security severity 'Low'. The single most important signal is in the description, not the vector: exploitation requires an attacker who has ALREADY compromised the renderer process. The CVSS vector does not capture this prerequisite (it shows PR:N, which reflects Chrome's convention of scoring from the compromised-renderer attack surface rather than treating renderer compromise as a privilege) - so taken alone the vector overstates ease of exploitation. Combined with AC:H and UI:R, real-world exploitability is very constrained: this is a secondary capability (UI spoofing) layered on top of a separate, more serious renderer compromise, not a standalone entry point. No EPSS score was supplied, so exploitation probability cannot be quantified. The vulnerability is not in CISA KEV and no proof-of-concept was referenced, so there is no public exploit identified at time of analysis. Conclusion: low real risk - patch in routine cycles rather than emergency.

An attacker who has already achieved code execution in Chrome's sandboxed renderer (via a separate bug) serves a crafted HTML page that exploits a use-after-free in UI handling to spoof browser UI elements (e.g., address bar or security indicators). The victim, trusting the spoofed chrome, may be deceived into divulging credentials or trusting a malicious page. High attack complexity and the renderer-compromise prerequisite make this a post-exploitation refinement rather than an initial-access vector; no public exploit was identified.