← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11281 · CWE-472 · Disclosed 2026-06-05

Integer overflow in Chromoting in Google Chrome on Windows prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
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 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation found in public sources reviewed, and not listed in CISA KEV.
KEV statusNot KEV-listed as of the current CISA catalog review; no federal due date applies.
Proof-of-concept availabilityNo 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.
EPSS0.00005 from the supplied intel, which is extremely low. Percentile was not available in the reviewed source set.
CVSS vectorCVSS: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 versionsGoogle Chrome on Windows before 149.0.7827.53.
Fixed versionUpdate 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 realityThis 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 date2026-06-05 per the supplied intel.
Reporting / root-cause contextPublic 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.8/10)

The single biggest downgrading factor is that this bug requires local authenticated access on the endpoint before the attacker can even begin. That makes it a post-initial-access information leak with limited fleet-wide blast radius, not a scalable enterprise entry vector.

HIGH Affected platform/version boundary: Windows Chrome before `149.0.7827.53`
MEDIUM Operational exploitability is materially narrower than vendor CVSS suggests
LOW Exact reachability of the public Chromoting/ETW path across all real-world Windows Chrome deployments

Why this verdict

  • Requires local foothold firstAV: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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
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
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull a Windows Chrome version report, identify anything below 149.0.7827.53, and fold it into your next standard browser update wave. Because this is LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA beyond normal backlog hygiene; do not disrupt emergency patch capacity for this one. The exception is incident-scoped systems—if a workstation is already suspected compromised, patch that endpoint's Chrome build during containment rather than waiting for the routine ring.

Sources

  1. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  2. CVE Alert feed entry referencing CVE-2026-11281
  3. Chromium elevated tracing service README
  4. Microsoft Learn: Instrumenting Your Code with ETW
  5. FIRST EPSS program
  6. FIRST EPSS data statistics
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Google Chrome Enterprise: View Chrome version details
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.