CVE-2026-11105 · Chrome WebUI Insufficient Input Validation Cross-Origin Data Leak

01 · The Real Story

This is a second-story window you can only reach after someone already broke down the front door

CVE-2026-11105 is an insufficient input validation flaw in Google Chrome's WebUI component affecting all versions prior to 149.0.7827.53 (stable channel, patched June 4, 2026). The bug allows a remote attacker to leak cross-origin data — potentially session tokens, email content, or sensitive web-app state — via a crafted HTML page. The catch: the attacker must have already compromised the renderer process before this vulnerability becomes reachable. That means a separate, typically more severe exploit (e.g., a V8 memory-corruption bug) must fire first to gain code execution inside Chrome's sandbox. Only then does CVE-2026-11105 provide incremental value as a cross-origin read primitive. CWE-20 (Improper Input Validation) and CWE-346 (Origin Validation Error) both apply.

Google's own Chromium severity rating of Medium at 6.5 is generous for the real-world threat this poses. The CVSS vector AV:N/AC:L/PR:N/UI:R implies low attack complexity and no privileges, but the description contradicts that — you need a pre-existing renderer compromise, which is itself a high-severity, high-complexity prerequisite. The vector should really carry AC:H at minimum. Furthermore, Chrome's aggressive auto-update mechanism means the remediation window is measured in hours to days for most managed fleets, not weeks. With no PoC, no KEV listing, an EPSS of 0.24%, and zero evidence of in-the-wild exploitation, the practical risk to an enterprise with standard Chrome update policies is negligible.

"Renderer-compromise prerequisite makes this a chain-only info leak; auto-update kills exposure window."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Renderer process compromise

The attacker must first exploit a separate vulnerability — typically a use-after-free, type confusion, or heap buffer overflow in V8 or Blink — to achieve code execution inside Chrome's sandboxed renderer process. This is a high bar: renderer exploits for current Chrome versions are rare, valued at $250K+ on the exploit market, and burned quickly. No public PoC chains CVE-2026-11105 with a renderer bug.

Conditions required:

Victim visits attacker-controlled or compromised page
Separate renderer RCE vulnerability (e.g., V8 bug) available and unpatched in victim's Chrome version

Where this breaks in practice:

Renderer exploits are scarce and expensive; Chrome's V8 sandbox, MiraclePtr, and CFI mitigations raise the cost
Chrome auto-updates mean the window for an unpatched renderer bug is typically <72 hours on managed endpoints
Most enterprise Chrome deployments are on current or N-1 versions

Detection/coverage: EDR agents with browser exploit telemetry (CrowdStrike Falcon, Microsoft Defender for Endpoint) detect anomalous renderer behavior. Chrome's own crash reporting flags renderer instability.

STEP 02

Victim navigates to crafted HTML page

With renderer compromise achieved, the attacker serves or injects a crafted HTML page that triggers the WebUI input validation bypass. The page must be loaded in the compromised renderer context. This requires the victim to navigate to the malicious content — either via phishing, malvertising, or a watering-hole site.

Conditions required:

User interaction: victim must click a link or visit a page
Attacker-controlled content served to the compromised renderer

Where this breaks in practice:

Enterprise email gateways and web proxies filter known malicious URLs
Browser-level Safe Browsing and enterprise URL filtering add another layer
User awareness training reduces click-through rates on phishing

Detection/coverage: Secure Web Gateway logs, DNS-layer filtering (Cisco Umbrella, Zscaler), Chrome Enterprise URL blocklists.

STEP 03

WebUI input validation bypass

The crafted page exploits the insufficient input validation in Chrome's WebUI layer. Because the renderer is already compromised, the attacker can manipulate IPC messages or DOM state to bypass origin checks that would normally prevent cross-origin reads. The WebUI trusts certain renderer-sourced data that it should not.

Conditions required:

Active renderer compromise from Step 1
Crafted HTML payload targeting CVE-2026-11105 specifically

Where this breaks in practice:

No public PoC or exploit code exists for this specific bypass
Chrome's Site Isolation (enabled by default since Chrome 67) limits the cross-origin surface reachable from any single renderer
The bug is in WebUI specifically — not all cross-origin data is accessible, only data the WebUI component handles

Detection/coverage: No specific scanner signature exists. Version-based detection only: chrome --version < 149.0.7827.53.

STEP 04

Cross-origin data exfiltration

The attacker reads cross-origin data that the WebUI component has access to — potentially including content from other origins loaded in the same browser profile. This could include session tokens, form data, or page content from sensitive web applications. The data is exfiltrated to attacker infrastructure over the existing network connection.

Conditions required:

Successful WebUI bypass from Step 3
Victim has sensitive cross-origin data loaded in the browser session
Network egress path to attacker C2

Where this breaks in practice:

Site Isolation limits which origins share a renderer process
Data Loss Prevention (DLP) at the network edge may flag unusual exfiltration patterns
The practical data accessible depends heavily on what the victim has open — not guaranteed to be high-value

