Google Chrome CVE-2026-106391

Exploitation requires the attacker to have ALREADY compromised the Chrome renderer process on the target Android device (per the description) - this is the primary gating precondition and is not a default state. It additionally requires the victim to interact with a crafted HTML page (UI:R), and it is specific to Chrome on Android versions prior to 155.0.8059.39; desktop and other platforms are out of scope per the description. The bug lies in the WebShare feature's authorization handling (CWE-863). Limiting factors: no separate login/authentication is needed (PR:N), but the compromised-renderer requirement plus mandatory user interaction make unassisted, widespread exploitation impractical, consistent with SSVC Exploitation 'none' and Automatable 'no'. The outcome is limited to UI/element spoofing, not code execution or data exfiltration.

This is a genuinely low-priority issue despite the medium Chromium label. The CVSS base score of 4.2 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L) reflects limited impact, and the single most important qualifier is baked into the description: exploitation requires an attacker who has ALREADY compromised the renderer process. That precondition is why AC is High and why this is realistically a sandbox-escape-adjacent polish bug rather than a primary attack vector - an attacker who controls the renderer must first have obtained that foothold through a separate, more serious vulnerability. All exploitation signals point the same direction: SSVC rates Exploitation as 'none', Automatable 'no', and Technical Impact only 'partial'; there is no EPSS score supplied; KEV status is not listed (no active exploitation); and no POC is referenced. Accordingly: no public exploit identified at time of analysis. One tension worth flagging: the CVSS vector encodes PR:N (unauthenticated), but the description's requirement of a compromised renderer is a substantial real-world prerequisite that the base vector does not capture - Chrome conventionally scores post-renderer-compromise bugs as PR:N because no application-level credentials are needed, but defenders should read PR:N as 'no login required' and NOT as 'trivially remote against a healthy browser.' The practical outcome is UI spoofing (deception), not code execution or data theft.

An attacker first compromises the Chrome renderer process on an Android device via a separate vulnerability, then serves a crafted HTML page that abuses the WebShare API's incorrect authorization to spoof trusted UI elements (e.g., share-sheet or origin indicators) and trick the user. The deception requires user interaction (UI:R) to be effective, and no public exploit code is currently identified; the realistic goal is phishing/social-engineering rather than direct system compromise.