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

Insufficient validation of untrusted input in Network in Google Chrome prior to 149

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

This is a broken bulkhead inside the ship, not a hole in the outer hull

CVE-2026-11016 is an input-validation flaw in Chrome's Network component that affects desktop builds before 149.0.7827.53. The published description is unusually important here: the attacker must have already compromised the renderer process, then use a crafted HTML page to bypass same-origin policy (SOP). That makes this a containment-failure bug inside an existing browser compromise chain, not a one-bug drive-by initial access issue.

Reality is slightly *lower-drama* than the raw words "remote attacker" suggest. The vendor's own label is Medium, and that matches the real-world risk: the impact can be meaningful because SOP bypass can expose cross-origin data from a live browser session, but the decisive friction is the prerequisite foothold in the renderer. For a 10,000-host estate, this is worth fixing as routine browser hygiene, not as a drop-everything emergency.

"Post-renderer-compromise SOP bypass: real in exploit chains, but not a fleet-wide patch fire"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a renderer foothold with a separate bug or malicious execution path

The published CNA description explicitly requires a compromised renderer process before CVE-2026-11016 matters. In practice that means the operator needs a prior-stage bug, a working exploit chain, or another execution path that already gives code running inside the renderer sandbox. Weaponized tool: a separate renderer exploit chain, not this CVE itself; reference: Chrome CNA/NVD description.
Conditions required:
  • Victim is running Chrome prior to 149.0.7827.53
  • Attacker can get the victim to load attacker-controlled web content
  • Attacker already has a renderer compromise by another means
Where this breaks in practice:
  • This CVE is unusable as initial access by itself
  • A reliable renderer exploit is a high-cost prerequisite modern Chrome hardening tries to prevent
  • Many opportunistic actors will never have step 1
Detection/coverage: Traditional vuln scanners will not validate this step. Detection lives in browser crash telemetry, exploit-prevention alerts, EDR child-process anomalies, and web exploit telemetry.
STEP 02

Serve crafted HTML that drives the bad Network validation path

Once code is already executing in the renderer context, the attacker delivers a crafted HTML page that exercises the vulnerable Network handling path. Weaponized tool: attacker-hosted HTML/JS content; reference: CNA says exploitation occurs via a crafted HTML page.
Conditions required:
  • Renderer code can navigate or interact with attacker-controlled page content
  • Victim session remains active long enough to complete the chain
Where this breaks in practice:
  • Bug details are still restricted, so public weaponization is not straightforward
  • Enterprise browsing isolation, kill-on-crash, or browser restarts can break timing-sensitive chains
Detection/coverage: No broad scanner signature. Useful signals are suspicious navigation sequences, unusual renderer instability, and browser security logs if centrally collected.
STEP 03

Bypass same-origin policy from the compromised renderer

The security boundary failure here is same-origin policy bypass, not native code execution. With the Network flaw triggered, the already-compromised renderer can access data that should have remained isolated across origins. Weaponized tool: in-browser fetch/XHR/navigation primitives after exploit chain completion; reference: CNA/NVD description.
Conditions required:
  • Target user has active authenticated browser state worth stealing
  • Relevant cross-origin targets are reachable from the browser session
Where this breaks in practice:
  • Blast radius is mostly bounded to the victim's browser session and accessible origins
  • Strong re-authentication, short-lived sessions, and partitioned storage reduce what is worth stealing
Detection/coverage: Behavioral coverage is better than signature coverage here: browser telemetry, proxy logs, CASB visibility, and identity-provider anomaly detection may show suspicious cross-origin access patterns.
STEP 04

Exfiltrate session data or abuse web actions

If the browser is logged into SaaS apps, the operator can potentially read sensitive data or drive unintended actions within web application trust boundaries. Weaponized tool: standard HTTPS exfiltration to attacker infrastructure from the browser session. This is why the bug still matters despite the heavy prerequisite chain.
Conditions required:
  • Victim has valuable live sessions or accessible data
  • Outbound HTTPS from the endpoint is not blocked