Detection/coverage: Network DLP, CASB monitoring for anomalous data transfers from browser processes, endpoint telemetry showing unusual Chrome network patterns.

03 · Compensating Control

LOW 3.5→IGNORE 0.0

SEVERITY REDUCED

Verify Chrome auto-update is enforced fleet-wide — Confirm that Chrome's ComponentUpdatesEnabled and AutoUpdateCheckPeriodMinutes group policies are set to ensure automatic updates. For enterprises using Chrome Browser Cloud Management, verify the update policy is not set to 'Updates disabled'. This is the single most effective control — if auto-update is working, your fleet is already patched. As a LOW-severity finding, there is no noisgate mitigation SLA; treat this as backlog hygiene within your standard patching cycle.

LOW 3.5→LOW 2.0

Enforce Site Isolation and strict site-per-process — Ensure SitePerProcess is enabled (it's the default since Chrome 67, but can be disabled via enterprise policy). This limits the cross-origin surface available to a compromised renderer, reducing the data accessible via CVE-2026-11105 even if the chain fires.

LOW 3.5→LOW 1.5

Deploy browser-aware EDR with renderer exploit detection — EDR agents like CrowdStrike Falcon, Microsoft Defender for Endpoint, and SentinelOne detect anomalous renderer process behavior indicative of exploitation (shellcode execution, unusual IPC patterns). This addresses the *prerequisite* step (renderer compromise) rather than CVE-2026-11105 itself, breaking the chain at its most critical link.

LOW 3.5→LOW 2.5

Audit for unmanaged Chrome installations — Use your endpoint management platform (Intune, SCCM, Jamf) to identify Chrome installations not receiving managed updates. BYOD and shadow-IT endpoints are the most likely to remain unpatched. Remediate by enrolling them in Chrome Browser Cloud Management or blocking access via conditional access policies.

What doesn't work

WAF / Reverse proxy rules — This is a client-side browser vulnerability, not a server-side flaw. No WAF rule can prevent exploitation on the endpoint.
Network segmentation — The attack occurs entirely within the browser process on the endpoint. Network controls do not affect the renderer-to-WebUI IPC channel.
Disabling JavaScript — While this would block most renderer exploits (the prerequisite), it is not practical for enterprise web applications and would break critical business workflows.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None observed. Not listed in CISA KEV. No reports from Google TAG, Mandiant, or other threat intelligence sources indicate active exploitation. No GreyNoise or Shadowserver tags for this CVE.
Proof-of-Concept Availability	None found. No PoC on GitHub, ExploitDB, pocindex.io, or Nuclei templates. No researcher has published a working exploit. The Chromium bug tracker issue (500505339) is access-restricted, typical for Chrome security bugs.
EPSS Score	0.00243 (0.24%) — 15th percentile. This places CVE-2026-11105 well below the threshold where EPSS models predict meaningful exploitation probability within 30 days.
KEV Status	Not listed. No CISA Known Exploited Vulnerabilities catalog entry as of 2026-09-30.
CVSS Vector Analysis	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N` → 6.5. The vector's `AC:L` and `PR:N` are misleading: the description explicitly requires a prior renderer compromise, which implies high attack complexity and an implicit privilege prerequisite. A more accurate vector would use `AC:H`, dropping the score to ~5.3.
Affected Versions	All Google Chrome versions < 149.0.7827.53 across Windows, macOS, Linux, and ChromeOS. Chromium-based browsers (Edge, Brave, Opera, Vivaldi) on the same engine version are also affected until they pull the upstream fix.
Fixed Versions	Chrome 149.0.7827.53 (stable, June 4, 2026). Debian/Ubuntu: chromium-browser snap auto-updates; Ubuntu marks all supported releases as 'Not affected' since the snap tracks upstream. Microsoft Edge: check `edge://version` for Chromium base ≥ 149.0.7827.53.
Scanning & Exposure	Not applicable for internet-facing exposure scans (Shodan/Censys/FOFA) — this is a client-side browser vulnerability, not a server-side flaw. Endpoint vulnerability scanners (Qualys, Tenable, Rapid7) detect via version check of the Chrome binary.
Disclosure Date	June 4, 2026. Patched in the same stable channel release. Approximately 118 days since disclosure as of today.
Reporter / Attribution	Not publicly attributed. The Chromium issue tracker entry is restricted. Google's release notes for this batch did not credit a named external researcher, suggesting this may have been found internally or through the Chrome VRP with delayed attribution.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to LOW (3.5/10)

Why this verdict

Chaining prerequisite is the dominant friction: The attacker must first achieve renderer compromise via a *separate* vulnerability (typically a V8/Blink memory corruption bug). This is a high-cost, high-complexity step that itself requires an unpatched zero-day or N-day in the renderer. The CVSS vector's AC:L/PR:N fails to encode this prerequisite, inflating the score by ~1-2 points.
Auto-update eliminates the exposure window: Chrome's aggressive auto-update mechanism means >95% of managed enterprise endpoints will be on the patched version within 72 hours of release. As of today (118 days post-patch), any unpatched instance represents a configuration failure, not a patching gap. The population of exploitable targets is vanishingly small.
Confidentiality-only impact with Site Isolation limiting blast radius: Even if the full chain fires, the attacker gets a cross-origin *read* — not write, not code execution outside the sandbox. Chrome's Site Isolation (default since Chrome 67) further constrains which cross-origin data is accessible from any given renderer process, making the practical data harvest unpredictable and often low-value.
No PoC, no exploitation, rock-bottom EPSS: Zero public exploit code, zero in-the-wild sightings, EPSS at 0.24% (15th percentile). There is no evidence anyone has built or used a weaponized chain incorporating this CVE.
Role multiplier: Chrome is a universal endpoint application, not a canonically high-value-role component (it is not an IdP, DC, hypervisor, or network edge appliance). (a) *Workstation/dev sandbox:* standard role, chain succeeds only with renderer compromise, blast radius is host-level cross-origin data leak. (b) *Admin workstation accessing cloud consoles:* theoretically higher-value target, but the attacker who already has renderer compromise has more direct and reliable paths to session theft (e.g., reading localStorage, cookies via the renderer itself) — CVE-2026-11105 adds marginal incremental value. (c) No high-value-role override applies: Chrome itself is not domain-infrastructure software, and the confidentiality-only/host-scoped impact does not reach domain/fleet/supply-chain blast radius. The floor test is not triggered.

Why not higher?

Upgrading to MEDIUM would require either active exploitation evidence, a public PoC lowering the exploitation bar, or a scenario where this bug provides unique capability not already available to an attacker with renderer compromise. None of these conditions exist. The renderer compromise prerequisite means the attacker has *already* achieved something more severe than what this CVE delivers — making it a marginal amplifier, not a primary threat.

Why not lower?

IGNORE would be appropriate only if the vulnerability were entirely theoretical or affected zero production deployments. While Chrome auto-updates aggressively, a non-trivial tail of unmanaged or BYOD endpoints may lag, and the *theoretical* data leakage (session tokens, cross-origin content) is real if the chain fires. It warrants version-checking during routine scans, just not emergency action.

06 · Verification

Crowdsourced verification payload.

Run on any auditor workstation or as part of a fleet scan. Requires Python 3.6+. Invoke with: python check_cve_2026_11105.py [/path/to/chrome] — if no path is given, it searches common OS-specific default locations. No elevated privileges required; reads the Chrome binary version string only.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3
"""Check for CVE-2026-11105: Chrome WebUI input validation bypass.
Affects Google Chrome < 149.0.7827.53.
Outputs: VULNERABLE / PATCHED / UNKNOWN
"""
import subprocess
import sys
import os
import re
from pathlib import Path

FIXED_VERSION = (149, 0, 7827, 53)

def parse_version(version_str):
    parts = version_str.strip().split('.')
    if len(parts) != 4:
        return None
    try:
        return tuple(int(p) for p in parts)
    except ValueError:
        return None

def find_chrome():
    if len(sys.argv) > 1:
        p = Path(sys.argv[1])
        if p.exists():
            return str(p)
        print(f"UNKNOWN - provided path does not exist: {p}", file=sys.stderr)
        sys.exit(3)
    candidates = []
    if sys.platform == 'win32':
        for base in [os.environ.get('PROGRAMFILES', ''), os.environ.get('PROGRAMFILES(X86)', ''), os.environ.get('LOCALAPPDATA', '')]:
            if base:
                candidates.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
    elif sys.platform == 'darwin':
        candidates.append('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
    else:
        candidates.extend(['/usr/bin/google-chrome', '/usr/bin/google-chrome-stable', '/usr/bin/chromium-browser', '/usr/bin/chromium'])
    for c in candidates:
        if os.path.isfile(c):
            return c
    return None

def get_version(chrome_path):
    try:
        result = subprocess.run([chrome_path, '--version'], capture_output=True, text=True, timeout=10)
        match = re.search(r'(\d+\.\d+\.\d+\.\d+)', result.stdout)
        if match:
            return match.group(1)
    except Exception:
        pass
    return None

def main():
    chrome = find_chrome()
    if not chrome:
        print('UNKNOWN - Chrome binary not found. Provide path as argument.')
        sys.exit(3)
    ver_str = get_version(chrome)
    if not ver_str:
        print(f'UNKNOWN - Could not determine version from {chrome}')
        sys.exit(3)
    ver = parse_version(ver_str)
    if not ver:
        print(f'UNKNOWN - Could not parse version: {ver_str}')
        sys.exit(3)
    if ver < FIXED_VERSION:
        print(f'VULNERABLE - Chrome {ver_str} < {".".join(str(v) for v in FIXED_VERSION)} (CVE-2026-11105)')
        sys.exit(1)
    else:
        print(f'PATCHED - Chrome {ver_str} >= {".".join(str(v) for v in FIXED_VERSION)}')
        sys.exit(0)

if __name__ == '__main__':
    main()