This is a booby-trapped lobby door, not a master key to the whole building
CVE-2026-11054 is a use-after-free in Chrome's WebRTC stack affecting Chrome before 149.0.7827.53; Google shipped fixes as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. The practical attack is classic browser exploitation: lure a user to attacker-controlled content, trigger the memory bug through WebRTC-capable page logic, and gain arbitrary code execution inside the renderer sandbox.
Google's HIGH 8.8 is technically defensible for exploitability, but it overstates enterprise urgency if you care about *real-world blast radius*. The decisive friction is that the advertised outcome is sandboxed code execution, not a host takeover; the attacker still needs a second bug, a policy weakness, or accessible in-browser data to turn this into major enterprise damage. With no KEV listing, no public exploit evidence, and very low EPSS, this is a broad patching item, not an emergency outage.
4 steps from start to impact.
Deliver a malicious page with custom HTML/JS + WebRTC trigger
- Victim is running Chrome below 149.0.7827.53
- Victim loads attacker-controlled or attacker-influenced web content
- WebRTC-relevant code path is reachable in that browsing session
- Requires user interaction (UI:R) rather than blind internet reachability
- Enterprise URL filtering, mail security, and browser isolation can reduce successful delivery
- Exploit reliability for modern browser memory corruption is usually non-trivial
Trigger the WebRTC use-after-free in the renderer
- Attacker has a working exploit primitive for this specific Chrome build family
- Target platform behavior matches exploit assumptions closely enough for reliability
- Browser exploit chains are fragile across patch levels, OS variants, and mitigation states
- No public PoC or exploit kit is currently visible, which usually means more attacker engineering time
Gain code execution inside the sandboxed renderer
- Renderer compromise succeeds
- Chrome sandbox is operating as intended
- The sandbox limits host impact and blocks this CVE from being a one-bug workstation takeover
- Site isolation and browser hardening reduce the amount of cross-site and host access available after compromise
Chain a second primitive for meaningful host compromise
- A second exploitable weakness or valuable browser-accessible target exists
- Defender controls such as EDR, application control, and OS exploit mitigations do not stop the follow-on stage
- Requires additional attacker capability beyond this CVE
- Modern endpoint controls are more likely to catch the post-renderer step than the initial trigger
The supporting signals.
| In-the-wild status | As of 2026-06-05, there is no public evidence of active exploitation and no CISA KEV listing for CVE-2026-11054. |
|---|---|
| Public PoC availability | No credible public GitHub/Exploit-DB PoC was found in current indexed sources. Expect private crash repros or internal testcases to exist, but nothing broadly weaponized is visible. |
| EPSS | 0.00071 (~0.071%) per the intel provided; that is *very low* and consistent with a fresh browser bug lacking public exploitation signals. |
| KEV status | Not listed in CISA KEV; that removes the strongest external urgency trigger. |
| CVSS vector readout | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote and low-complexity once the victim opens hostile content, but it still depends on user interaction and does not claim sandbox escape. |
| Affected versions | Chrome prior to 149.0.7827.53; Google and the Canadian Cyber Centre describe the fixed desktop train as 149.0.7827.53/54 (Windows/macOS) and 149.0.7827.53 (Linux). |
| Fixed versions | Treat 149.0.7827.53 or later as the minimum safe floor across fleet reporting, with Windows/macOS sometimes surfacing .54 in inventory. |
| Exposure / scanning reality | This is an endpoint browser issue, so Shodan/Censys/FOFA-style internet exposure counts are the wrong lens. The real exposure driver is Chrome's massive enterprise footprint, not public-service discoverability. |
| Disclosure date | 2026-06-04. |
| Researcher / reporting context | A specific external reporter is not publicly named in the sources reviewed for this CVE. More broadly, Chromium states that around 70% of its serious bugs are memory safety issues and about half of those are use-after-free bugs. |
noisgate verdict.
The single biggest severity reducer is impact confinement to the renderer sandbox. This is still a remotely reachable browser memory corruption bug, but without evidence of a paired sandbox escape or in-the-wild exploitation, the enterprise consequence is usually *potential foothold inside Chrome*, not *instant workstation loss*.
Why this verdict
- Sandbox-only outcome cuts the blast radius: the disclosed impact is code execution *inside Chrome's sandbox*, which is materially less severe than a one-bug endpoint takeover.
- User interaction is mandatory: the attacker needs the victim to browse hostile content, so this is drive-by capable but not wormable or service-exploitable.
- No KEV and near-floor EPSS reduce immediate operational risk: there is no public sign of broad weaponization yet, and the provided EPSS of 0.00071 is extremely low.
- Ubiquity keeps it from dropping lower: Chrome is everywhere, so even a sandboxed renderer RCE deserves disciplined fleet remediation.
Why not higher?
It is not higher because this CVE, as disclosed, stops at sandboxed execution. For a CRITICAL or even strong HIGH call, I would want active exploitation, KEV listing, or evidence that the bug reliably chains to sandbox escape or host compromise in common enterprise builds.
Why not lower?
It is not lower because browsers are a massively exposed client attack surface and a malicious page is a realistic delivery path. Remote, no-auth, low-complexity memory corruption in Chrome still matters at scale, even when the sandbox prevents us from calling it an emergency.
What to do — in priority order.
- Force browser auto-update compliance — Use GPO, MDM, or your endpoint management stack to enforce Chrome version drift limits and report any endpoint below 149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browser software should still ride your next managed update cycle rather than wait for annual cleanup.
- Prioritize high-risk user cohorts — Front-load patch verification for users who browse untrusted content all day: help desk, HR, recruiters, executives, finance, researchers, and developers. There is no mitigation SLA here, so focus on shrinking exposure through your normal rollout waves and complete remediation comfortably inside the 365-day window.
- Use browser isolation where already deployed — If you already run remote browser isolation, VDI, or hardened browsing containers for risky workflows, keep those users there until fleet version compliance is confirmed. This does not replace patching, but it lowers the value of a renderer compromise while you execute the normal MEDIUM-severity patch plan.
- Tune endpoint detection for browser breakout behavior — Hunt for suspicious child processes from
chrome.exe, abnormal browser memory protections, exploit-block events, and unusual credential or token access immediately after browser sessions. This is not a formal mitigation deadline item for MEDIUM, but it is the best backstop if someone privately weaponizes the bug before your rollout finishes.
- A WAF does not help; this is a client-side browser bug triggered by hostile page content after the user loads it.
- Perimeter internet scanning does not help; vulnerable Chrome versions live on endpoints, not on discoverable public services.
- Generic server patch cadence dashboards are misleading here; you need endpoint software inventory, not server vuln counts.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/remote execution tooling. Invoke it with python3 check_chrome_cve_2026_11054.py on macOS/Linux or py check_chrome_cve_2026_11054.py on Windows; no admin rights are normally required, but access to the installed Chrome binary or app bundle metadata is needed.
#!/usr/bin/env python3
# check_chrome_cve_2026_11054.py
# Purpose: Determine whether local Google Chrome version is vulnerable to CVE-2026-11054
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from pathlib import Path
MIN_SAFE = (149, 0, 7827, 53)
def parse_version(text):
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, capture_output=True, text=True, timeout=10)
if p.returncode == 0:
return (p.stdout or p.stderr).strip()
except Exception:
pass
return None
def get_windows_version():
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 path in candidates:
if path and os.path.exists(path):
out = run_cmd([
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path}').VersionInfo.ProductVersion"
])
if out:
v = parse_version(out)
if v:
return path, v
out = run_cmd([path, '--version'])
if out:
v = parse_version(out)
if v:
return path, v
return None, None
def get_macos_version():
app = '/Applications/Google Chrome.app'
plist = Path(app) / 'Contents' / 'Info.plist'
if plist.exists():
out = run_cmd(['/usr/bin/defaults', 'read', str(plist), 'CFBundleShortVersionString'])
if out:
v = parse_version(out)
if v:
return app, v
bin_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(bin_path):
out = run_cmd([bin_path, '--version'])
if out:
v = parse_version(out)
if v:
return bin_path, v
return None, None
def get_linux_version():
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in cmds:
out = run_cmd(cmd)
if out:
v = parse_version(out)
if v:
return ' '.join(cmd[:-1]), v
paths = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/snap/bin/chromium',
'/usr/bin/chromium-browser',
'/usr/bin/chromium',
]
for path in paths:
if os.path.exists(path):
out = run_cmd([path, '--version'])
if out:
v = parse_version(out)
if v:
return path, v
return None, None
def main():
system = platform.system().lower()
source = None
version = None
if 'windows' in system:
source, version = get_windows_version()
elif 'darwin' in system:
source, version = get_macos_version()
elif 'linux' in system:
source, version = get_linux_version()
else:
print('UNKNOWN - unsupported operating system')
sys.exit(2)
if not version:
print('UNKNOWN - Google Chrome version could not be determined')
sys.exit(2)
verdict = 'PATCHED' if version >= MIN_SAFE else 'VULNERABLE'
print(f'{verdict} - detected version {version_to_str(version)} from {source}; minimum safe version is {version_to_str(MIN_SAFE)}')
sys.exit(0 if verdict == 'PATCHED' else 1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases: Early Stable Update for Desktop
- Chromium source log for 149.0.7827.30..149.0.7827.53
- Chromium Security: Memory safety
- Chromium Security: Secure Architecture
- Canadian Centre for Cyber Security advisory AV26-544
- SecurityWeek: Chrome 149 Patches 429 Vulnerabilities
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API for CVE-2026-11054
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.