This is a jailbreak tunnel hidden behind another locked door
CVE-2026-10918 is a use-after-free in Chrome's Viz/compositor stack. On affected builds prior to 149.0.7827.53—with Google showing 149.0.7827.53/.54 for Windows/macOS early stable and 149.0.7827.53 for Linux beta/branch alignment—a remote attacker could potentially turn a renderer compromise into a sandbox escape using crafted web content. That matters because Viz sits on the boundary between untrusted rendering and more privileged browser components.
Google's HIGH 8.3 score is technically fair for exploit-chain value, but it overstates standalone enterprise urgency. This bug does not give an unauthenticated internet attacker host compromise by itself; it assumes the attacker already landed code execution or equivalent control in the renderer. That prerequisite is major real-world friction, and with no KEV listing, no public exploitation signal, and a very low EPSS, this belongs below the top patch queue unless you're protecting high-risk browsing populations.
4 steps from start to impact.
Win the renderer first
- Target is running a vulnerable Chrome build prior to 149.0.7827.53
- Attacker can deliver malicious web content or another browser-stage exploit
- A separate renderer-compromise primitive exists and succeeds
- Requires a prior compromise stage before this CVE matters
- Modern browser mitigations, extension controls, and Safe Browsing reduce first-stage success
- User interaction is normally required to reach attacker content
Drive the compromised renderer into Viz
- Renderer code execution or equivalent control
- Reachable Viz code path from attacker-controlled page activity
- Correct browser build and heap state
- Exploit reliability is version-specific and heap-layout sensitive
- A crash is more likely than a clean escape during development or failed attempts
- Bug details are commonly restricted early in Chrome release cycles
Convert UAF into sandbox escape
- Successful reachability into the vulnerable Viz object lifecycle
- Exploit primitives survive memory-safety defenses sufficiently to gain control
- Target platform behavior matches the exploit assumptions
- Chrome's memory-hardening work in privileged processes materially raises failure rates
- Not every sandbox escape yields durable arbitrary code execution on the host
- A second-stage browser exploit is operationally rarer than single-bug web attacks
Turn browser escape into host objectives
- Successful sandbox escape
- Valuable data or reachable follow-on actions on the endpoint
- Defensive tooling does not block post-escape behavior
- EDR often catches browser-spawned payloads or suspicious memory behavior
- Least-privilege desktops limit blast radius
- Admin-separated browsing tiers reduce payoff on commodity endpoints
The supporting signals.
| In-the-wild status | No public exploitation signal found in primary-source review, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC located in primary-source web/GitHub checks. That's expected for a Chrome sandbox escape that also needs a separate renderer bug. |
| EPSS | 0.00068 from the provided intel, which is extremely low and consistent with a niche, chain-dependent exploit. |
| KEV status | Not KEV-listed as of the disclosure window around 2026-06-04. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the vendor model captures chain value, but it hides the most important operational fact: this assumes prior renderer compromise. |
| Affected versions | Google Chrome prior to 149.0.7827.53. Google release posts show 149.0.7827.53/.54 for Windows/macOS early stable and 149.0.7827.53 for Linux beta/branch alignment. |
| Fixed versions | 149.0.7827.53 or later for Linux-aligned builds, and 149.0.7827.53/.54 on Windows/macOS release channels called out by Google. |
| Scanning and exposure reality | Not internet-enumerable in the way server CVEs are. Shodan/Censys-style ASM is mostly irrelevant here; prioritize via endpoint/browser inventory and version telemetry. |
| Disclosure | 2026-06-04 per provided intel. Public bug details appear restricted, which is normal for Chrome until patch adoption improves. |
| Researcher / reporting | Unknown publicly from available primary sources. Chrome often withholds bug metadata temporarily during rollout. |
noisgate verdict.
The decisive downgrading factor is the attacker position requirement: this bug needs a renderer compromise first, which means it is not an initial-access web RCE by itself. That sharply narrows both the reachable population and the number of real attacks that can operationalize it, despite the serious technical impact if chained successfully.
Why this verdict
- Major prerequisite drag: exploitation requires the attacker to have already compromised the renderer process, which is a separate bug or foothold and turns this into a second-stage chain element.
- Exposure is universal but reachability is not: Chrome is everywhere, but only a small fraction of attacks can chain a renderer compromise into a reliable Viz sandbox escape.
- No exploitation pressure: no KEV listing, no public in-the-wild signal found, and the provided EPSS 0.00068 argue against emergency prioritization for the average enterprise fleet.
Why not higher?
This is not a clean one-click host takeover. The attacker needs user interaction plus a separate successful renderer compromise, and each prerequisite compounds downward pressure on real-world severity. For a 10,000-host patch queue, that makes it materially less urgent than pre-auth remote code execution or directly exploitable browser zero-days.
Why not lower?
A sandbox escape in Chrome still matters because browsers are high-value attack surfaces and this bug can be the difference between a contained renderer exploit and endpoint compromise. If paired with another browser bug, the blast radius can jump quickly, especially on high-risk users who browse untrusted content.
What to do — in priority order.
- Prioritize high-risk browser tiers — Move admins, executives, developers, researchers, and users who regularly browse untrusted sites onto the fixed Chrome build first. For a MEDIUM verdict there is no mitigation SLA, so treat this as targeted risk reduction while patching through normal remediation.
- Enforce browser auto-update and version visibility — Make sure Chrome update policies are not pinned behind stale rings and that endpoint telemetry reports exact browser versions. For MEDIUM, there is no mitigation SLA — go straight to standard remediation tracking, but you still want hard data on fleet coverage.
- Harden extension and browsing policy — Use Chrome enterprise policy to restrict unapproved extensions, isolate admin browsing, and reduce risky web content exposure where practical. This does not fix the bug, but it raises the cost of the first-stage renderer compromise this CVE depends on.
- Watch for browser-led post-exploitation — Tune EDR to alert on browser child processes, script interpreters launched from Chrome, suspicious file writes, and credential access following browser activity. With MEDIUM there is no mitigation SLA, but these detections are the best fallback if an exploit chain lands.
- A WAF does not protect endpoint browsers from a client-side memory corruption bug delivered through ordinary web content.
- Perimeter vulnerability scanners are poor coverage here because the vulnerable asset is the user's browser, not an internet-facing service banner.
- MFA is irrelevant to the exploit path; it may reduce downstream account abuse, but it does not stop renderer compromise or sandbox escape.
Crowdsourced verification payload.
Run this on the target endpoint or through your software management agent. Invoke it with python3 check_chrome_cve_2026_10918.py on macOS/Linux or py check_chrome_cve_2026_10918.py on Windows; no admin rights are required unless your EDR blocks process inspection. The script checks common Google Chrome install locations and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_10918.py
# 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, ...]]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_cmd(cmd: List[str]) -> Optional[str]:
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
if p.returncode == 0:
return (p.stdout or p.stderr).strip()
return (p.stdout or p.stderr).strip() or None
except Exception:
return None
def version_from_exe(path: str) -> Optional[Tuple[int, ...]]:
out = run_cmd([path, '--version'])
if out:
return parse_version(out)
return None
def windows_versions() -> List[Tuple[str, Tuple[int, ...]]]:
found = []
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):
v = version_from_exe(path)
if v:
found.append((path, v))
# Registry fallback via PowerShell if executable probing fails
if not found:
ps = shutil.which('powershell') or shutil.which('pwsh')
if ps:
script = r"""
$paths = @(
'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
)
foreach ($p in $paths) {
if (Test-Path $p) {
$v = (Get-ItemProperty -Path $p -ErrorAction SilentlyContinue).version
if ($v) { Write-Output $v }
}
}
"""
out = run_cmd([ps, '-NoProfile', '-Command', script])
if out:
for line in out.splitlines():
v = parse_version(line.strip())
if v:
found.append(('registry', v))
return found
def mac_versions() -> List[Tuple[str, Tuple[int, ...]]]:
found = []
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in candidates:
if os.path.exists(path):
v = version_from_exe(path)
if v:
found.append((path, v))
return found
def linux_versions() -> List[Tuple[str, Tuple[int, ...]]]:
found = []
binaries = [
'google-chrome',
'google-chrome-stable',
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
]
for b in binaries:
path = shutil.which(b) if not b.startswith('/') else b
if path and os.path.exists(path):
v = version_from_exe(path)
if v:
found.append((path, v))
return found
def compare(v: Tuple[int, ...], fixed: Tuple[int, ...]) -> int:
# returns -1 if v < fixed, 0 if equal, 1 if v > fixed
if v < fixed:
return -1
if v > fixed:
return 1
return 0
def main() -> int:
system = platform.system().lower()
installs: List[Tuple[str, Tuple[int, ...]]] = []
if 'windows' in system:
installs = windows_versions()
elif 'darwin' in system or 'mac' in system:
installs = mac_versions()
elif 'linux' in system:
installs = linux_versions()
else:
print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
return 2
if not installs:
print('UNKNOWN - Google Chrome not found in common install locations')
return 2
vulnerable = []
patched = []
for path, ver in installs:
if compare(ver, FIXED) < 0:
vulnerable.append((path, ver))
else:
patched.append((path, ver))
if vulnerable:
details = '; '.join(['{}={}'.format(p, '.'.join(map(str, v))) for p, v in vulnerable])
print('VULNERABLE - found Chrome build(s) older than 149.0.7827.53: {}'.format(details))
return 1
details = '; '.join(['{}={}'.format(p, '.'.join(map(str, v))) for p, v in patched])
print('PATCHED - all discovered Chrome build(s) are >= 149.0.7827.53: {}'.format(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 Releases - Chrome Beta for Desktop Update (149.0.7827.53)
- Chrome Releases - 2026 archive
- Google Security Blog - MiraclePtr: protecting users from use-after-free vulnerabilities on more platforms
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- FIRST EPSS overview
- Censys Internet Scanning documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.