Insufficient validation of untrusted input in Printing in Google Chrome on Windows prior to 149

The public record points to an *improper input validation* bug in Chrome's Windows printing path affecting versions prior to 149.0.7827.53. The title supplied in your intel is truncated, but the surrounding Chrome 149 records and Google's normal wording strongly suggest this is a post-renderer-compromise bug in the print/broker boundary on Windows, meaning the attacker still needs to get code or control inside the renderer first and then use printing to cross into a more privileged context.

That is why the vendor's CRITICAL 9.6 feels too hot in operational terms. A browser sandbox escape on a ubiquitous client is never trivial, but once a CVE requires a prior renderer compromise, it stops being a clean initial-access bug and becomes a *chain component*; that sharply reduces reachable population and makes modern controls like browser isolation, EDR, and fast Chrome auto-update much more relevant.

Why this verdict

• Start at vendor 9.6: if this were truly a one-bug remote browser-to-host break on ubiquitous Chrome, CRITICAL would be fair.
• Down for attacker position: the available wording strongly implies the attacker must *already have compromised the renderer process*; that means this CVE is not initial access, it is a *post-compromise escape step*.
• Down for reachable population: Windows-only scope and a print-path dependency reduce the fraction of real sessions that can actually drive the vulnerable code path reliably.
• Down for threat evidence: no KEV listing, no public PoC found, and EPSS 0.00047 argue against immediate mass exploitation pressure.
• Not below HIGH: when this kind of flaw is chainable, the blast radius is still endpoint-level because it can collapse Chrome's sandbox boundary on a very widely deployed client.

Why not higher?

I am not keeping this at CRITICAL because the hardest step in the chain appears to happen *before* this CVE becomes relevant: the attacker must first own or meaningfully control the renderer. That prerequisite compounds with Windows-only scope and no current exploitation evidence, which is too much friction for a top bucket.

Why not lower?

I am not dropping this to MEDIUM because browser sandbox escapes are premium exploit-chain components, and Chrome on Windows is a massive enterprise population. Once paired with any renderer bug or malicious extension foothold, the outcome can jump from browser-only compromise to host impact quickly.

1. Force Chrome auto-update and relaunch — Use enterprise policy or endpoint management to push Chrome to 149.0.7827.53+ and force a relaunch on Windows systems; for a HIGH verdict, deploy this control within 30 days if patch completion is not immediate.
2. Isolate high-risk browsing — Put admins, finance, developers, and other high-target users behind browser isolation or remote browsing where available. This is the best interim control when the bug is web-delivered but not directly network-scannable; deploy within 30 days.
3. Constrain Chrome child-process execution — Harden chrome.exe through EDR policy, Attack Surface Reduction, WDAC/AppLocker, or equivalent so a successful sandbox escape has fewer post-exploitation options. This does not fix the bug, but it raises the cost of turning the escape into durable endpoint compromise; deploy within 30 days.
4. Prioritize laggards and unmanaged Windows endpoints — Find systems with disabled Chrome auto-update, kiosk builds, VDI gold images, and persistent-session endpoints. Those are where a client-side browser flaw stays alive longest; put them under compensating restrictions within 30 days.

Run this on the target Windows endpoint or via your RMM/EDR live response shell. Invoke with powershell.exe -ExecutionPolicy Bypass -File .\Test-Chrome-CVE-2026-10971.ps1; standard user rights are usually enough because it reads file and registry version data only.

#requires -version 5.1
<#
Test-Chrome-CVE-2026-10971.ps1
Checks Google Chrome on Windows against the fixed version for CVE-2026-10971.
Outputs one of: VULNERABLE / PATCHED / UNKNOWN
Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
#>

$FixedVersion = [version]'149.0.7827.53'

function Get-ChromeVersion {
    $paths = @(
        "$Env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "$Env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
        "$Env:LocalAppData\Google\Chrome\Application\chrome.exe"
    )

    foreach ($p in $paths) {
        if (Test-Path $p) {
            try {
                $fv = (Get-Item $p).VersionInfo.FileVersion
                if ($fv) {
                    return [PSCustomObject]@{ Source = $p; Version = $fv }
                }
            } catch {}
        }
    }

    $regPaths = @(
        'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
        'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
        'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
    )

    foreach ($rp in $regPaths) {
        try {
            $item = Get-ItemProperty -Path $rp -ErrorAction Stop
            if ($item.version) {
                return [PSCustomObject]@{ Source = $rp; Version = $item.version }
            }
        } catch {}
    }

    return $null
}

function Normalize-Version([string]$v) {
    try {
        return [version]$v
    } catch {
        return $null
    }
}

$chrome = Get-ChromeVersion
if (-not $chrome) {
    Write-Output 'UNKNOWN: Google Chrome not found via common file paths or BLBeacon registry keys.'
    exit 2
}

$installed = Normalize-Version $chrome.Version
if (-not $installed) {
    Write-Output ("UNKNOWN: Found Chrome version string '{0}' from {1}, but could not parse it." -f $chrome.Version, $chrome.Source)
    exit 2
}

if ($installed -lt $FixedVersion) {
    Write-Output ("VULNERABLE: Google Chrome {0} detected at {1}; fixed version is {2} or later." -f $installed, $chrome.Source, $FixedVersion)
    exit 1
} else {
    Write-Output ("PATCHED: Google Chrome {0} detected at {1}; meets or exceeds fixed version {2}." -f $installed, $chrome.Source, $FixedVersion)
    exit 0
}

Sources

1. Google Chrome Releases - Early Stable Update for Desktop
2. Google Chrome Releases - Stable Channel Update for Desktop
3. Canadian Centre for Cyber Security advisory AV26-544
4. GovCERT.HK Security Alert A26-06-08
5. FIRST EPSS API documentation
6. FIRST EPSS query endpoint for this CVE
7. CISA Known Exploited Vulnerabilities Catalog
8. NVD reference pattern: Chrome 149 post-renderer sandbox escape record