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.
4 steps from start to impact.
Land code execution on the Windows endpoint
powershell.exe, commodity loaders, or an RMM implant. This CVE does not provide initial access by itself.- 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
- 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
Reach the vulnerable ETW/Chromoting code path
- 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
- 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
Trigger integer overflow and leak memory
- Malformed event reliably reaches the vulnerable code path
- Exploit can recover process memory in a usable way
- 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
Convert leaked bytes into follow-on value
- Leaked memory contains actionable secrets or exploit primitives
- Attacker can exfiltrate or reuse the leaked data
- 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
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. |
noisgate verdict.
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.
Why this verdict
- Requires local foothold first —
AV:L/PR:L/UI:Rmeans 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.
What to do — in priority order.
- 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.
- 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.
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.
# 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
}
If you remember one thing.
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
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- CVE Alert feed entry referencing CVE-2026-11281
- Chromium elevated tracing service README
- Microsoft Learn: Instrumenting Your Code with ETW
- FIRST EPSS program
- FIRST EPSS data statistics
- CISA Known Exploited Vulnerabilities Catalog
- Google Chrome Enterprise: View Chrome version details
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.