Out of bounds read in ANGLE in Google Chrome on Windows prior to 149

CVE-2026-11005 is an out-of-bounds read in ANGLE on Google Chrome for Windows affecting versions before 149.0.7827.53. Publicly available records describe it as a bug that a remote attacker who already compromised the renderer process can use via crafted HTML to read potentially sensitive process memory, which makes this a post-renderer-compromise information disclosure issue rather than a clean initial-access bug.

Reality is lower-drama than the words *remote attacker* suggest. The decisive friction is that the attacker must first land code execution or equivalent control inside Chrome's renderer, and only then use this ANGLE bug as a second-stage primitive; that puts it firmly in exploit-chain territory. Chromium's own public wording tags the underlying security severity as Medium, and that matches the real-world risk much better than a vacuum-scored browser memory bug would.

Why this verdict

• Post-compromise only: requires prior renderer compromise, which implies the attacker has already beaten Chrome's first security boundary. That is a major downward adjustment from any generic 'remote browser bug' intuition.
• Read primitive, not direct takeover: public wording points to obtaining sensitive process memory, not straight renderer RCE or guaranteed sandbox escape. Information disclosure can be useful in chains, but alone it is a smaller enterprise fire.
• Windows-only ANGLE path narrows population: this is not cross-platform Chrome-wide exposure. The bug sits behind a specific Windows graphics component and likely a narrower rendering path, which further reduces real reachable population.
• No KEV, no public PoC, negligible EPSS: there is no public sign that operators are actively using this CVE. With no exploitation evidence, no PoC, and effectively absent/very low EPSS, urgency stays moderate rather than high.

Why not higher?

It is not higher because the exploit chain starts with 'attacker already compromised the renderer'. That means this CVE is not your initial foothold problem; it is a chain-enabler whose value depends on another bug already succeeding. Also, the available public description points to memory disclosure, not a clean one-shot sandbox escape or browser-to-OS compromise.

Why not lower?

It is not lower because Chrome is everywhere, ANGLE is security-relevant on Windows, and memory disclosures inside exploit chains can materially improve reliability or leak useful secrets. Even as a second-stage primitive, it sits in a high-value target class and should not be ignored as mere noise.

1. Enforce Chrome auto-update — Make sure Windows endpoints are allowed to move to 149.0.7827.53 or later without user deferral. For a MEDIUM finding there is no mitigation SLA — go straight to the 365-day remediation window, but browsers are low-friction to update, so use your normal endpoint policy rather than treating this as exception work.
2. Block unsupported Chrome builds — Use endpoint management or application control to identify and suppress straggler installs below 149.0.7827.53. This reduces the long tail of unmanaged portable installs and should be completed within the 365-day remediation window for a MEDIUM issue.
3. Harden browser isolation for risky users — Keep or enable remote/browser isolation, high-risk browsing segmentation, or stricter web content controls for admins, developers, and finance users. This does not fix the bug, but it cuts the odds of the required first-stage renderer compromise; for MEDIUM there is no mitigation SLA, so fold this into your standing control program rather than a hotfix sprint.
4. Monitor for renderer-crash anomalies — Collect Chrome crash telemetry, GPU-process anomalies, and EDR detections around browser exploit behavior. That helps catch the prerequisite exploit stage this CVE depends on, and it can be operationalized during the same 365-day remediation window while patch coverage converges.

Run this on the target Windows endpoint or through your EDR/remote-management shell. Invoke with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11005.ps1; standard user rights are usually enough, but local admin helps if you want to inspect all-machine registry paths reliably. The script checks common Chrome install locations and registry version data, compares against the fixed build 149.0.7827.53, and prints VULNERABLE, PATCHED, or UNKNOWN.

# check-chrome-cve-2026-11005.ps1

# Purpose: Determine whether Google Chrome on Windows is vulnerable to CVE-2026-11005

# Affected: Chrome on Windows prior to 149.0.7827.53

# Output: VULNERABLE / PATCHED / UNKNOWN

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


$ErrorActionPreference = 'SilentlyContinue'
$fixedVersion = [version]'149.0.7827.53'

function Get-RegistryVersion {
    param([string]$Path)
    try {
        $item = Get-ItemProperty -Path $Path -ErrorAction Stop
        if ($item.version) { return $item.version }
    } catch {}
    return $null
}

function Get-FileVersion {
    param([string]$Path)
    try {
        if (Test-Path $Path) {
            return (Get-Item $Path).VersionInfo.ProductVersion
        }
    } catch {}
    return $null
}

function Normalize-Version {
    param([string]$VersionString)
    if ([string]::IsNullOrWhiteSpace($VersionString)) { return $null }
    try {
        # Strip non-numeric suffixes if present

        $clean = ($VersionString -replace '[^0-9\.]', '')
        return [version]$clean
    } catch {
        return $null
    }
}

$checks = @()

# Registry: machine-wide and per-user Chrome update/client state keys

$regPaths = @(
    'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
    'HKCU:\SOFTWARE\Google\Chrome\BLBeacon',
    'HKLM:\SOFTWARE\WOW6432Node\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}',
    'HKLM:\SOFTWARE\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}'
)
foreach ($rp in $regPaths) {
    $v = Get-RegistryVersion -Path $rp
    if ($v) {
        $checks += [pscustomobject]@{ Source = $rp; VersionString = $v }
    }
}

# Common executable locations

$filePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
    "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
foreach ($fp in $filePaths) {
    $v = Get-FileVersion -Path $fp
    if ($v) {
        $checks += [pscustomobject]@{ Source = $fp; VersionString = $v }
    }
}

if (-not $checks -or $checks.Count -eq 0) {
    Write-Output 'UNKNOWN - Google Chrome not found in common registry keys or file paths.'
    exit 2
}

$parsed = @()
foreach ($c in $checks) {
    $ver = Normalize-Version -VersionString $c.VersionString
    if ($ver) {
        $parsed += [pscustomobject]@{ Source = $c.Source; Version = $ver }
    }
}

if (-not $parsed -or $parsed.Count -eq 0) {
    Write-Output 'UNKNOWN - Chrome found, but version could not be parsed.'
    exit 2
}

# If any discovered install is below fixed version, treat host as vulnerable.

$vuln = $parsed | Where-Object { $_.Version -lt $fixedVersion }
$patched = $parsed | Where-Object { $_.Version -ge $fixedVersion }

if ($vuln) {
    $details = ($vuln | ForEach-Object { "$($_.Version) [$($_.Source)]" }) -join '; '
    Write-Output "VULNERABLE - Found Chrome version(s) below $fixedVersion: $details"
    exit 1
}

if ($patched) {
    $details = ($patched | ForEach-Object { "$($_.Version) [$($_.Source)]" }) -join '; '
    Write-Output "PATCHED - Found Chrome version(s) at or above $fixedVersion: $details"
    exit 0
}

Write-Output 'UNKNOWN - Unable to determine Chrome patch status conclusively.'
exit 2

Sources

1. Google Chrome Stable Channel Update for Desktop (Chrome 149)
2. Quanteta record for CVE-2026-11005
3. ANGLE README
4. Chromium Multi-process Architecture
5. Chromium Sandbox design docs
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS API documentation
8. ANGLE fix commit linked to Chromium bug 495052581