Inappropriate implementation in Extensions in Google Chrome prior to 149

CVE-2026-11239 affects Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. The flaw sits in the Extensions component and, per the supplied description, lets an attacker who has already compromised the renderer process attempt a privilege jump via crafted HTML. That prerequisite matters more than the headline: the attacker must already have landed code execution or equivalent control inside Chrome's sandboxed renderer first.

For enterprise patch triage, the supplied HIGH 7.5 overstates the standalone operational risk. This is not a clean unauthenticated remote compromise of a browser from scratch; it is a post-initial-browser-compromise chain step with narrow reach, no KEV listing, very low EPSS, and no public exploitation evidence I could verify. Chrome's own June 2, 2026 release notes also classify this CVE as Low, which better matches real-world fleet risk than the higher feed-supplied CVSS.

Why this verdict

• Requires prior renderer compromise: attacker position is not unauthenticated remote-from-nothing; it assumes a separate successful browser exploit stage already happened.
• Exposure population is narrower than the CVSS suggests: only endpoints still running pre-149.0.7827.53 builds and reachable by a reliable browser exploit chain are candidates.
• No active exploitation signal: no KEV, no verified public PoC, and very low EPSS all argue against emergency fleet reprioritization.

Why not higher?

A higher severity would fit a browser bug that provides first-stage remote code execution, broad one-click compromise, or confirmed in-the-wild chaining. This CVE does none of that on its own; it is valuable mainly to an attacker who has already won the hardest part of the intrusion path.

Why not lower?

It is still a browser trust-boundary issue in a massively deployed product, and chainable Chrome bugs deserve respect even when they are not first-stage footholds. If paired with a renderer exploit, this type of flaw can materially improve attacker outcomes, so it should not be ignored outright.

1. Verify browser auto-update health — Confirm managed Chrome rings are actually moving to 149.0.7827.53/54 or later and that update holds are justified. For a LOW verdict there is no SLA; treat this as backlog hygiene and close the version gap in normal client maintenance.
2. Tighten extension governance — Restrict extension installation with allowlists or approved publishers where feasible, because the bug lives in the Extensions attack surface and reduced extension sprawl lowers reachable complexity. For LOW, do this through standard policy hygiene rather than an emergency change.
3. Prioritize browser exploit telemetry — Look for suspicious child-process behavior, repeated browser crashes, exploit-kit style web hits, and renderer/browser process anomalies in EDR and proxy data. This helps catch the *first-stage* compromise that CVE-2026-11239 depends on.
4. Audit release pins and legacy channels — Find endpoints stuck on pinned desktop builds, VDI gold images, kiosk baselines, or disconnected systems that may lag Chrome stable. LOW severity means no emergency deadline, but these laggards are where browser bugs linger longest.

Run this on a Windows target host or through your endpoint management tool to check the locally installed Chrome version. Invoke with powershell -ExecutionPolicy Bypass -File .\check-cve-2026-11239.ps1; no admin rights are required for the registry reads used here, though SYSTEM or an admin context is fine for fleet automation.

# check-cve-2026-11239.ps1

# Outputs: VULNERABLE / PATCHED / UNKNOWN

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


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

function Get-ChromeVersion {
    $paths = @(
        'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
        'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
        'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
    )

    foreach ($path in $paths) {
        try {
            if (Test-Path $path) {
                $p = Get-ItemProperty -Path $path
                if ($p.version) {
                    return $p.version
                }
            }
        } catch {
            # continue

        }
    }

    $exePaths = @(
        "$Env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "$Env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
        "$Env:LocalAppData\Google\Chrome\Application\chrome.exe"
    )

    foreach ($exe in $exePaths) {
        try {
            if (Test-Path $exe) {
                $ver = (Get-Item $exe).VersionInfo.ProductVersion
                if ($ver) {
                    return $ver
                }
            }
        } catch {
            # continue

        }
    }

    return $null
}

try {
    $installed = Get-ChromeVersion

    if (-not $installed) {
        Write-Output 'UNKNOWN: Google Chrome version not found on this host.'
        exit 2
    }

    try {
        $installedVersion = [version]$installed
    } catch {
        Write-Output "UNKNOWN: Unable to parse installed Chrome version '$installed'."
        exit 2
    }

    if ($installedVersion -lt $fixedVersion) {
        Write-Output "VULNERABLE: Installed Chrome version $installedVersion is older than fixed version $fixedVersion."
        exit 1
    } else {
        Write-Output "PATCHED: Installed Chrome version $installedVersion is at or newer than fixed version $fixedVersion."
        exit 0
    }
} catch {
    Write-Output "UNKNOWN: $($_.Exception.Message)"
    exit 2
}

Sources

1. Google Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
2. Google Chrome Releases index for 2026
3. Chromium issue tracker entry referenced by Google's release notes
4. Chromium Security overview
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST EPSS data/statistics
8. Chrome Enterprise and Education release notes