This is a cracked steering column in a company car that still needs the driver to take the wrong road
Per the supplied intel, this is a use-after-free in Chrome's Network component affecting Google Chrome versions prior to 149.0.7827.53 and disclosed on 2026-06-04. A successful exploit would start with attacker-controlled web content or network-delivered browser content, trigger stale object reuse in the networking path, and then turn a crash into controlled heap corruption. I could corroborate that Chrome 149 stable shipped on 2026-06-02 with multiple Network use-after-free fixes, but I could not corroborate this exact CVE ID in the official Google release note I reviewed, so the exploit-chain assessment here is based on the supplied record plus Chrome's confirmed June 2026 Network UAF patch pattern.
Google's HIGH 8.8 baseline makes sense in a vacuum for remote memory corruption, but it overstates enterprise urgency for patch scheduling. The biggest downward pressure is practical: this is client-side, requires user interaction, and Chrome's sandbox/site isolation usually means an attacker still needs a second bug for reliable host compromise. With no KEV listing, no public exploitation evidence in the reviewed sources, and an EPSS of 0.00035, this lands as MEDIUM for a 10,000-host program.
4 steps from start to impact.
Land the user on attacker-controlled content
- Unauthenticated remote attacker
- Target uses Chrome below the fixed build
- User visits or loads attacker-controlled content
- Requires a user action or at least user browsing behavior
- Email/web filtering, Safe Browsing, DNS filtering, and URL isolation cut the reachable population
- No public PoC located in reviewed sources
Trigger the Network use-after-free
- Specific vulnerable code path must still exist in the installed build
- Payload must line up with allocator behavior on the target platform
- Reliability varies by OS build, Chrome channel, mitigations, and heap state
- Modern exploit mitigations and compiler hardening raise the bar from crash to code execution
Convert corruption into code execution inside Chrome
- Exploit developer can shape memory reliably
- Target protections do not break the primitive
- Sandbox and site isolation are strong downward pressure on blast radius
- A working exploit often needs per-platform tuning and significant offensive engineering
Chain to meaningful enterprise impact
- Additional exploit or high-value browser session target
- User has access to sensitive SaaS/apps worth stealing
- Second-stage chaining is the decisive real-world hurdle
- MFA, conditional access, and hardened endpoints reduce value of stolen sessions and limit follow-on actions
149.0.7827.53+ and that users cannot indefinitely defer browser restarts. For a MEDIUM verdict there is no mitigation SLA; use this as routine hygiene while working inside the 365-day remediation window, not as an emergency exception process.- External perimeter vulnerability scans won't tell you much here, because they do not enumerate endpoint Chrome patch levels reliably.
- MFA by itself does not stop the initial browser-memory-corruption event; it only helps limit some follow-on account abuse.
- A WAF is mostly irrelevant for a client browser flaw unless you fully control every upstream web application the user visits, which you do not.
The supporting signals.
| Public record quality | Caveat: I could confirm Chrome 149's official stable release on 2026-06-02 and confirmed multiple Network UAF fixes in that train, but I could not corroborate the exact CVE-2026-11030 ID in the Google bulletin I reviewed. Assessment is therefore based on the supplied intel plus Chrome's confirmed June 2026 Network-UAF patch set. |
|---|---|
| In-the-wild status | No active exploitation found in the reviewed sources, and not listed in CISA KEV. |
| PoC availability | No public PoC found in the reviewed sources. Expect custom exploit development, not copy-paste exploitation. |
| EPSS | 0.00035 from the supplied intel, which is very low and consistent with weak short-term exploitation pressure. |
| KEV status | Not KEV-listed as of the reviewed CISA catalog; no KEV add date. |
| CVSS interpretation | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote, no auth, but user interaction required; high impact if exploited, but the UI:R prerequisite matters a lot in enterprise prioritization. |
| Affected versions | Supplied record says Google Chrome prior to 149.0.7827.53. Official Google release notes confirm 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS) as the June 2026 stable builds. |
| Fixed versions | Use 149.0.7827.53 or later as the safe floor for fleet validation, with platform nuance of 149.0.7827.53/54 on Windows/macOS in Google's stable rollout. |
| Exposure reality | This is a client-side browser flaw. Shodan/Censys/FOFA-style exposure counts are not meaningful for estimating enterprise risk because the vulnerable population lives on endpoints, not internet-facing servers. |
| Reporting / research provenance | The supplied CVE record does not identify a researcher. In the official Chrome 149 bulletin, comparable Network UAFs were reported by c6eed09fc8b174b0f3eebedcceb1e792 on 2026-02-25 and 2026-04-17. |
Sources.
Why this verdict
- User interaction required: The vendor vector already says
UI:R; that means no drive-by internet worm here. In a 10,000-host estate, this shifts the attacker from 'scan and hit' to 'lure and convert,' which is real downward pressure from the 8.8 baseline. - Sandboxed client-side context: Chrome explicitly uses sandboxing and site isolation as containment for memory-safety bugs. That means the first successful step is usually browser-context execution, not immediate OS-level impact, so I pull the score down another notch.
- No exploitation signal: No KEV, no public exploitation evidence in reviewed sources, and an EPSS of 0.00035 all argue against emergency handling. If this were showing up in active chains, this score would jump fast.
- Still broad endpoint reach: I am not dropping this to LOW because Chrome is ubiquitous and the attacker position is still just 'remote plus user click/browse.' Broad population and attractive browser-session targets keep this materially relevant.
Why not higher?
This is not a server-side pre-auth RCE on an externally exposed service, and there is no confirmed active exploitation signal in the reviewed sources. The exploit chain also has a built-in brake: user interaction first, reliable code execution second, sandbox bypass often third.
Why not lower?
Memory-corruption bugs in browsers are never pure paperwork, especially in a product deployed to nearly every user. A remote attacker with only a lure still gets a path to browser compromise, and that is enough to keep this above backlog-hygiene territory.
Crowdsourced verification payload.
Run this on the target endpoint or push it through your EDR/RMM as a local check. Invoke it as python3 check_chrome_149.py on macOS/Linux or py check_chrome_149.py on Windows; no admin rights are required unless your environment blocks process execution from unprivileged users.
#!/usr/bin/env python3
# check_chrome_149.py
# Determine whether local Google Chrome is at or above 149.0.7827.53
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
MIN_VERSION = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text):
m = VERSION_RE.search(text or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_version_command(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return parse_version(out)
except Exception:
return None
def windows_candidates():
candidates = []
for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
if not base:
continue
candidates.append(Path(base) / 'Google' / 'Chrome' / 'Application' / 'chrome.exe')
which = shutil.which('chrome.exe')
if which:
candidates.append(Path(which))
return candidates
def mac_candidates():
return [
Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
Path.home() / 'Applications' / 'Google Chrome.app' / 'Contents' / 'MacOS' / 'Google Chrome',
]
def linux_candidates():
bins = []
for name in ['google-chrome', 'google-chrome-stable', 'chrome']:
which = shutil.which(name)
if which:
bins.append(Path(which))
bins.extend([
Path('/usr/bin/google-chrome'),
Path('/usr/bin/google-chrome-stable'),
Path('/opt/google/chrome/chrome'),
])
return bins
def find_installed_version():
system = platform.system().lower()
candidates = []
if system == 'windows':
candidates = windows_candidates()
elif system == 'darwin':
candidates = mac_candidates()
else:
candidates = linux_candidates()
checked = set()
for path in candidates:
try:
path = path.resolve()
except Exception:
pass
key = str(path)
if key in checked:
continue
checked.add(key)
if path.exists():
v = run_version_command([str(path), '--version'])
if v:
return v, str(path)
# Fallback: try generic commands
for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chrome.exe']:
which = shutil.which(name)
if which:
v = run_version_command([which, '--version'])
if v:
return v, which
return None, None
def compare_versions(found, minimum):
if found is None:
return None
if found < minimum:
return -1
return 0
def fmt(v):
return '.'.join(str(x) for x in v)
if __name__ == '__main__':
found, path = find_installed_version()
if found is None:
print('UNKNOWN - Google Chrome not found or version could not be parsed')
sys.exit(2)
cmp_result = compare_versions(found, MIN_VERSION)
if cmp_result == -1:
print(f'VULNERABLE - Found Chrome {fmt(found)} at {path}; requires >= {fmt(MIN_VERSION)}')
sys.exit(1)
else:
print(f'PATCHED - Found Chrome {fmt(found)} at {path}; meets >= {fmt(MIN_VERSION)}')
sys.exit(0)