This is a leaky window in a moving car, not a smashed front door
CVE-2026-11090 is an *uninitialized use* bug in Chrome's ANGLE graphics layer, the component that translates browser graphics calls to platform GPU APIs. The affected range is Google Chrome versions *before* 149.0.7827.53; Google's June 2, 2026 stable release shipped 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. The stated impact is cross-origin data leakage from a crafted HTML page, not code execution.
Google's *Medium / 6.5* label is broadly fair, but a little generous for enterprise patch triage. The exploit chain needs a user to render attacker-controlled content in a vulnerable Chrome build, then successfully exercise the ANGLE path to leak useful data; that is meaningful for targeted theft, but it is not wormable, not a server-side foothold, and there is no current KEV listing, public exploit evidence, or scary EPSS signal pushing this into urgent territory.
4 steps from start to impact.
Land the user on attacker content
- Target uses Google Chrome below
149.0.7827.53 - User browses to attacker-controlled or attacker-influenced content
- Enterprise controls do not block the lure or destination
- This is *UI:R* by definition; no click, no bug
- Modern email/web filtering cuts down mass delivery
- Attackers still need a believable lure or compromised trusted site
Exercise the vulnerable ANGLE path
- ANGLE is in use on the target platform
- The vulnerable code path is reachable from the rendered content
- The host GPU/driver/browser combination behaves as expected for the bug
- Client-side graphics bugs are notoriously environment-sensitive
- Hardware acceleration settings, backend choice, and driver variation can break reliability
- Some enterprise VDI/kiosk builds materially differ from consumer desktops
Leak cross-origin or process data
- Useful victim data is present in browser memory or reachable rendering state
- Same-origin protections are bypassed by the bug's memory disclosure behavior
- The leaked bytes are stable enough to be parsed into something valuable
- Memory disclosure does not guarantee clean, high-value data every run
- Many leaks are noisy and require repeated attempts or careful grooming
- Blast radius is usually bounded to the browser session, not the whole host
Monetize the theft
- The leak yields something actionable
- Outbound network egress from the browser is allowed
- The victim is authenticated to something worth stealing
- Many enterprises rely on SSO, device binding, and conditional access that reduce token reuse value
- Useful data may be sparse unless the user is already logged into sensitive apps
- Exfil traffic can still stand out in proxy logs for targeted users
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found, and not listed in CISA KEV as of 2026-06-06. |
|---|---|
| Public PoC | No public proof-of-concept located. The Chromium issue exists at issues.chromium.org, but details are still effectively gated/restricted. |
| EPSS | User-supplied EPSS = 0.00035. That is a very low predicted exploitation probability; the percentile was not independently verified from FIRST during this assessment. |
| KEV status | Not KEV-listed. For prioritization, that removes the strongest urgency amplifier. |
| CVSS meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means remote delivery with user interaction required, confidentiality impact only, and no direct integrity or availability loss. |
| Affected versions | Google Chrome before 149.0.7827.53. Google's June 2, 2026 stable announcement shipped 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. |
| Fixed versions | Patch level is 149.0.7827.53 or later; Windows/macOS may report 149.0.7827.54 from the same stable rollout. |
| Exposure reality | Internet-wide scanner data like Shodan/Censys/FOFA is not applicable because this is a client-side browser bug, not a listening service. The population is still huge because Chrome held about 71.56% desktop browser share worldwide in StatCounter's April 2026 dataset. |
| Disclosure timeline | Chrome 149 stable shipped on 2026-06-02; the CVE record was disclosed on 2026-06-04. The Chrome release notes show the underlying bug was reported by Google on 2026-04-07. |
| Reporter / issue | The Chrome release notes attribute this bug to Google and map it to Chromium issue 500161302. |
noisgate verdict.
The decisive factor is compounding attacker friction: this is a client-side, user-driven data leak that must survive browser, GPU, and rendering-path variability before it returns anything useful. Chrome's ubiquity keeps it relevant, but the absence of KEV, public exploitation, or an integrity/availability impact keeps it out of the emergency lane.
Why this verdict
- User interaction drags the score down: the attacker needs a victim to render hostile web content, which implies phishing, malvertising, or a compromised trusted site rather than straight unauthenticated remote reach.
- This is client-side and non-scannable: there is no exposed service to sweep at internet scale, so population reach depends on successful content delivery and user browsing behavior, not raw network exposure.
- ANGLE/GPU path variability adds real friction: browser graphics bugs often depend on backend, driver, acceleration, and platform specifics, which hurts reliability in real enterprise fleets.
- No exploit pressure today: no KEV, no public in-the-wild reporting, no public PoC found, and the supplied EPSS is extremely low.
- Why it does not fall further: Chrome is everywhere, and a cross-origin data leak in a browser can still matter for SSO-heavy environments where users hold valuable live sessions.
Why not higher?
This is not code execution, not sandbox escape, and not a server-side exposure you can hit blindly from the internet. The chain requires user interaction and then a somewhat finicky client-side rendering condition to turn a bug into useful data theft, which is a meaningful downgrade from the vendor baseline.
Why not lower?
Cross-origin leakage inside the dominant enterprise browser is still a legitimate security issue, especially for high-value users with active SaaS sessions. Even without RCE, confidentiality loss in a browser can translate into real business impact if an attacker can steal tokens, page contents, or sensitive application data.
What to do — in priority order.
- Enforce browser auto-update — Make sure managed endpoints are actually receiving and applying Chrome stable updates, then verify they move to
149.0.7827.53+. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browsers should not sit that long in lagging channels. - Harden risky user cohorts — For admins, finance, executives, and researchers, apply stricter web isolation or remote browser isolation where available. This reduces the chance that a malicious page can exercise the vulnerable client path while you complete remediation within the 365-day window.
- Restrict untrusted browsing paths — Use secure web gateway policy to reduce exposure to newly registered domains, ad-tech noise, and uncategorized destinations. This does not fix the bug, but it reduces the odds of step 1 in the chain while you remediate.
- Watch browser laggards — Inventory endpoints still below
149.0.7827.53and tie them to owners, channels, and update failures. The real operational risk here is not exploit hype; it is unmanaged browser drift across thousands of hosts.
- A WAF does not help because the vulnerable component is the client's browser, not your server-side app stack.
- Perimeter port scanning does not help because there is no listening network service to enumerate for this CVE.
- Generic network segmentation does not neutralize a user browsing to hostile content on the open internet.
- Relying on AV signatures alone is weak here; there may be no dropped file or stable exploit artifact to match.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet management agent. Invoke it as python3 check_chrome_cve_2026_11090.py on Linux/macOS or py check_chrome_cve_2026_11090.py on Windows; no administrator rights are normally required because it only reads local executable paths and queries the browser version.
#!/usr/bin/env python3
# Check local Google Chrome version for CVE-2026-11090 exposure
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
PATCHED_MIN = (149, 0, 7827, 53)
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_to_str(v):
return '.'.join(str(x) for x in v)
def get_candidates():
system = platform.system().lower()
candidates = []
if system == 'windows':
env = os.environ
for base in [env.get('PROGRAMFILES'), env.get('PROGRAMFILES(X86)'), env.get('LOCALAPPDATA')]:
if not base:
continue
candidates.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
where = shutil.which('chrome') or shutil.which('chrome.exe')
if where:
candidates.append(where)
elif system == 'darwin':
candidates.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
])
where = shutil.which('google-chrome') or shutil.which('chrome')
if where:
candidates.append(where)
else:
candidates.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/snap/bin/chromium',
])
for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
where = shutil.which(name)
if where:
candidates.append(where)
# Deduplicate while preserving order
seen = set()
deduped = []
for c in candidates:
if c and c not in seen:
deduped.append(c)
seen.add(c)
return deduped
def get_version(binary):
try:
result = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=10)
output = (result.stdout or '') + ' ' + (result.stderr or '')
return parse_version(output)
except Exception:
return None
def main():
candidates = get_candidates()
found = []
for c in candidates:
if os.path.exists(c) or shutil.which(c):
v = get_version(c)
if v:
found.append((c, v))
if not found:
print('UNKNOWN - Google Chrome executable not found or version unreadable')
sys.exit(2)
# Use the highest discovered version in case multiple channels are installed
best_path, best_version = sorted(found, key=lambda x: x[1], reverse=True)[0]
if best_version >= PATCHED_MIN:
print(f'PATCHED - {best_path} version {version_to_str(best_version)} >= {version_to_str(PATCHED_MIN)}')
sys.exit(0)
else:
print(f'VULNERABLE - {best_path} version {version_to_str(best_version)} < {version_to_str(PATCHED_MIN)}')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, validate auto-update health, and push laggards through your normal endpoint update process; for a MEDIUM verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window, and noisgate remediation SLA: patch within 365 days. If you have high-risk user groups, tighten browsing controls and isolation sooner, but this CVE does not justify emergency change windows absent new exploitation evidence.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.