CVE-2026-11281 · Google Chrome on Windows Chromoting integer overflow via crafted ETW…

01 · The Real Story

This is more like a pickpocket in the employee break room than a burglar at the front door

CVE-2026-11281 is an integer overflow in the Chromoting code path of Google Chrome on Windows affecting versions prior to 149.0.7827.53. The public description says a local attacker can use a crafted ETW event to leak potentially sensitive data from process memory. That means the bug is about information disclosure, not direct code execution, and the attacker already needs a foothold on the endpoint with at least low privileges.

The vendor's MEDIUM 5.0 baseline is defensible in a vacuum, but it overstates operational urgency for most enterprises. The attack chain is heavily gated by local access, valid privileges, and a likely narrow Windows/Chromoting/ETW reachability path; those are classic post-compromise friction points. For a team managing 10,000 hosts, this is patch-worthy but not a front-of-queue event unless you are already dealing with endpoint compromise or have a special dependency on Chrome Remote Desktop/Chromoting features.

"This is a post-compromise Chrome info leak, not a fleet-wide fire drill."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution on the Windows endpoint

The attacker first needs a local foothold as a normal user. In practice that means a prior phish, malware run, stolen workstation session, or another local execution path using tools like powershell.exe, commodity loaders, or an RMM implant. This CVE does not provide initial access by itself.

Conditions required:

Attacker has interactive or scripted execution on the target Windows host
Chrome is installed on the host
Victim version is older than 149.0.7827.53

Where this breaks in practice:

EDR, ASR, WDAC, AppLocker, and standard anti-malware controls should already be fighting this stage
A local-user prerequisite means the organization is already in a post-compromise state

Detection/coverage: Strong detection at this step usually comes from endpoint telemetry, not vulnerability scanning. Version scanners can find vulnerable Chrome builds, but they cannot prove exploitability.

STEP 02

Reach the vulnerable ETW/Chromoting code path

The public description ties exploitation to a crafted ETW event, so the attacker needs to generate ETW activity that the vulnerable Chrome/Chromoting path will parse. Weaponization would likely use custom code or native Windows tracing APIs rather than commodity web exploit kits. Chromium documentation also shows Windows tracing is handled through a dedicated elevated tracing service, which implies a specialized and less common path.

Conditions required:

Windows host exposes the vulnerable Chrome tracing/Chromoting parsing path
Attacker can emit or influence ETW events locally
The affected feature path is present and reachable in the installed build

Where this breaks in practice:

This is not a generic browser-tab bug; it requires a Windows-local instrumentation path
Public exploit details are sparse, which raises implementation cost
Many enterprises will have vulnerable binaries installed but rarely exercise this path

Detection/coverage: There is little off-the-shelf scanner coverage for 'crafted ETW event against Chromoting parser.' Detection is mostly indirect: suspicious local ETW tooling, unusual tracing activity, or exploit crashes.

STEP 03

Trigger integer overflow and leak memory

If the malformed event reaches the vulnerable parser, the integer overflow can produce an out-of-bounds read or similar memory disclosure condition. The result is process-memory exposure, not arbitrary code execution. The attacker still has to recover useful bytes from the leak and convert them into something operationally valuable.

Conditions required:

Malformed event reliably reaches the vulnerable code path
Exploit can recover process memory in a usable way

Where this breaks in practice:

Information leaks are often noisy and unreliable compared with code-execution bugs
ASLR, process isolation, and general heap layout variability reduce repeatability
Leaked memory may contain nothing immediately useful

Detection/coverage: Crash telemetry, browser instability, or unusual tracing behavior may expose failed attempts. Commodity perimeter scanners will miss this entirely.

STEP 04

Convert leaked bytes into follow-on value

To matter, the attacker must turn leaked process memory into credentials, tokens, internal URLs, or exploit-development material for a second-stage attack. That is possible, but it is a secondary payoff after a successful local compromise. This keeps the blast radius materially below a remotely triggerable browser RCE.

Conditions required:

Leaked memory contains actionable secrets or exploit primitives
Attacker can exfiltrate or reuse the leaked data

Where this breaks in practice:

Modern browsers limit direct secret exposure compared with legacy monolithic processes
Many enterprise secrets are protected outside the browser process or require additional user context

Detection/coverage: Look for suspicious local collection/exfiltration behavior after browser or tracing anomalies. The CVE itself is less detectable than the attacker actions around it.

03 · Compensating Control

Prioritize endpoints already under incident response — If you have suspected or confirmed Windows endpoint compromise, move vulnerable Chrome builds on those systems to the front of your containment-and-recovery backlog. For a LOW noisgate verdict there is no formal mitigation SLA, but incident-impacted hosts should not wait for the normal browser ring.

Tighten local execution controls — Enforce or validate WDAC/AppLocker/ASR/EDR preventions that stop arbitrary user-mode tooling from gaining a foothold or abusing local tracing APIs. This matters more than the CVE itself because the attacker must already be local; for LOW, treat this as backlog hygiene unless an active compromise is in play.

Use version-based scoping — Pull a Chrome version inventory from your endpoint platform or Chrome Enterprise versions report and isolate Windows systems below 149.0.7827.53. For LOW, there is no separate mitigation clock; use this to feed the normal patch wave and exception tracking.

Restrict unnecessary Chrome Remote Desktop usage — Where Chromoting or Chrome Remote Desktop is not needed, remove it from sensitive admin workstations and jump hosts to reduce attack surface. This is an exposure-reduction measure, not an emergency control, so apply it through standard workstation hardening change windows.

