This is less a front-door break-in than a second lock failing after the burglar is already in the hallway
CVE-2026-11293 is a use-after-free in Chrome's Input component affecting desktop Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The bug class and published description point to a sandbox escape outcome from a malicious web page, which means the endgame is breaking out of Chrome's renderer isolation and reaching more privileged browser or host functionality.
The vendor's CRITICAL 9.6 score is too hot for enterprise patch triage because CVSS is scoring the *technical end state*, not the real-world attack chain. In practice, sandbox-escape bugs are usually second-stage browser exploit components: they matter a lot when paired with a renderer compromise, but by themselves they are not the same thing as a reliable single-bug drive-by RCE, and the current public signal shows no KEV listing, no public exploit, and extremely low EPSS.
4 steps from start to impact.
Lure the target into hostile web content
- Target uses vulnerable Chrome/Chromium build
- Target browses attacker-controlled or attacker-influenced content
- JavaScript or equivalent active content is allowed
- User interaction is required (
UI:R) - Enterprise filtering, browser reputation controls, and safe browsing routinely kill commodity delivery paths
- A meaningful fraction of managed Chrome fleets auto-update within days
Gain renderer-side control or a reliable browser primitive
- Attacker can drive complex browser state from the malicious page
- A renderer-side exploitation primitive exists or can be paired in-chain
- Exploit reliability is high enough across the target's OS/Chrome build
- This is the biggest downward pressure on severity: it likely assumes a prior compromise stage inside the browser
- Modern exploit mitigations, heap hardening, sandboxing, CFG/CET/PAC, and crash telemetry reduce reliability
- Public issue details remain embargoed/restricted
Trigger the Input use-after-free
- Precise heap grooming and object lifetime control
- Reachability of the vulnerable Input code path on the target platform
- Unpatched version prior to 149.0.7827.53/54
- Memory-corruption exploitation reliability varies sharply by OS, allocator state, and build flags
- Fleet diversity across Windows, macOS, Linux, and browser channels makes one-size-fits-all weaponization harder
- Chrome's own security team keeps bug details restricted until adoption improves
Escape the sandbox and act as the logged-on user
- Successful sandbox bypass
- Valuable user context or reachable post-exploitation objectives on the host
- No additional control blocks from EDR or application control
- Impact is generally bounded to the victim endpoint and user context unless followed by more post-exploitation
- EDR, browser isolation, and privilege management can still contain follow-on behavior
- This is not internet-scale perimeter exposure like an unauthenticated appliance RCE
The supporting signals.
| In-the-wild status | No public exploitation evidence found as of 2026-06-05; not KEV-listed. |
|---|---|
| Proof-of-concept availability | No public GitHub PoC or exploit repo located in current open-source search results; Chromium issue 502362260 remains restricted, which is normal for fresh browser memory-corruption bugs. |
| EPSS | 0.00068 (~0.068%) from the prompt intel — extremely low near-term exploitation probability relative to typical emergency patch drivers. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities catalog as checked after disclosure. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H captures severe *possible impact*, but it overstates single-bug operational risk because UI:R already narrows reach and a sandbox-escape outcome usually implies a multi-stage browser chain. |
| Affected versions | Desktop Chrome prior to 149.0.7827.53 (Linux) and prior to 149.0.7827.53/54 (Windows/Mac) per Google's release post and Canada's advisory. |
| Fixed versions | Google patched in 149.0.7827.53/54 for desktop; Android 149.0.7827.59 inherits the same security fixes as the desktop train. Distro rebuilds such as openSUSE Chromium 149.0.7827.53 also carry the fix set. |
| Scanning / exposure data | Shodan/Censys/FOFA/GreyNoise are basically non-signals here because this is a client-side browser flaw, not a remotely fingerprintable server service. Exposure has to be measured from endpoint version inventory, not internet census. |
| Disclosure timeline | Vendor patch train published 2026-06-02; Canadian advisory followed 2026-06-03; the prompt lists public disclosure as 2026-06-05. |
| Reporter / bug visibility | Public reporter attribution is not exposed in the available sources. The issue does not appear in Google's highlighted external-researcher reward list for the June 2 desktop stable post, which suggests a Google-found or non-highlighted fix — that part is an inference, not a confirmed attribution. |
noisgate verdict.
The decisive factor is that this looks like a sandbox-escape chain component, not a proven single-bug drive-by compromise. Without active exploitation, KEV pressure, or a public reliable exploit, the vendor's CRITICAL score is pricing in the *end state* while ignoring the most important real-world friction: the likely need for prior browser compromise or equivalent renderer control.
Why this verdict
- Post-renderer assumption cuts hard: the public description says *sandbox escape*, which in real browser ops usually means the attacker still needs renderer-side control first. That is a compounding prerequisite and a major downgrade from vendor CVSS.
- No exploitation pressure: there is no KEV listing, no public in-the-wild reporting, and the supplied EPSS of 0.00068 is extremely low. That is not the profile of a fleet-wide fire drill.
- Reachable product, limited enterprise blast radius: Chrome is everywhere, so population is broad, but successful exploitation lands on a user workstation in user context. This is not an unauthenticated perimeter service that turns one internet request into mass compromise.
Why not higher?
I am not scoring this HIGH or CRITICAL because the public evidence does not show a reliable one-bug drive-by chain, active exploitation, or a KEV-grade threat signal. If later reporting shows this is directly web-reachable without a separate renderer bug, or if exploit kits start using it, the score should move up fast.
Why not lower?
I am not dropping this to LOW because browser bugs on ubiquitous endpoints still matter, and a successful sandbox escape is a real boundary break with meaningful host impact. Also, endpoint version lag is common in large fleets, so a non-trivial vulnerable population can persist even when Chrome nominally auto-updates.
What to do — in priority order.
- Force Chrome auto-update and relaunch — Use enterprise policy to verify automatic update is enabled and relaunch prompts are enforced so patched builds actually replace stale processes. For a MEDIUM verdict there is no mitigation SLA under noisgate, so treat this as normal browser hygiene and fold it into your standard browser-management cycle rather than emergency change control.
- Hunt for version lag, not network exposure — Query endpoint management, EDR, or software inventory for Chrome/Chromium versions below 149.0.7827.53/54 and clean up unmanaged exceptions. There is no mitigation SLA for MEDIUM, but this is the highest-value control because browser client flaws are invisible to perimeter scanners.
- Keep browser exploit containment on — Preserve or expand browser isolation, EDR browser child-process protection, application control, and least-privilege user context to reduce damage if a renderer-to-host chain lands. Again, no mitigation SLA applies here; implement through your normal hardening program.
- A WAF will not help; this is a client-side browser flaw, not a server request parsing issue.
- Perimeter vulnerability scanners will not give useful coverage because there is no exposed network daemon to fingerprint; you need endpoint inventory.
- Relying on users to manually restart browsers does not work at 10,000-host scale; Chrome can stay running for days and keep the vulnerable process image loaded.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet execution tool. Invoke it with python3 check_cve_2026_11293.py on Windows, macOS, or Linux; no admin rights are required unless your endpoint controls block process execution. It auto-discovers common Chrome/Chromium binaries and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_cve_2026_11293.py
# Detect vulnerable Google Chrome / Chromium versions for CVE-2026-11293
# 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
THRESHOLD = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
m = VERSION_RE.search(text or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_version(cmd: List[str]) -> Optional[str]:
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return None
def existing_paths(candidates: List[str]) -> List[str]:
seen = []
for p in candidates:
if p and os.path.exists(p) and p not in seen:
seen.append(p)
return seen
def candidate_binaries() -> List[str]:
system = platform.system().lower()
cands = []
# PATH hits first
for name in [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser',
'chrome', 'msedge' # included only if org reuses script pattern; result is still versioned output
]:
p = shutil.which(name)
if p:
cands.append(p)
if system == 'windows':
for env in ['ProgramFiles', 'ProgramFiles(x86)', 'LocalAppData']:
base = os.environ.get(env)
if not base:
continue
cands.extend([
os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(base, 'Chromium', 'Application', 'chrome.exe')
])
elif system == 'darwin':
cands.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Chromium.app/Contents/MacOS/Chromium',
os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium')
])
else:
cands.extend([
'/usr/bin/google-chrome', '/usr/bin/google-chrome-stable',
'/usr/bin/chromium', '/usr/bin/chromium-browser',
'/snap/bin/chromium'
])
return existing_paths(cands)
def compare_versions(found: Tuple[int, int, int, int], threshold: Tuple[int, int, int, int]) -> int:
if found < threshold:
return -1
if found == threshold:
return 0
return 1
def main() -> int:
bins = candidate_binaries()
if not bins:
print('UNKNOWN: no Chrome/Chromium binary found')
return 2
results = []
for b in bins:
out = run_version([b, '--version'])
ver = parse_version(out or '')
if ver:
results.append((b, ver, out.strip()))
if not results:
print('UNKNOWN: Chrome/Chromium found but version could not be determined')
return 2
vulnerable = []
patched = []
for path, ver, raw in results:
cmpv = compare_versions(ver, THRESHOLD)
item = {'path': path, 'version': '.'.join(map(str, ver)), 'raw': raw}
if cmpv < 0:
vulnerable.append(item)
else:
patched.append(item)
if vulnerable:
print('VULNERABLE')
for item in vulnerable:
print(f"{item['path']} -> {item['version']}")
if patched:
print('INFO: patched binaries also present:')
for item in patched:
print(f"{item['path']} -> {item['version']}")
return 1
print('PATCHED')
for item in patched:
print(f"{item['path']} -> {item['version']}")
return 0
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
Sources
- Google Chrome Stable Channel Update for Desktop
- Canadian Centre for Cyber Security advisory AV26-544
- Chromium security project page
- Chromium issue 502362260
- openSUSE Chromium 149 patchinfo
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS program
- Tenable CVE entry aggregating public description and scoring
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.