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
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. |
noisgate verdict.
The single biggest reason this drops to MEDIUM is that it is a user-driven client-side browser bug rather than an unauthenticated server-side foothold. Even if the memory corruption is real, Chrome's sandbox and site-isolation architecture usually mean an attacker still needs additional offensive work to turn this into durable host compromise at scale.
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.
What to do — in priority order.
- Enforce Chrome auto-update compliance — Make sure managed endpoints actually converge on
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. - Isolate high-risk browsing — Apply remote browser isolation, hardened web filtering, or stricter browsing policy to users who regularly open untrusted links or external content. There is no mitigation SLA for MEDIUM here; use this where exposure is highest while standard patching catches up within the remediation window.
- Tighten browser extension and download controls — Restrict unmanaged extensions and watch for browser-originated child-process execution or suspicious download chains, because meaningful impact usually comes from post-browser pivoting rather than the initial crash itself. Again, no mitigation SLA for this bucket; treat it as compensating hardening while you remediate in the normal window.
- 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.
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)
If you remember one thing.
149.0.7827.53; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, and the noisgate remediation SLA is ≤ 365 days. In practice, because this is a browser, most teams should finish well before that using the next standard browser-update cycle rather than a crisis change window.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.