What doesn't work

A WAF does nothing here because this is not a web-server bug and not remotely reachable over HTTP in the published attack model.
Perimeter scanners like Shodan/Censys-style exposure checks are mostly useless because the vulnerable surface lives on endpoints, not internet-facing services.
Network segmentation alone does not solve a bug that begins after the attacker already has local execution on the Windows device.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No evidence of active exploitation found in public sources reviewed, and not listed in CISA KEV.
KEV status	Not KEV-listed as of the current CISA catalog review; no federal due date applies.
Proof-of-concept availability	No public PoC located in reviewed sources. That is an inference from the absence of vendor-published exploit details, public exploit repos, and KEV/incident reporting—not proof that private weaponization does not exist.
EPSS	`0.00005` from the supplied intel, which is extremely low. Percentile was not available in the reviewed source set.
CVSS vector	`CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N` — this screams post-compromise local info leak: local vector, low privileges required, user interaction, confidentiality-only impact.
Affected versions	Google Chrome on Windows before `149.0.7827.53`.
Fixed version	Update to Chrome `149.0.7827.53` or later on Windows. Because this is a browser release, enterprises should also account for normal channel lag and managed rollout rings.
Exposure reality	This is not meaningfully internet-scannable like a server CVE. Exposure is driven by endpoint inventory and browser version distribution, which Google recommends tracking through Chrome Enterprise version reporting—not by Shodan/Censys counts.
Disclosure date	2026-06-05 per the supplied intel.
Reporting / root-cause context	Public root-cause detail is currently thin. Chromium documentation confirms Windows tracing components and ETW integration exist, but the precise fix commit and reporter identity were not publicly identified in the reviewed sources.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to LOW (2.8/10)

Why this verdict

Requires local foothold first — AV:L/PR:L/UI:R means the attacker is already on the box. That implies a prior compromise stage and sharply cuts the exposed population versus remotely triggerable Chrome bugs.
Confidentiality-only impact — the published impact is memory disclosure, not code execution or sandbox escape. Useful, yes, but usually as a follow-on primitive rather than the main event.
Likely narrow code-path reachability — exploitation depends on a crafted ETW event hitting a Chromoting-related path on Windows. Specialized local instrumentation paths see far less real-world abuse than generic webpage-driven browser surfaces.

Why not higher?

This is not a network-reachable browser RCE, not a renderer-to-sandbox-escape chain, and not a zero-click drive-by. The attacker needs local execution, some privileges, and a specialized ETW-trigger path before any data can leak. That combination is exactly why it should not sit in the same patch queue as remotely exploitable Chrome memory-corruption bugs.

Why not lower?

It is still a real memory disclosure bug in a widely deployed enterprise application, and post-compromise info leaks can materially help credential theft, token recovery, or exploit chaining. If you already have endpoint compromise, this kind of bug can make containment worse, so 'IGNORE' would be too dismissive.

06 · Verification

Crowdsourced verification payload.

Run this on the target Windows endpoint itself, or push it through SCCM, Intune, PDQ, Tanium, or your RMM. Invoke with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11281.ps1; standard user rights are usually enough because it only reads file and registry version data.

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

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

# Detect whether Google Chrome on Windows is older than 149.0.7827.53

# Output: VULNERABLE / PATCHED / UNKNOWN

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


$ErrorActionPreference = 'SilentlyContinue'

function Get-ChromeVersion {
    $candidates = @(
        'C:\Program Files\Google\Chrome\Application\chrome.exe',
        'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
        "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
    )

    foreach ($path in $candidates) {
        if (Test-Path $path) {
            try {
                $ver = (Get-Item $path).VersionInfo.ProductVersion
                if ($ver) { return $ver }
            } catch {}
        }
    }

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

    foreach ($reg in $regPaths) {
        try {
            $ver = (Get-ItemProperty -Path $reg -Name version).version
            if ($ver) { return $ver }
        } catch {}
    }

    return $null
}

if (-not $IsWindows) {
    Write-Output 'UNKNOWN: This check is intended for Windows only.'
    exit 2
}

$fixed = [version]'149.0.7827.53'
$rawVersion = Get-ChromeVersion

if (-not $rawVersion) {
    Write-Output 'UNKNOWN: Google Chrome not found or version unreadable.'
    exit 2
}

try {
    $installed = [version]$rawVersion
} catch {
    Write-Output "UNKNOWN: Unparseable Chrome version '$rawVersion'."
    exit 2
}

if ($installed -lt $fixed) {
    $chromotingSvc = Get-Service -Name 'chromoting' -ErrorAction SilentlyContinue
    if ($chromotingSvc) {
        Write-Output "VULNERABLE: Chrome $installed is older than $fixed. Chromoting service present: $($chromotingSvc.Status)."
    } else {
        Write-Output "VULNERABLE: Chrome $installed is older than $fixed. Chromoting service not detected."
    }
    exit 1
} else {
    $chromotingSvc = Get-Service -Name 'chromoting' -ErrorAction SilentlyContinue
    if ($chromotingSvc) {
        Write-Output "PATCHED: Chrome $installed is at or above $fixed. Chromoting service present: $($chromotingSvc.Status)."
    } else {
        Write-Output "PATCHED: Chrome $installed is at or above $fixed."
    }
    exit 0
}