Inappropriate implementation in WebAppInstalls in Google Chrome on Windows prior to 150

CVE-2026-14138 is an *inappropriate implementation* in Chrome's WebAppInstalls component — the subsystem that handles installable PWAs and the install/launch prompts. Per the advisory, versions of Chrome on Windows prior to 150.0.7871.47 rendered install-related UI in a way that a crafted page could exploit to mislead a user (CWE-451: User Interface (UI) Misrepresentation of Critical Information). No memory corruption, no sandbox escape — the payoff is a spoofed prompt that could trick a user into installing or launching something they didn't intend.

Google labels this MEDIUM (4.2) and the CVSS vector AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L matches the reality: network reachable, but high attack complexity, user interaction required, and impact capped at *low integrity / low availability, zero confidentiality*. In a fleet of 10,000 hosts running Chrome auto-update, this is a backlog item, not a fire. The vendor rating is honest; if anything real-world friction pushes it lower.

Why this verdict

• Impact ceiling is trivial — C:N/I:L/A:L. No code execution, no data theft, no privilege escalation. Worst case is a user tricked into installing a fake PWA that facilitates *follow-on* phishing already covered by other controls.
• High attack complexity — AC:H combined with UI:R means the attacker needs both a specific technical condition and a duped user. Two compounding friction points.
• Role multiplier: workstation only. Chrome runs on user endpoints; there is no domain-controller, hypervisor, IdP, PAM, or backup-admin variant of this bug. The blast radius is capped at the single user's browser session — no fleet, tenant, or domain pivot. Floor stays at LOW.
• Auto-update is the world's largest compensating control for Chrome. Enterprises on Chrome Browser Cloud Management or default Windows Update-for-Business channels will be patched before most teams finish reading the advisory.
• Compensating tooling is dense — Safe Browsing, SmartScreen, secure web gateway URL filtering, email link rewriting, MFA/FIDO2, and existing user phishing training all sit in the attack path.

Why not higher?

MEDIUM would be defensible if the impact vector included confidentiality or if there were an unpatched-population signal. Neither exists: the vector is C:N and auto-update rapidly drains exposure. Nothing in the chain terminates in a fleet-scale outcome.

Why not lower?

IGNORE is wrong because the bug is real, present in an internet-exposed attack surface (the browser), and phishing chains that end in credential theft do use trust-shifting UI tricks like this. It deserves the standard backlog patch, not a rationale-only dismissal.

1. Let Chrome auto-update do its job — Confirm ChromeAutoUpdate and UpdateDefault GPO/registry settings are enabled fleet-wide; verify Chrome Browser Cloud Management reporting shows >95% of hosts on 150.0.7871.47 or later within 14 days. LOW verdict has no mitigation SLA — you have the full 365-day remediation window, but auto-update should close this in a week regardless.
2. Restrict PWA installation via enterprise policy — Set DefaultWebAppSettings to block_install or use WebAppInstallForceList to allow-list only approved PWAs. Deployed via GPO/MDM this neutralizes the exploit's payoff even on unpatched hosts.
3. Enforce Safe Browsing Enhanced Protection — Push SafeBrowsingProtectionLevel=2 via Chrome policy. Google's Safe Browsing catches the phishing lure well before the WebAppInstalls UI ever renders.
4. Confirm FIDO2/WebAuthn on identity provider — Since the terminal harm is credential-phishing amplification, phishing-resistant MFA (Okta FastPass, Entra passkeys, YubiKey) means a spoofed PWA cannot cash out into an account takeover.

Run on any Windows host as a standard user (elevation not required). Example: .\Check-CVE-2026-14138.ps1. Detects installed Chrome version across per-user and per-machine install paths and compares to the fixed build 150.0.7871.47.

#Requires -Version 5.0
# Check-CVE-2026-14138.ps1
# Detects Google Chrome versions vulnerable to CVE-2026-14138 (WebAppInstalls UI spoof)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN/NotInstalled

$fixed = [Version]'150.0.7871.47'
$paths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
    "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)

$found = $false
$vuln  = $false

foreach ($p in $paths) {
    if (Test-Path $p) {
        $found = $true
        try {
            $v = [Version](Get-Item $p).VersionInfo.ProductVersion
            Write-Host "[+] Chrome found at $p -> $v"
            if ($v -lt $fixed) {
                Write-Host "    VULNERABLE (fixed in $fixed)" -ForegroundColor Red
                $vuln = $true
            } else {
                Write-Host "    PATCHED" -ForegroundColor Green
            }
        } catch {
            Write-Host "[!] Could not parse version at $p" -ForegroundColor Yellow
        }
    }
}

if (-not $found) {
    Write-Host 'UNKNOWN: Google Chrome not installed on this host'
    exit 2
}
if ($vuln) { Write-Host 'VULNERABLE'; exit 1 }
Write-Host 'PATCHED'; exit 0

Sources

1. Chrome Releases – Stable Channel Update for Desktop
2. NVD entry for CVE-2026-14138
3. CWE-451: User Interface (UI) Misrepresentation of Critical Information
4. Chromium Issue Tracker (embargoed bugs list)
5. Chrome Enterprise policy: DefaultWebAppSettings
6. Chrome Enterprise policy: SafeBrowsingProtectionLevel
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS scoring model