This is a burglar already inside the house finding an unlocked interior door, not kicking in the front entrance
CVE-2026-11023 is a Chrome *same-origin policy bypass* in WebAppInstalls. Affected builds are Google Chrome versions prior to 149.0.7827.53; Google shipped the fix in Chrome 149 for Linux as 149.0.7827.53 and for Windows/macOS as 149.0.7827.53/.54. The important clause in the description is not WebAppInstalls—it is *"who had compromised the renderer process"*: the attacker must already have code execution or equivalent control inside Chrome's sandboxed renderer before this bug matters.
Google's *Medium* label matches reality better than the scary-sounding browser context might suggest. This is not a one-click workstation takeover, not a sandbox escape, and not a standalone internet-exploitable entry point; it is a chain-enabler that turns a renderer compromise into cross-origin data access. For enterprise prioritization, that is worth fixing, but it does not outrank true initial-access or sandbox-escape Chrome bugs.
4 steps from start to impact.
Land a renderer foothold first
- Target is running Chrome prior to 149.0.7827.53
- Victim visits attacker-controlled content
- Attacker already has renderer-process compromise through another flaw or chain
- This is *post-initial-browser-compromise*; most opportunistic actors do not have a renderer exploit to pair with it
- Modern browser exploit mitigations and site isolation raise the cost of landing step 1
- No public exploit chain was found for this CVE specifically
Drive the vulnerable WebAppInstalls path
WebAppInstalls behavior covered by issue 497538899. The bug is described as inappropriate implementation / insufficient input validation, which implies a logic or trust-boundary failure rather than memory corruption. That generally means the attacker must steer execution into a fairly specific code path instead of getting broad, reliable memory primitives.- Renderer is already compromised
- Attacker can script page behavior in the victim tab
- The vulnerable code path is reachable in the victim's browsing context
- Bug details remain restricted in the Chromium tracker
- Exploit reliability is narrower than classic memory-corruption bugs
- Enterprise browsing restrictions or disabled app-install surfaces may reduce reachable population
Break the origin boundary
- The victim has valuable authenticated web sessions or cross-origin data in the browser
- The targeted origin interaction is present and reachable from the compromised context
- Impact depends on what the user is signed into at the time
- HttpOnly cookies, origin-scoped APIs, and app-specific server-side checks can limit blast radius
- This does not itself escape the Chrome sandbox or execute native OS code
Monetize browser-resident access
- High-value browser sessions exist on the endpoint
- The chain stays stable long enough to access target data
- Blast radius is per-browser-profile, not per-host or per-domain-controller
- Session re-auth, MFA prompts, and server-side anti-abuse checks can interrupt abuse
The supporting signals.
| In-the-wild status | No evidence of active exploitation found in the reviewed sources, and not listed in CISA KEV as of 2026-06-05. |
|---|---|
| Public PoC status | No public proof-of-concept or exploit repo was found during review. The Chromium issue is still access-restricted, which usually suppresses copycat weaponization in the short term. |
| EPSS | 0.00021 from the user-supplied intel — extremely low, which fits a chained, second-stage browser bug rather than a broadly reusable entry bug. |
| KEV status | No. No CISA KEV listing date because it is not in the catalog. |
| Vendor severity / score | Google labels it Medium in the Chrome 149 release notes, but no vendor or authority CVSS score/vector is published. |
| CVSS view | No official vector exists. *Inference:* comparable Chrome cases involving renderer already compromised plus same-origin policy bypass have landed between roughly 3.1 and 6.5; this case looks closer to the lower-middle end because it is confidentiality-focused and explicitly chained. |
| Affected versions | Google Chrome desktop prior to 149.0.7827.53. Google shipped fixed Chrome 149 on 2026-06-02; Windows/macOS received 149.0.7827.53/.54, Linux received 149.0.7827.53. |
| Fixed versions | Patch level is Chrome 149.0.7827.53 or later. For managed fleets, validate the platform-specific stable build actually deployed, especially Windows/macOS 149.0.7827.54 channels and downstream Chromium-based browsers once they rebase. |
| Exposure reality | This is an endpoint browser flaw, not an internet-facing service. Shodan/Censys-style exposure counts are not a meaningful denominator; your true exposure is the number of enterprise endpoints still running pre-149 Chrome. |
| Disclosure / reporting | Published 2026-06-04. Google release notes show it was reported by Google on 2026-03-29 under Chromium issue 497538899. |
noisgate verdict.
The decisive downgrading factor is the prerequisite that the attacker must have already compromised Chrome's renderer process before this bug is reachable in a meaningful way. That makes CVE-2026-11023 a *chain extender*, not a front-door exploit, and sharply reduces the number of real-world attacks that can operationalize it at scale.
Why this verdict
- Major downward pressure: requires prior renderer compromise — attacker position is not just unauthenticated remote; it implies successful exploitation of a separate browser bug first, which is a compounding prerequisite that excludes most opportunistic threat activity.
- Impact is browser-bound, not host-bound — the stated outcome is *same-origin policy bypass*, which is serious for web sessions and data, but it is not native code execution, not a sandbox escape, and not direct OS compromise.
- Population is broad but not uniformly reachable — Chrome is everywhere, but the exploitable population is really the subset of endpoints still on old builds *and* exposed to a functioning first-stage renderer exploit *and* carrying valuable authenticated web state at the moment of exploitation.
- No active exploitation signal — no KEV listing, no public PoC found, and a tiny EPSS all point away from urgent internet-scale abuse.
- Google already classed it as Medium — with no official CVSS to compare against, the vendor's own severity label is a sensible baseline, and the real-world friction audit does not justify moving it upward.
Why not higher?
Because this is not a standalone one-click compromise. The attacker must already be inside the renderer, and the described impact is a browser trust-boundary bypass rather than sandbox escape or host takeover. No public exploitation evidence or KEV listing removes the main amplifier that would otherwise push a chained browser flaw into HIGH.
Why not lower?
Same-origin policy bypasses still matter in enterprise browsers because they can expose authenticated sessions and cross-origin data from high-value SaaS applications. Chrome's footprint is enormous, so even a second-stage bug can become operationally relevant when paired with another browser exploit or a private chain.
What to do — in priority order.
- Enforce browser auto-update health — Audit whether Chrome stable is actually advancing to
149.0.7827.53+across Windows, macOS, and Linux, and remediate broken update channels. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but for a browser fleet you should still validate update compliance this week because this control closes the issue without user action. - Reduce exposure to untrusted browsing — Keep risky browsing in hardened profiles, isolated VDI, or remote browser isolation where you already use them. This does not remove the bug, but it reduces the odds that a separate renderer exploit reaches a high-value browser session before the patch is broadly deployed; for MEDIUM, there is no mitigation SLA, so use it as risk reduction while normal patching completes.
- Tighten web app install policy — Review enterprise policies controlling app/PWA installation surfaces and disable unneeded install capabilities where business use does not require them. This narrows reachable code paths in
WebAppInstallsand is a practical containment move while remediation proceeds under the 365-day MEDIUM remediation window. - Hunt for chained browser exploitation — Look for browser exploit indicators rather than this CVE in isolation: renderer crashes, abnormal Chrome child-process trees, exploit prevention hits, and suspicious follow-on web-session abuse. The CVE is only useful after a first-stage browser foothold, so detection effort belongs on the chain.
- A WAF does not meaningfully protect endpoint Chrome clients from a renderer-compromise-plus-SOP-bypass chain; this is not a server-side web app bug in your environment.
- Perimeter internet scanning is not helpful because Chrome is client software, not a bannered external service.
- Basic version-only vulnerability scanning is necessary but insufficient; it tells you who is unpatched, not whether the attacker can satisfy the renderer-compromise prerequisite.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke it with python3 check_chrome_cve_2026_11023.py; no admin rights are required for normal detection, though Windows registry access may work more consistently in a standard user session with local profile access.
#!/usr/bin/env python3
# check_chrome_cve_2026_11023.py
# Detect Google Chrome version and assess exposure to CVE-2026-11023.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED = (149, 0, 7827, 53)
def parse_version(text):
if not text:
return None
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 run_cmd(cmd):
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 ''
def get_windows_version():
try:
import winreg
except Exception:
return None, 'winreg unavailable'
reg_paths = [
(winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
]
for hive, path in reg_paths:
try:
key = winreg.OpenKey(hive, path)
version, _ = winreg.QueryValueEx(key, 'version')
v = parse_version(version)
if v:
return v, f'registry:{path}'
except OSError:
pass
candidates = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
for exe in candidates:
if exe and os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
return v, exe
return None, 'Chrome not found'
def get_macos_version():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for exe in candidates:
if os.path.exists(exe):
out = run_cmd([exe, '--version'])
v = parse_version(out)
if v:
return v, exe
plist_candidates = [
'/Applications/Google Chrome.app/Contents/Info.plist',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/Info.plist'),
]
for plist in plist_candidates:
if os.path.exists(plist):
out = run_cmd(['/usr/bin/defaults', 'read', plist, 'KSVersion'])
v = parse_version(out)
if v:
return v, plist
return None, 'Chrome not found'
def get_linux_version():
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
['/opt/google/chrome/chrome', '--version'],
]
for cmd in cmds:
exe = cmd[0]
if os.path.isabs(exe) and not os.path.exists(exe):
continue
if not os.path.isabs(exe) and shutil.which(exe) is None:
continue
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v, ' '.join(cmd)
return None, 'Chrome not found'
def main():
system = platform.system().lower()
if 'windows' in system:
version, source = get_windows_version()
elif 'darwin' in system:
version, source = get_macos_version()
else:
version, source = get_linux_version()
if version is None:
print(f'UNKNOWN - Unable to determine Google Chrome version ({source})')
sys.exit(2)
if version < FIXED:
print(f'VULNERABLE - Google Chrome version {version_to_str(version)} detected via {source}; fixed is {version_to_str(FIXED)} or later')
sys.exit(1)
else:
print(f'PATCHED - Google Chrome version {version_to_str(version)} detected via {source}; fixed baseline is {version_to_str(FIXED)}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
<= 365 days.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.