Where this breaks in practice:
  • Impact stays at browser-session scope unless chained again
  • DLP, IdP risk controls, and app-side step-up auth can blunt the payoff
Detection/coverage: Look for anomalous SaaS activity from a normal device, odd token reuse patterns, and post-compromise browser-originated traffic spikes; network scanners do not cover this.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo CISA KEV listing and no authoritative public evidence of active exploitation found in the consulted sources as of 2026-06-05.
Proof-of-concept availabilityNo public PoC was found in the consulted sources. The Chromium issue is still access-restricted, which usually slows copycat weaponization.
EPSS0.00021 in OpenCVE, shown as <1% / Very Low probability of exploitation signal.
KEV statusNot listed in CISA KEV; disclosure was 2026-06-04.
Vendor severityChrome CNA text says Chromium security severity: Medium; there is no vendor CVSS score yet.
Attack preconditionRequires a compromised renderer process first. That implies this is post-initial-access inside the browser, not a standalone remote compromise bug.
Impact summaryPublished impact is same-origin policy bypass via a crafted HTML page, which can expose cross-origin data available to the victim's live browser session.
Affected versionsAffected: Chrome < 149.0.7827.53. Desktop stable fix published as 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac).
Scanning / exposure realityThis is a client-side browser flaw with no meaningful internet-facing service fingerprint. Shodan/Censys/GreyNoise-style exposure data is largely not applicable; you need endpoint/browser inventory, not perimeter scanning.
Disclosure / reportingPublished 2026-06-04; release notes show it was reported by Google on 2026-03-28 under Chromium issue 497278395.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.6/10)

The single biggest downward driver is the prerequisite: the attacker must already own the renderer process before this bug becomes usable. That makes CVE-2026-11016 a chain amplifier with real confidentiality impact, but not a broad, first-hop enterprise takeover risk.

HIGH Affected version range and fixed build threshold
HIGH Attack-path prerequisite that renderer compromise is required
MEDIUM Overall severity bucket for enterprise prioritization
LOW Public exploit availability assessment while bug details remain restricted

Why this verdict

  • Major downward pressure — requires renderer compromise first: this is not unauthenticated remote initial access; it assumes the attacker has already beaten Chrome once.
  • Contained blast radius — browser-session scope: the published impact is SOP bypass and cross-origin data access, serious but narrower than native code execution or sandbox escape.
  • Low threat telemetry today — no KEV, very low EPSS: the consulted sources show no active-exploitation signal and an EPSS of 0.00021, which argues against emergency treatment.

Why not higher?

It is not higher because the exploit chain starts from a prerequisite most attackers will fail to satisfy: a prior renderer compromise. Also, the described consequence is a browser security-boundary bypass rather than direct OS compromise, remote code execution, or wormable network spread.

Why not lower?

It is not lower because once the prerequisite is met, bypassing same-origin policy can expose real enterprise data and authenticated SaaS sessions. On managed desktops with thousands of users, browser-session theft still has meaningful downstream business impact even when it is only a second-stage bug.

05 · Compensating Control

What to do — in priority order.

  1. Keep Chrome auto-update and restart enforcement healthy — For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers are cheap to update, so use policy to prevent version pinning and force restarts for stale channels where needed. This reduces dwell time on vulnerable builds without inventing an emergency change window.
  2. Preserve browser sandbox and site isolation defaults — Do not weaken Chrome security features with compatibility exceptions. These controls do not remove the bug, but they make the required renderer-compromise prerequisite harder to achieve and should remain enforced while you complete patching within the 365-day remediation window.
  3. Hunt for renderer-exploit precursors — Because this CVE is only useful after renderer compromise, focus monitoring on exploit-prevention hits, browser crashes, suspicious child-process creation, and unusual browser-originated identity activity. Treat this as an interim detective control while the fleet rolls to fixed versions within the 365-day remediation window.
  4. Reduce risky extension and unmanaged browsing paths — Restrict extension installation and route high-risk users through managed browser policy where possible. This does not directly patch CVE-2026-11016, but it lowers the chances of the attacker ever obtaining the prerequisite browser foothold before remediation is complete within 365 days.
