This is a burglar getting through the lobby door but still being trapped behind the vault glass
CVE-2026-11059 is a use-after-free in Blink, Chrome's rendering engine, affecting Google Chrome versions prior to 149.0.7827.53 on desktop platforms and corresponding builds before the 149 stable fix train. The practical exploit path is a crafted HTML page that triggers memory corruption in the renderer and gives the attacker arbitrary code execution inside the renderer sandbox, not unrestricted OS-level execution.
Google's HIGH 8.8 label is technically fair for a remote browser memory-corruption bug with no auth requirement, but it overstates enterprise blast radius if you read it like a server-side RCE. The two biggest brakes are user interaction and sandbox confinement: the attacker still has to get a target onto a malicious page, and a successful single-bug exploit lands in a restricted process unless paired with a second vulnerability or a high-value browser-granted permission state.
4 steps from start to impact.
Deliver the trigger page
- Target is running Chrome earlier than
149.0.7827.53 - Attacker can get the user to open attacker-controlled web content
- Browser policies do not fully block the relevant content path
- Requires UI:R: no page load, no exploit
- Enterprise web filtering, Safe Browsing, DNS filtering, and mail protections cut down delivery success
- Managed Chrome fleets often auto-update within days, shrinking the exposure window
Trigger Blink memory corruption
- Specific vulnerable Blink code path must be reachable from web content
- Exploit reliability must survive target-specific hardening and build differences
- Modern Chrome ships with allocator hardening, exploit mitigations, and aggressive fuzz-driven bug cleanup
- Many UAF bugs are crashable long before they are reliably weaponizable
- No official public exploit details were found in the reviewed primary sources as of 2026-06-05
Run code in the renderer sandbox
- Exploit must achieve stable control of instruction flow
- Sandbox remains intact but renderer capabilities are still valuable
- Chrome's security architecture is explicitly designed to confine renderer compromise
- Impact is narrower than a service-side RCE or sandbox-escape chain
- Data access is largely constrained to what the compromised renderer can already touch
Seek higher impact with a second bug or user context
- Attacker needs an additional escape or a high-value in-browser target
- Victim context contains useful session data or privileged app access
- A second exploit is a major reliability and availability constraint
- Many enterprise sessions are also protected by MFA, conditional access, or re-auth prompts
- Blast radius is usually one user/session at a time, not immediate fleet-wide compromise
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in the reviewed primary sources as of 2026-06-05; Chromium notes a separate restricted channel for bugs with evidence of exploitation, but this CVE was not flagged that way in the sources reviewed |
|---|---|
| KEV status | Not listed in CISA KEV based on the current KEV catalog |
| Proof-of-concept availability | No public PoC located in official sources reviewed; bug details are commonly withheld by Chrome until users are broadly updated, which materially limits immediate mass weaponization |
| EPSS | 0.0008 from the user-supplied intel; interpreted via FIRST EPSS as very low predicted 30-day exploitation probability. *Percentile was not provided in the prompt and was not directly retrievable from primary sources in this review* |
| Vendor severity / CVSS | HIGH 8.8 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — that is remote, low-complexity, no-privilege, user-interaction-required code execution with full CIA impact *inside the vulnerable security scope* |
| Affected versions | Chrome prior to 149.0.7827.53; the 149 stable release train covers Windows, macOS, and Linux desktop channels in the reviewed release material |
| Fixed versions | Fixed in 149.0.7827.53/.54 for Windows/macOS and 149.0.7827.53 for Linux per Google's release posts; Extended Stable users still receive security fixes on their channel cadence |
| Exposure reality | This is not internet-facing service exposure; Shodan/Censys-style counts are largely irrelevant. Real exposure is endpoint population size, and Chrome is commonly installed across enterprise fleets, which is the main amplifier here |
| Disclosure date | 2026-06-04 per the user-supplied intel |
| Research / reporting attribution | The reviewed release material did not expose public researcher attribution for this specific CVE at the time of review; Chrome frequently restricts detailed bug metadata until patch adoption improves |
noisgate verdict.
The deciding factor is population size: Chrome is everywhere, and an attacker can deliver this over the web without authentication. What keeps this out of CRITICAL is that the bug yields renderer-sandbox code execution, not a clean workstation takeover, and it still requires the victim to hit attacker-controlled content.
Why this verdict
- Baseline stays elevated because this is an unauthenticated, remotely deliverable browser memory-corruption bug in a massively deployed client application
- First downward adjustment: UI:R — the attacker needs a user to open malicious content, which implies delivery friction and puts modern email/web controls in the kill chain
- Second downward adjustment: sandboxed impact — successful code execution lands inside Chrome's renderer sandbox, so the single-bug outcome is materially narrower than a host-level RCE
- Third downward adjustment: no exploitation signal — not KEV-listed, no official in-the-wild reporting located, and the supplied EPSS is extremely low
- Residual upward pressure remains because nearly every managed endpoint may run Chrome, so even modest per-user exploitability can matter at fleet scale
Why not higher?
This is not a one-shot domain-wide disaster bug. The attacker needs user interaction, gets execution in a sandboxed renderer, and usually needs a second-stage escape or valuable in-browser session context to turn the bug into full host compromise. With no confirmed exploitation and a very low EPSS, there is not enough evidence to rate this CRITICAL.
Why not lower?
Calling this MEDIUM would underweight the fact that the initial attacker position is still unauthenticated remote over the web and the exposed population is huge. Browsers are high-churn attack surfaces, and a reliable renderer exploit can still steal session context, abuse SSO-backed web apps, or become dangerous when chained.
What to do — in priority order.
- Force browser auto-update — Ensure managed Chrome stays on the Stable or supported Extended Stable channel with automatic updates enabled, and verify rollout health through Chrome Enterprise reporting. For a HIGH verdict, deploy this control within 30 days to reduce the number of stale browsers waiting for user restart.
- Enforce relaunch compliance — Chrome patches do not take full effect until the browser restarts, so use enterprise policy, user prompts, or maintenance windows to drive relaunch on lagging endpoints. For a HIGH verdict, push this within 30 days or your fleet will look patched in inventory while vulnerable code is still in memory.
- Constrain risky browsing paths — Tighten URL filtering, malicious ad/category blocking, attachment detonation, and Safe Browsing posture for high-risk user groups such as finance, admins, and executives. This is the most realistic temporary brake on the UI:R delivery step and should be in place within 30 days.
- Prioritize unmanaged and exception devices — Hunt for devices off enterprise management, pinned to old versions, or stranded on incompatible channels, because these are where browser CVEs linger. Close those gaps within 30 days; the long tail, not the mainstream fleet, is where this issue will survive.
- Watch for renderer crash clusters — Correlate browser crash spikes, renderer instability, and unusual browser child-process behavior in EDR to catch exploitation attempts or low-quality PoCs. Stand this up within 30 days as a detection backstop, especially for user populations that routinely hit untrusted content.
- A network perimeter scanner does not help much here because this is a client-side browser bug, not an exposed listening service
- Relying on MFA alone does not stop initial exploitation; it may reduce the value of stolen sessions later, but it does not block the Blink trigger
- A generic WAF is irrelevant for most deployments because the exploit usually arrives from arbitrary websites, not your own protected web apps
- Marking the endpoint as 'patched' without forcing a browser restart is weak control; Chrome may have downloaded the update while the vulnerable process keeps running
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it with python3 check_chrome_cve_2026_11059.py on macOS/Linux or py check_chrome_cve_2026_11059.py on Windows; standard user rights are usually enough because it only reads executable version info from common install paths.
#!/usr/bin/env python3
# Check for CVE-2026-11059 exposure by local Chrome/Chromium version
# 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
FIXED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
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_str(v: Tuple[int, int, int, int]) -> str:
return '.'.join(str(x) for x in v)
def run_cmd(cmd: List[str]) -> Optional[str]:
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return None
def candidate_paths() -> List[str]:
system = platform.system().lower()
paths = []
if system == 'windows':
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',
r'Google\Chrome Beta\Application\chrome.exe',
]
for base in envs:
if not base:
continue
for suf in suffixes:
p = os.path.join(base, *suf.split('\\'))
if os.path.exists(p):
paths.append(p)
elif system == 'darwin':
mac_paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
paths.extend([p for p in mac_paths if os.path.exists(p)])
else:
bins = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome'
]
for b in bins:
p = shutil.which(b)
if p:
paths.append(p)
linux_paths = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
]
paths.extend([p for p in linux_paths if os.path.exists(p)])
# de-dup preserving order
seen = set()
uniq = []
for p in paths:
if p not in seen:
uniq.append(p)
seen.add(p)
return uniq
def get_version_from_binary(path: str) -> Optional[Tuple[int, int, int, int]]:
out = run_cmd([path, '--version'])
if out:
v = parse_version(out)
if v:
return v
# Fallback for Windows PowerShell file version query
if platform.system().lower() == 'windows':
ps = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item -LiteralPath '{path}').VersionInfo.ProductVersion"
]
out = run_cmd(ps)
if out:
v = parse_version(out)
if v:
return v
return None
def compare(v: Tuple[int, int, int, int], fixed: Tuple[int, int, int, int]) -> int:
return (v > fixed) - (v < fixed)
def main() -> int:
paths = candidate_paths()
if not paths:
print('UNKNOWN: Chrome/Chromium executable not found')
return 2
findings = []
for p in paths:
v = get_version_from_binary(p)
findings.append((p, v))
known = [(p, v) for p, v in findings if v is not None]
if not known:
print('UNKNOWN: Found browser binaries but could not determine version')
return 2
vulnerable = []
patched = []
for p, v in known:
if compare(v, FIXED) < 0:
vulnerable.append((p, v))
else:
patched.append((p, v))
if vulnerable:
details = '; '.join(f'{p}={version_str(v)}' for p, v in vulnerable)
print(f'VULNERABLE: fixed version is {version_str(FIXED)}; found {details}')
return 1
details = '; '.join(f'{p}={version_str(v)}' for p, v in patched)
print(f'PATCHED: fixed version is {version_str(FIXED)}; found {details}')
return 0
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
Sources
- Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome 149 release notes
- Chromium Security
- Chrome Enterprise - Manage Chrome updates
- Chrome Enterprise - View Chrome version details
- Chrome Enterprise - Release channels
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.