Google Chrome CVE-2026-106194

Exploitation requires a specific multi-stage setup, not a default-configuration remote hit: (1) the attacker must already have compromised the Chrome renderer process (typically via a separate vulnerability), (2) the victim must visit a crafted HTML page, and (3) social engineering must induce the user to interact with the WebAppInstalls flow (UI:R). The targeted feature is Chrome's WebAppInstalls (web app / PWA installation) functionality, where a missing authorization check (CWE-862) permits code to escape the sandbox. Limiting factors that reduce realistic risk: the mandatory prior renderer compromise, the required user interaction, and high attack complexity (AC:H) - together explaining the vendor's Medium severity rating despite the total technical impact. Mitigated in Chrome 155.0.8059.39 and later.

Signals conflict and must be weighed carefully. The input CVSS of 8.3 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H) reflects a scope-changing sandbox escape with total confidentiality, integrity and availability impact, which is why the numeric score lands in the High range - but Google's own Chromium severity rating is only Medium, signaling that in practice exploitation is heavily gated. The CVSS vector itself encodes those gates: AC:H (high attack complexity) and UI:R (user interaction required), and the description adds a further hard precondition - the attacker must FIRST have compromised the renderer process. SSVC reinforces a low operational priority: Exploitation 'none' (no observed or public exploitation), Automatable 'no' (cannot be reliably scripted at scale), with Technical Impact 'total' being the only elevated factor. There is no CISA KEV listing and no POC indicated, so this is no public exploit identified at time of analysis. Net: this is a genuine sandbox-escape primitive valued as a second-stage link in an exploit chain, not a standalone mass-exploitation threat. The headline 8.3 overstates real-world urgency relative to the vendor's Medium rating, the high complexity, and the renderer-compromise prerequisite; prioritize patching through normal Chrome auto-update cadence rather than as an emergency. Note the apparent tension to verify: PR:N marks it unauthenticated, yet the description requires a pre-compromised renderer - the vector treats that as a scenario precondition rather than a privilege on the vulnerable component.

An attacker who has already exploited a separate bug to gain code execution inside Chrome's sandboxed renderer lures the victim to a crafted HTML page and uses social engineering to get the user to interact with a WebAppInstalls prompt. The missing authorization check is then abused to install/execute code that crosses the sandbox boundary onto the host. No public exploit code is identified, and successful exploitation depends on a prior renderer compromise plus user interaction.