What doesn't work
  • A WAF does not materially help; the vulnerable code runs in the client browser after content is rendered, and the crucial issue is the post-compromise SOP bypass path.
  • Perimeter vulnerability scanning does not help; there is no server-side service banner to probe for this client-side desktop version problem.
  • Generic network IPS signatures are weak here because the exploit details are restricted and the visible traffic can look like ordinary browsing to attacker-controlled content.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR execution channel. Invoke it with python3 check_chrome_cve_2026_11016.py (or py check_chrome_cve_2026_11016.py on Windows); it needs only standard user privileges and checks Google Chrome version locally, outputting VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11016.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import re
import sys
import shutil
import platform
import subprocess

THRESHOLD = (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(cmd):
    try:
        p = subprocess.run([cmd, '--version'], capture_output=True, text=True, timeout=5)
        output = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(output), output.strip()
    except Exception:
        return None, ''


def candidate_paths():
    system = platform.system()
    paths = []

    if system == 'Windows':
        envs = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LOCALAPPDATA'),
        ]
        suffixes = [
            os.path.join('Google', 'Chrome', 'Application', 'chrome.exe'),
        ]
        for base in envs:
            if base:
                for suffix in suffixes:
                    paths.append(os.path.join(base, suffix))
        if shutil.which('chrome'):
            paths.append(shutil.which('chrome'))
        if shutil.which('chrome.exe'):
            paths.append(shutil.which('chrome.exe'))

    elif system == 'Darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
        if shutil.which('google-chrome'):
            paths.append(shutil.which('google-chrome'))

    else:
        for name in ['google-chrome', 'google-chrome-stable']:
            resolved = shutil.which(name)
            if resolved:
                paths.append(resolved)

    # De-duplicate while preserving order
    seen = set()
    ordered = []
    for p in paths:
        if p and p not in seen:
            seen.add(p)
            ordered.append(p)
    return ordered


def main():
    checked = []
    for path in candidate_paths():
        if os.path.exists(path) or shutil.which(path):
            ver, raw = run_version(path)
            checked.append({'path': path, 'raw': raw, 'ver': ver})
            if ver is not None:
                status = 'PATCHED' if ver >= THRESHOLD else 'VULNERABLE'
                print(f'{status} - Google Chrome version {".".join(map(str, ver))} at {path}')
                sys.exit(0 if status == 'PATCHED' else 1)

    # If Chromium is present but not Google Chrome, report UNKNOWN because distro/backport logic differs.
    chromium_candidates = ['chromium', 'chromium-browser']
    for name in chromium_candidates:
        resolved = shutil.which(name)
        if resolved:
            ver, raw = run_version(resolved)
            if ver is not None:
                print(f'UNKNOWN - Found Chromium-family browser {".".join(map(str, ver))} at {resolved}; this check only asserts Google Chrome fixed at >= 149.0.7827.53 and cannot validate distro backports.')
                sys.exit(2)

    if checked:
        print('UNKNOWN - Chrome executable found but version could not be parsed.')
    else:
        print('UNKNOWN - Google Chrome not found on this host.')
    sys.exit(2)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, pull your browser inventory and identify endpoints still below 149.0.7827.53. For this MEDIUM assessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window, so you do not need an emergency compensating-control sprint; use auto-update telemetry, forced browser restarts for stale clients, and exception cleanup to get stragglers onto fixed builds. In practice, because Chrome patching is operationally cheap, you should verify healthy rollout on your next endpoint maintenance cycle, but your formal noisgate remediation SLA is ≤365 days.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue 497278395
  3. OpenCVE entry for CVE-2026-11016
  4. NVD entry for CVE-2026-11016
  5. Chromium Security page
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS
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.