Inappropriate implementation in Dawn in Google Chrome prior to 149

CVE-2026-11086 is an *inappropriate implementation* flaw in Chrome's Dawn component, the WebGPU stack. Affected versions are Chrome desktop builds prior to 149.0.7827.53; Google's rollout notes show 149.0.7827.53/.54 for Windows and macOS early stable, and 149.0.7827.53 for Linux. The public description matters more than the vendor CVSS here: exploitation assumes the attacker has already compromised the renderer process and can then drive the vulnerable Dawn path.

The vendor's HIGH 8.8 overstates real-world urgency for enterprise patch triage because the attack does not begin from a clean unauthenticated web visit; it begins after a separate browser exploit stage has already succeeded. That makes this a *post-initial-browser-compromise* primitive, likely useful for sandbox escape or privilege expansion inside the browser architecture, but much less useful as a standalone mass-compromise bug.

Why this verdict

• Start from 8.8, then cut for attacker position: this is not unauthenticated remote initial access in practice; it requires a prior renderer compromise, which implies the attacker is already mid-chain.
• Cut again for reachable population: only a subset of real-world browser sessions will line up with a successful first-stage exploit *and* the right Dawn/WebGPU path, GPU stack, and target conditions.
• No exploitation signal to offset that friction: no KEV listing, no public in-the-wild note reviewed, and the supplied EPSS 0.00078 does not argue for emergency handling.

Why not higher?

A higher rating would fit a one-click or no-click browser RCE that starts from a normal web visit. This CVE does not appear to be that. The renderer-compromise prerequisite is a compounding constraint that turns this into a chain component rather than a broadly weaponizable standalone bug.

Why not lower?

It should not be pushed to LOW or IGNORE because Chrome is everywhere and post-renderer escape primitives are exactly the sort of bug advanced operators want for full exploit chains. If an attacker already has a renderer foothold, this kind of flaw can convert a contained browser compromise into a materially worse endpoint event.

1. Verify Chrome auto-update health — Confirm managed endpoints are actually receiving Stable/Early Stable browser updates and that no rings are pinned below 149.0.7827.53. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but in practice you should clear browser-update drift in the next normal desktop patch cycle rather than letting stragglers age.
2. Use browser isolation for high-risk users — For admins, developers, executives, and users who routinely browse untrusted sites, steer risky sessions into browser isolation or hardened VDI profiles. There is no mitigation SLA for this severity, so use this as a targeted risk reducer when patch rollout is delayed, not as an emergency fleetwide action.
3. Tighten web destination controls — Apply URL allow/block policies, DNS filtering, and category-based web filtering to reduce exposure to attacker-controlled content that could host a first-stage renderer exploit. Again, there is no mitigation SLA here, so prioritize this where user behavior or threat model justifies it.
4. Hunt on browser exploit telemetry — Review EDR and crash telemetry for exploit-prevention events, anomalous chrome.exe child processes, suspicious file writes by browser processes, and spikes in renderer/GPU crashes. This matters because your best control point is often detecting the first-stage exploit attempt, not this CVE in isolation.

Run this on each Windows endpoint that has Chrome installed, or push it through Intune/SCCM/RMM. Invoke it as powershell.exe -ExecutionPolicy Bypass -File .\Test-CVE-2026-11086.ps1; standard user rights are enough because it only reads file versions from common install paths.

# Test-CVE-2026-11086.ps1

# Checks installed Google Chrome version against fixed build 149.0.7827.53

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


param()

$FixedVersion = [version]'149.0.7827.53'
$Candidates = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
    "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)

function Get-ChromeVersion {
    param([string[]]$Paths)

    foreach ($Path in $Paths) {
        if (Test-Path -LiteralPath $Path) {
            try {
                $Item = Get-Item -LiteralPath $Path -ErrorAction Stop
                $VersionText = $Item.VersionInfo.ProductVersion
                if (-not [string]::IsNullOrWhiteSpace($VersionText)) {
                    $Clean = ($VersionText -split '\s+')[0]
                    return [pscustomobject]@{
                        Path = $Path
                        VersionText = $Clean
                        Version = [version]$Clean
                    }
                }
            }
            catch {
                # Keep trying other paths

            }
        }
    }

    return $null
}

$Chrome = Get-ChromeVersion -Paths $Candidates

if ($null -eq $Chrome) {
    Write-Output 'UNKNOWN - Google Chrome not found in standard install paths'
    exit 2
}

if ($Chrome.Version -lt $FixedVersion) {
    Write-Output ("VULNERABLE - Chrome {0} at {1} is older than fixed version {2}" -f $Chrome.VersionText, $Chrome.Path, $FixedVersion)
    exit 1
}
else {
    Write-Output ("PATCHED - Chrome {0} at {1} meets or exceeds fixed version {2}" -f $Chrome.VersionText, $Chrome.Path, $FixedVersion)
    exit 0
}

Sources

1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
2. Chrome Releases main page
3. Chromium Docs - Threat Model and Defenses Against Compromised Renderers
4. Chromium Docs - Sandbox design
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST EPSS API documentation
8. Chrome Enterprise - Manage Chrome updates