← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11030 · CWE-416 · Disclosed 2026-06-04

Use after free in Network in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Treat this as a real browser bug, not an emergency fleet-wide fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled content

The attacker needs a user to browse to a malicious site, open hostile web content, or otherwise load attacker-controlled network responses in Chrome. There is no evidence in the reviewed sources of a turnkey public exploit kit for this CVE, so assume a custom landing page / custom exploit chain rather than commodity tooling.
Conditions required:
  • Unauthenticated remote attacker
  • Target uses Chrome below the fixed build
  • User visits or loads attacker-controlled content
Where this breaks in practice:
  • 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
Detection/coverage: External scanners do not reliably detect this; coverage is mostly indirect through browser version inventory, web filtering telemetry, and EDR/browser process crash signals.
STEP 02

Trigger the Network use-after-free

Attacker-controlled content exercises the vulnerable Network code path and attempts to dereference freed memory. At this stage most real-world attempts are just crashes; turning a UAF into controlled execution is materially harder than reproducing a fault.
Conditions required:
  • Specific vulnerable code path must still exist in the installed build
  • Payload must line up with allocator behavior on the target platform
Where this breaks in practice:
  • 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
Detection/coverage: You may see browser crash spikes or abnormal renderer/network-process termination, but signature-based vuln scanners generally cannot validate exploitability.
STEP 03

Convert corruption into code execution inside Chrome

If exploitation succeeds, the first win is typically code execution in a sandboxed browser context, not instant system ownership. Chrome's own security model assumes memory-safety bugs will happen and relies on sandboxing and site isolation to contain damage.
Conditions required:
  • Exploit developer can shape memory reliably
  • Target protections do not break the primitive
Where this breaks in practice:
  • Sandbox and site isolation are strong downward pressure on blast radius
  • A working exploit often needs per-platform tuning and significant offensive engineering
Detection/coverage: EDR can catch anomalous browser child process behavior, repeated crashes, unusual IPC abuse, or post-exploitation staging from the browser.
STEP 04

Chain to meaningful enterprise impact

To get beyond a browser compromise, the attacker usually needs a second vulnerability such as a sandbox escape, local privilege escalation, credential theft path, or high-value session theft. Without that second stage, the business impact is often limited to the browser session and whatever the sandboxed context can reach.
Conditions required:
  • Additional exploit or high-value browser session target
  • User has access to sensitive SaaS/apps worth stealing
Where this breaks in practice:
  • 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
Detection/coverage: Look for browser-to-OS pivot attempts, suspicious token theft behavior, abnormal downloads, and browser-originated child-process execution.
03 · Intelligence Metadata

The supporting signals.

Public record qualityCaveat: 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 statusNo active exploitation found in the reviewed sources, and not listed in CISA KEV.
PoC availabilityNo public PoC found in the reviewed sources. Expect custom exploit development, not copy-paste exploitation.
EPSS0.00035 from the supplied intel, which is very low and consistent with weak short-term exploitation pressure.
KEV statusNot KEV-listed as of the reviewed CISA catalog; no KEV add date.
CVSS interpretationCVSS: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 versionsSupplied 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 versionsUse 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 realityThis 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 provenanceThe 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.3/10)

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.

HIGH Exploit-chain friction assessment for a Chrome Network use-after-free with `UI:R`
LOW Exact public metadata mapping for `CVE-2026-11030` in official Google advisories

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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)
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like an emergency out-of-band patch event unless your own telemetry shows active exploitation. Inventory Chrome versions, let normal enterprise browser auto-update do the heavy lifting, and clean up laggards that remain below 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

  1. Google Chrome stable desktop release 149
  2. Google Chrome early stable desktop release 149.0.7827.53/.54
  3. Chromium security: memory safety
  4. Chromium security: site isolation
  5. CISA Known Exploited Vulnerabilities catalog
  6. FIRST EPSS overview
  7. VulDB listing for CVE-2026-11030 search results
  8. Chrome 149 release notes
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.