Google Chrome CVE-2026-79098

Exploitation requires the victim to visit a crafted HTML page served by the attacker and to interact with the spoofed PermissionElement - social engineering is explicitly stated as a prerequisite in the CVE description. The CVSS vector confirms the attacker requires no authentication (PR:N) and no special network position, but user interaction is mandatory (UI:R); a passive drive-by without user action is not possible. Chrome versions prior to 152.0.7977.65 on desktop are vulnerable; auto-updated browsers are not. No special server-side configuration or non-default Chrome settings are required to be vulnerable - any default Chrome installation below the fixed version visiting attacker-controlled content is in scope. Exploitation is limited to contexts where the user actively interacts with an attacker-controlled web page.

The CVSS 4.3 base score is technically reasonable: the attack is network-delivered (AV:N), low complexity (AC:L), requires no attacker privileges (PR:N), but mandates user interaction (UI:R), with impact confined to integrity (I:L) and no confidentiality or availability effects. EPSS at 0.17% (7th percentile) is among the lowest observable exploitation probability signals, reinforcing Chromium's own Low severity classification. No CISA KEV listing exists, and no public proof-of-concept has been identified. The real-world risk is further moderated by Chrome's auto-update infrastructure, which deploys patches to most desktop installations within days of release without user action - meaning the effective vulnerable population shrinks rapidly post-patch. The primary residual concern is for managed enterprise fleets with delayed update rollouts, where the permission-spoofing primitive could be chained with social engineering campaigns targeting specific capability grants. There is no evidence of opportunistic mass exploitation, making this a low-urgency patch item for organizations with standard patch cadences.

An attacker crafts an HTML page that manipulates Chrome's PermissionElement rendering to display a spoofed permission dialog - for instance, making a microphone or geolocation access request visually indistinguishable from a harmless UI control or a trusted system prompt. A user visiting the page via a phishing link or malvertising is deceived into clicking through the spoofed prompt, unknowingly granting the attacker's origin access to a sensitive browser capability. No public proof-of-concept code has been identified at time of analysis.