This is a burglar getting into the building lobby, not the master key room
CVE-2026-11136 is a use-after-free in Chrome Canvas that affects Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. A malicious site can trigger memory corruption through crafted HTML/JavaScript and potentially achieve arbitrary code execution inside the Chrome sandboxed renderer, which matters because Chrome is ubiquitous and user browsing is the delivery path.
The raw 8.8 CVSS overstates enterprise urgency for patch scheduling. The decisive reality is that the advertised impact is inside the sandbox, not a full workstation takeover, and exploitation still needs user interaction plus a browser memory-corruption exploit that survives modern mitigations; with no KEV listing, no public PoC, and very low EPSS, this is a patch-worthy browser flaw but not a drop-everything incident.
4 steps from start to impact.
Land the user on attacker-controlled content
- Attacker can host or inject a crafted web page
- Victim uses vulnerable Chrome build
- Victim reaches the page and renders it
- Requires user interaction; this is not a wormable network service bug
- Enterprise web filtering, Safe Browsing, URL rewriting, and email security reduce delivery success
- Chrome auto-update shrinks the vulnerable population quickly in managed fleets
Shape renderer heap with JavaScript
- Renderer can execute attacker JavaScript
- Bug is reachable in the victim's platform/build combination
- Exploit chain achieves stable heap layout
- Modern Chrome exploit mitigations make renderer memory corruption harder to weaponize reliably
- Cross-version reliability is poor; attackers usually tune for exact builds
- Crashes are more common than clean code execution for fresh browser bugs
Gain code execution in the sandboxed renderer
- Successful weaponization of the use-after-free
- Exploit reliability sufficient for target architecture
- Sandbox remains the current security boundary
- Impact is constrained by the sandbox
- Without a second vulnerability, the attacker does not get full host compromise from this CVE alone
- Many campaigns prefer easier browser bugs with immediate sandbox escape or data theft primitives
Attempt post-sandbox objectives
- Useful data or reachable APIs exist from renderer context
- Attacker has an additional exploit or abuse path
- Defenses do not stop browser-to-host pivoting
- This step often requires another bug or separate weakness
- MFA, EDR, application control, and OS hardening reduce blast radius
- Enterprise compromise value varies heavily by what the user has active in-browser
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the sources reviewed; no CISA KEV listing as of 2026-06-05 |
|---|---|
| PoC availability | No public PoC or GitHub exploit repo located during review; Chromium bug remains access-restricted |
| EPSS | User-supplied EPSS is 0.0008; that is very low and aligns with a newly disclosed, not-yet-weaponized client-side browser bug |
| EPSS percentile | Not verified from a primary EPSS record during this review; treat the score as directional, not the percentile |
| KEV status | Not listed in CISA KEV; no federal due date pressure |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the important real-world bit is UI:R plus the vendor description limiting impact to inside the sandbox |
| Affected versions | Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS |
| Fixed versions | Patch to 149.0.7827.53 on Linux or 149.0.7827.53/54 on Windows/macOS; Chrome Early Stable shipped 2026-05-29, Stable channel announcement followed 2026-06-02 |
| Exposure/scanning reality | This is not Internet-exposed in the Shodan/Censys sense; exposure is your endpoint/browser estate, not a server listening on a port. Asset truth comes from software inventory, browser management, and EDR version telemetry. |
| Disclosure and researchers | Disclosed 2026-06-04 in NVD/CVE ingestion; Chrome release notes credit Jungwoo Lee (@physicube) and Wongi Lee (@_qwerty_po), reported on 2026-04-11 |
noisgate verdict.
The biggest downward pressure is that the stated impact is code execution inside the Chrome sandbox, not a workstation-level compromise from one bug. Add user interaction, no KEV, no public weaponization, and a very low EPSS, and this lands as a broad-but-constrained browser patch rather than a top-of-queue emergency.
Why this verdict
- Sandbox containment cuts the blast radius: the vendor description says arbitrary code execution is *inside a sandbox*, which is materially less severe than a one-shot host compromise.
- User interaction is mandatory:
UI:Rmeans the attacker needs the victim to render hostile content, so this is not a wormable or scan-and-smash flaw. - No field evidence is pushing urgency up: no KEV listing, no public PoC found, and a user-supplied EPSS of 0.0008 all point away from immediate operational exploitation.
- Browser bugs are common; reliable chains are not: getting from a use-after-free to stable renderer RCE across enterprise builds takes exploit engineering, and many attempts will just crash Chrome.
- Exposure is wide but shallow: Chrome is everywhere, so patch coverage matters, but the reachable population is 'users who browse' rather than 'an Internet-facing service anyone can hit anonymously at scale.'
Why not higher?
If this were paired with a sandbox escape, publicly exploited, or trivially reliable, the score would climb fast. As published, the chain stops at renderer compromise, and that missing second-stage pivot is the main reason this does not stay HIGH.
Why not lower?
This is still a real memory-corruption bug in an extremely common application. A malicious page is a plausible delivery vehicle in any large enterprise, so dismissing it as LOW or IGNORE would understate the ubiquity and potential user-level business impact.
What to do — in priority order.
- Force browser auto-update compliance — Verify your management stack is actually enforcing Chrome auto-update and relaunch behavior, because that is the cleanest way to collapse exposure. For a MEDIUM verdict there is no noisgate mitigation SLA, so use this as immediate hygiene while you work inside the 365-day remediation window.
- Block risky delivery paths — Harden email-link detonation, web filtering, Safe Browsing enforcement, and category-based blocks for newly registered or low-reputation domains to cut initial page loads. There is no mitigation SLA for MEDIUM, so deploy where easy and high-value rather than treating this as emergency change work.
- Reduce unmanaged Chrome use — Find hosts running unmanaged, stale, or user-installed Chrome outside enterprise policy and either enroll them or remove them, since these machines persist long after the managed fleet updates. With a MEDIUM verdict, do this as exposure reduction while proceeding directly toward remediation.
- Watch for browser crash spikes — Use EDR, crash telemetry, or browser management reporting to spot clusters of Chrome renderer crashes on vulnerable builds, which can be your earliest signal of exploit development or active targeting. For MEDIUM there is no formal mitigation deadline, but this is low-cost monitoring to keep in place until patch saturation is complete.
- A network perimeter IPS signature is not a dependable answer here, because the trigger is hostile browser content over normal web traffic and exploit specifics are likely obfuscated or encrypted.
- MFA does not stop exploitation of the browser bug itself; it only helps if the attacker later pivots into account abuse.
- Server-side Internet exposure scanning will not tell you who is at risk, because Chrome is an endpoint application, not an externally listening service.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet tooling on Windows, macOS, or Linux. Invoke it with python3 check_cve_2026_11136.py or python3 check_cve_2026_11136.py --path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; no admin rights are required unless your EDR blocks process inspection.
#!/usr/bin/env python3
# check_cve_2026_11136.py
# Purpose: determine whether installed Google Chrome is vulnerable to CVE-2026-11136
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
PATCH_LINUX = (149, 0, 7827, 53)
PATCH_WIN_MAC = (149, 0, 7827, 53) # advisory says Windows/Mac 149.0.7827.53/54; 53 is fixed baseline
CANDIDATES = {
'Windows': [
r'C:\Program Files\Google\Chrome\Application\chrome.exe',
r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
],
'Darwin': [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
],
'Linux': [
shutil.which('google-chrome'),
shutil.which('google-chrome-stable'),
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
],
}
def norm_version_tuple(v):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', v)
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_version(path):
try:
cp = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
text = (cp.stdout or '') + ' ' + (cp.stderr or '')
return text.strip()
except Exception:
return None
def discover_paths(user_path=None):
if user_path:
return [user_path]
sysname = platform.system()
vals = CANDIDATES.get(sysname, [])
return [p for p in vals if p and os.path.exists(p)]
def compare_versions(installed, fixed):
# returns -1 if installed < fixed, 0 if equal, 1 if installed > fixed
if installed < fixed:
return -1
if installed > fixed:
return 1
return 0
def main():
user_path = None
if len(sys.argv) == 3 and sys.argv[1] == '--path':
user_path = sys.argv[2]
elif len(sys.argv) not in (1, 3):
print('UNKNOWN: usage: python3 check_cve_2026_11136.py [--path /full/path/to/chrome]')
sys.exit(2)
sysname = platform.system()
paths = discover_paths(user_path)
if not paths:
print('UNKNOWN: Google Chrome executable not found')
sys.exit(2)
fixed = PATCH_LINUX if sysname == 'Linux' else PATCH_WIN_MAC
for path in paths:
ver_out = run_version(path)
if not ver_out:
continue
ver = norm_version_tuple(ver_out)
if not ver:
continue
cmp_res = compare_versions(ver, fixed)
version_str = '.'.join(str(x) for x in ver)
fixed_str = '.'.join(str(x) for x in fixed)
if cmp_res < 0:
print(f'VULNERABLE: {path} version {version_str} is older than fixed baseline {fixed_str}')
sys.exit(1)
else:
print(f'PATCHED: {path} version {version_str} meets or exceeds fixed baseline {fixed_str}')
sys.exit(0)
print('UNKNOWN: Chrome found but version could not be determined')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.