Google Chrome CVE-2026-18018

Exploitation requires the attacker to have local file write access on the target Windows machine - either through an existing foothold, a prior vulnerability, or social engineering to deliver the malicious file. The victim must be running Google Chrome for Windows at a version below 151.0.7922.72. The Chrome Updater must execute (it runs periodically in the background on Windows, so this is a low bar once the file is placed). Limiting factors are significant: this is strictly a Windows-platform vulnerability; the attacker cannot exploit this remotely without a separate delivery mechanism; and the impact is limited to UI deception rather than code execution or data theft. Authentication is not required at the OS level to place a file as a standard user, but the attacker must already have some degree of local access to the machine.

Multiple signals converge on a low real-world priority. CVSS 4.0 base score is low, EPSS sits at 0.10% in the 1st percentile - virtually no observed exploitation attempts - and SSVC confirms no exploitation activity and non-automatable attack. The attack is local, requiring an adversary to first place a malicious file on the system, which presupposes existing local access or a prior delivery mechanism. Two notable data conflicts exist and must be flagged: (1) The provided CVSS vector includes A:L (Availability Low) as the primary impact metric, which is atypical for a CWE-451 UI spoofing vulnerability where Integrity impact (I:L) would be expected - this inconsistency is not explained by available sources and should be verified with the vendor. (2) The intelligence tags include 'Information Disclosure', which conflicts with the C:N (no confidentiality impact) in the CVSS vector - any information disclosure dimension is unconfirmed from available data. Despite Chrome's ubiquitous deployment, the combination of local-only attack vector, no exploitation, and low impact makes this a routine patch-cycle item rather than an emergency response trigger.

A local attacker with the ability to write files to the target Windows system - via a delivery mechanism such as phishing-dropped malware, a shared network path, or an existing low-privilege session - places a specially crafted file in a path monitored or read by the Chrome Updater. When the Updater runs (typically on a schedule or at browser launch), it processes the malicious file and renders a spoofed UI to the logged-in user, potentially impersonating a legitimate Chrome update prompt to manipulate the user's next action. No public exploit code exists at time of analysis.