Like peeking through a mail slot instead of kicking the door in
CVE-2026-11073 is a use-after-free bug in Chrome's WebGL path. On vulnerable desktop builds, a malicious page can trigger stale object reuse inside the renderer-side graphics stack and potentially leak process memory. Affected builds are Chrome versions before 149.0.7827.53 on Linux and before the fixed 149.0.7827.53/54 stable release on Windows/macOS; Windows/macOS Extended Stable also received a backport in 148.0.7778.254.
Google calling this *Medium* matches reality better than the usual panic around browser memory bugs. Yes, Chrome is everywhere and the bug is remotely triggerable through a webpage, but the chain still requires user interaction, the stated impact is confidentiality only, and modern Chrome defenses like sandboxing and Site Isolation materially reduce what a single renderer bug can steal without a second bug.
4 steps from start to impact.
Land the user on a crafted WebGL page
- Victim is using Chrome in an affected version range
- WebGL is available and not blocked by policy
- Attacker can get the victim to load a hostile page
- Requires user interaction, so this is not wormable and not a blind network spray
- Many enterprises already reduce risky browsing with URL filtering, Safe Browsing, or browser isolation
- High-value admins may browse from separate hardened workstations
Trigger the WebGL use-after-free in the renderer
- Exploit path matches the victim's platform/build
- Browser reaches the specific vulnerable WebGL state
- Mitigations do not make the bug non-reproducible
- Use-after-free exploitation is often brittle across builds, GPUs, drivers, and timing
- Google's bug details are still restricted, which usually means no turnkey exploit recipe is public yet
- Renderer crashes are more common than clean data exfiltration for immature browser exploits
Read process memory for useful secrets
- Exploit achieves memory disclosure rather than just a crash
- Target data is resident in the compromised process
- Attacker can return or exfiltrate the leaked bytes
- Site Isolation reduces cross-site data co-residency in many cases
- Chrome sandboxing and process boundaries constrain blast radius
- Secrets of real value may live outside the compromised renderer process
Monetize the leak or chain it with a second bug
- Leaked data has operational value
- Attacker can reuse tokens/cookies or pair this bug with another exploit
- No public evidence of active exploitation or a public chain as of June 5, 2026
- Session protections, re-auth prompts, and short-lived tokens reduce payoff
- Without a second bug, this stops well short of endpoint takeover
The supporting signals.
| In-the-wild status | No confirmed active exploitation located in public sources reviewed as of 2026-06-05. The CVE is not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC found in the reviewed sources. The vendor bug reference exists as Chromium issue 499365904, but details remain restricted, which usually slows opportunistic copycat use. |
| EPSS | 0.00032 from the user-supplied intel. That is extremely low; a verified percentile was not available from the primary sources reviewed. |
| KEV status | Not KEV-listed. No CISA due date applies because the CVE is absent from the catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — translation: remotely delivered through web content, but still needs a user to browse and is rated for confidentiality impact only. |
| Affected versions | Chrome before 149.0.7827.53 per the CVE description. Google's desktop rollout states fixed builds are 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. |
| Fixed versions / backports | Primary fix: Chrome 149 stable. Backport for slower channels: Windows/macOS Extended Stable 148.0.7778.254. |
| Scanning / exposure reality | This is a client-side browser bug, so edge-exposure telemetry is weak by design. GreyNoise and Censys are useful for internet-facing services, but they do not meaningfully enumerate endpoint browser build exposure for a WebGL renderer bug like this. |
| Disclosure timeline | There are two dates defenders should track: Google published the fixed stable desktop build on 2026-06-02, while downstream CVE metadata for this ID appears on 2026-06-04. |
| Reporter | Listed as reported by Google on 2026-04-03 in the Chrome stable-channel advisory. |
noisgate verdict.
The decisive factor is that this bug sits behind user-driven web navigation and yields information disclosure, not code execution. Chrome's process isolation also narrows what one renderer bug can reach, so the real-world blast radius is materially smaller than the ubiquity of the browser might suggest.
Why this verdict
- UI:R cuts the vendor 6.5 down immediately — the attacker needs a victim to render hostile content, which implies phishing, malvertising, or a compromised site rather than direct unauthenticated reachability.
- Confidentiality-only impact is a real ceiling — the published impact is memory disclosure, not arbitrary code execution, sandbox escape, or persistence on the host.
- Chrome's isolation model adds practical friction — Site Isolation and sandboxing reduce cross-site/process loot and make single-bug chains less rewarding than the raw CWE-416 label suggests.
Why not higher?
This is not an unauthenticated edge service and not a one-shot system compromise. There is no KEV listing, no public exploitation evidence in the reviewed sources, and no public PoC lowering the skill barrier for broad abuse.
Why not lower?
Chrome is everywhere, and drive-by delivery via a webpage is still a very real attack vector. Memory disclosure in a browser can expose session material or page data, and these bugs are frequently valuable as chain components even when the standalone CVSS looks modest.
What to do — in priority order.
- Enforce browser auto-update compliance — Use Chrome Enterprise policy, MDM, or your software deployment stack to verify that endpoints are actually receiving stable or Extended Stable updates. Because this verdict is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but for a browser you should treat version drift as an operational defect and close it in your next normal browser wave, not at day 364.
- Disable WebGL on tightly controlled high-risk tiers — For privileged admin workstations, kiosks, or VDI pools where WebGL is not business-critical, temporarily disable it with policy to shrink exposure while stragglers are updated. On a MEDIUM finding there is no mitigation SLA — go straight to the 365-day remediation window; use this only where the business impact is low and the population is easy to target.
- Separate privileged browsing — Keep administrator sessions, cloud consoles, and identity-provider admin work in dedicated browser profiles or hardened workstations so a renderer-only data leak has less valuable material to steal. With a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control pays off across the whole browser bug class.
- Monitor for browser crash clusters — Aggregate Chrome crash telemetry and EDR/browser logs to spot sudden spikes tied to specific URLs, referrers, or ad networks. There is no mitigation SLA — go straight to the 365-day remediation window for this finding, but early detection helps you catch opportunistic exploitation attempts before they become a broader incident.
- Perimeter WAF/IPS tuning doesn't solve this because the exploit lands as normal client web content over the victim's browser session, often inside HTTPS.
- External attack-surface scanning is mostly useless here because this is not an internet-facing server versioning problem; you need endpoint/browser inventory, not Censys or Shodan counts.
- MFA alone does not stop token or session-material theft if the bug can leak renderer-resident secrets after login.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR remote shell, not from an auditor workstation. Invoke it with python3 check_chrome_cve_2026_11073.py on Linux/macOS or py check_chrome_cve_2026_11073.py on Windows; standard user rights are usually enough, though some locked-down Windows hosts may require permission to read registry keys under HKLM.
#!/usr/bin/env python3
# check_chrome_cve_2026_11073.py
# Defensive version check for CVE-2026-11073 (Chrome WebGL UAF)
# 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 typing import List, Optional, Tuple
Version = Tuple[int, int, int, int]
def parse_version(text: str) -> Optional[Version]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_cmd(cmd: List[str]) -> str:
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
return (p.stdout or '') + (p.stderr or '')
except Exception:
return ''
def version_ge(a: Version, b: Version) -> bool:
return a >= b
def is_patched(ver: Version, system_name: str) -> bool:
# Stable fixed baseline for all desktop platforms
stable_fix = (149, 0, 7827, 53)
# Windows/macOS Extended Stable backport noted by Google
ext_fix = (148, 0, 7778, 254)
if system_name in ('Windows', 'Darwin'):
if ver[0] == 148 and ver[1] == 0 and ver[2] == 7778:
return version_ge(ver, ext_fix)
return version_ge(ver, stable_fix)
else:
# Linux advisory lists stable fix only
return version_ge(ver, stable_fix)
def detect_linux() -> List[Tuple[str, Version]]:
found = []
candidates = ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']
for c in candidates:
path = shutil.which(c)
if not path:
continue
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
found.append((path, ver))
return found
def detect_macos() -> List[Tuple[str, Version]]:
found = []
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary'
]
for path in candidates:
if not os.path.exists(path):
continue
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
found.append((path, ver))
return found
def detect_windows() -> List[Tuple[str, Version]]:
found = []
# Common executable paths
envs = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData')
]
suffixes = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe'
]
for base in envs:
if not base:
continue
for suf in suffixes:
path = os.path.join(base, *suf.split('\\'))
if os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
found.append((path, ver))
# Registry fallback: BLBeacon version key
reg_keys = [
r'HKLM\SOFTWARE\Google\Chrome\BLBeacon',
r'HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon'
]
for key in reg_keys:
out = run_cmd(['reg', 'query', key, '/v', 'version'])
ver = parse_version(out)
if ver:
found.append((key, ver))
# Deduplicate
uniq = {}
for src, ver in found:
uniq[src] = ver
return list(uniq.items())
def main() -> int:
system_name = platform.system()
detections: List[Tuple[str, Version]] = []
if system_name == 'Linux':
detections = detect_linux()
elif system_name == 'Darwin':
detections = detect_macos()
elif system_name == 'Windows':
detections = detect_windows()
else:
print(f'UNKNOWN: unsupported platform {system_name}')
return 2
if not detections:
print('UNKNOWN: Chrome/Chromium version not found')
return 2
vulnerable = []
patched = []
for src, ver in detections:
if is_patched(ver, system_name):
patched.append((src, ver))
else:
vulnerable.append((src, ver))
print('Detected versions:')
for src, ver in detections:
print(f' {src}: {".".join(map(str, ver))}')
if vulnerable:
print('VULNERABLE')
return 1
if patched:
print('PATCHED')
return 0
print('UNKNOWN')
return 2
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
149.0.7827.53 on Linux, 149.0.7827.53/54 on Windows/macOS, or 148.0.7778.254 for Windows/macOS Extended Stable. Because this lands MEDIUM and there is no KEV or public exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, roll it into your next normal browser maintenance wave and clean up stragglers well before the noisgate remediation SLA of ≤365 days.Sources
- Google Chrome Releases - Stable Channel Update for Desktop (2026-06-02)
- Google Chrome Releases - Extended Stable Updates for Desktop (2026-06-03)
- Chromium issue 499365904
- Chromium Security - Site Isolation
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS
- GreyNoise Event Feeds documentation
- Censys Search
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.