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

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

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

This is the deadbolt behind a door the attacker already had to kick in

CVE-2026-11008 is a cross-origin data leak flaw in Chrome's WebAppInstalls component. Affected desktop builds are Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS, with the public description stating that a remote attacker who had already compromised the renderer process could leak cross-origin data via a crafted HTML page.

Reality is less urgent than the product ubiquity suggests. This is not an initial-access browser RCE by itself; it is a post-renderer-compromise boundary bypass / data exposure primitive. That prerequisite is the whole story: if the attacker must first land a separate renderer exploit, this CVE becomes a chain component, not a standalone enterprise fire.

"ASSESSED AT MEDIUM: real bug, but it only matters after the attacker already popped the renderer."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code in the renderer first

The attacker needs a separate vulnerability or exploit chain to gain control of Chrome's renderer process. CVE-2026-11008 does not provide that foothold; it only becomes useful once renderer code execution or equivalent compromise already exists.
Conditions required:
  • Victim browses attacker-controlled content
  • A separate renderer-compromise bug exists and is exploitable
  • The victim is on a vulnerable Chrome build
Where this breaks in practice:
  • This CVE is not the initial exploit
  • Modern Chrome sandboxing and exploit mitigations raise the bar for renderer compromise
  • Exploit chains that start in the renderer are expensive and usually reserved for higher-value targets
Detection/coverage: Version scanners can flag vulnerable Chrome versions, but they cannot prove exploitability of the renderer prerequisite. Browser crash telemetry, sandbox violation logs, and EDR detections around exploit staging are the useful signals.
STEP 02

Trigger the WebAppInstalls validation flaw

With a compromised renderer, the attacker drives crafted HTML into the WebAppInstalls code path and abuses insufficient validation of untrusted input. The value here is breaking a browser trust boundary rather than getting native code execution.
Conditions required:
  • Renderer process is already compromised
  • Reachable WebAppInstalls code path from attacker-controlled content
Where this breaks in practice:
  • Requires the right browser state and reachable feature path
  • Bug details remain restricted, which usually means reliable weaponization is non-trivial
Detection/coverage: No dependable network signature. Detection is mostly indirect: browser version inventory, exploit-chain telemetry, and anomaly hunting around cross-origin access attempts.
STEP 03

Bypass origin boundaries and read data

The published impact is cross-origin data leakage. In practical terms, the attacker is trying to turn a renderer foothold on one site into access to data that should stay isolated to another origin or privileged browser context.
Conditions required:
  • Sensitive target data is present in browser context
  • Browser isolation controls do not fully block the specific leak path
Where this breaks in practice:
  • Chrome Site Isolation reduces what a compromised renderer can see
  • Impact is confidentiality-focused, not full host takeover
  • The attacker still needs valuable target data to be resident and reachable
Detection/coverage: Hard to detect directly. Site isolation and browser hardening reduce blast radius; endpoint telemetry may only show the upstream renderer exploit.
STEP 04

Exfiltrate the stolen data

Any data obtained must still be sent out through attacker-controlled network channels or reused in-session. That is operationally simpler than the exploit work, but it is the final step that turns a boundary bypass into actual business impact.
Conditions required:
  • Recovered data is valuable enough to operationalize
  • Outbound exfiltration path is available
Where this breaks in practice:
  • Least-privilege browsing profiles, short-lived sessions, and conditional access reduce value
  • Network controls and browser isolation can limit follow-on usefulness
Detection/coverage: Proxy logs, CASB, DLP, and EDR may catch suspicious outbound traffic or token reuse, but there is no CVE-specific signature.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the sources reviewed; Chrome's security advisory does not flag it as exploited, and CISA KEV does not list it.
Public PoC availabilityNo public PoC found. Google notes bug details may remain restricted until most users are patched, which usually suppresses early weaponized writeups.
EPSS0.00043. That is a *very* low modeled exploitation probability; VulDB shows the same score, and FIRST documents EPSS as a daily exploitation-likelihood estimate.
EPSS percentileNot directly available from the source set for this exact CVE. By comparison to recent FIRST API examples, the score sits in the low tail, consistent with opportunistic exploitation being unlikely.
KEV statusNot KEV-listed as of 2026-06-05. This is an inference from the current CISA KEV catalog and search-filter views.
Affected versionsChrome desktop prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS.
Fixed versionsUpdate to 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. Downstream Chromium-based browsers will need their own vendor rebuild cadence.
Attack precondition that mattersRequires prior renderer compromise. That implies this is post-initial-access inside the browser sandbox, not a click-and-own bug by itself.
Exposure / scanning realityThis is a client-side browser vulnerability, so Shodan/Censys-style internet exposure counts are mostly irrelevant. Your exposure is your managed endpoint fleet running vulnerable Chrome, not a public listening service.
Disclosure / reporterChrome stable update published 2026-06-02; the CVE was disclosed 2026-06-04/05 depending on feed timing. The advisory credits the report to Google on 2026-03-24.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.7/10)

The decisive limiter is the renderer-compromise prerequisite. Once a CVE only matters after the attacker already has code execution in a Chrome renderer, it stops being a frontline patch emergency and becomes a chain-hardening issue in a massively deployed product.

HIGH Affected version range and fix train
HIGH Post-renderer-compromise prerequisite
MEDIUM Practical blast radius of the cross-origin leak
MEDIUM Overall severity assessment without an authoritative CVSS baseline

Why this verdict

  • Downshift for attacker position: exploitation requires a remote attacker who had already compromised the renderer process. That is a separate exploit stage, so this CVE is not an entry bug.
  • Downshift for exposure reality: Chrome is everywhere, but this specific weakness is not internet-reachable as a service and is only actionable inside a successful browser exploit chain.
  • Downshift for defender controls: Chrome sandboxing and Site Isolation are designed to reduce exactly this class of cross-origin fallout from compromised renderers.
  • Upward pressure from ubiquity: if an actor already has a Chrome renderer exploit, adding a browser-boundary bypass in such a widely deployed target still has operational value at scale.
  • Upward pressure from impact type: the stated impact is cross-origin data leakage, which can expose session-bound or sensitive web data even without host-level compromise.

Why not higher?

There is no sign of KEV listing, no public exploitation evidence in the reviewed sources, and no public PoC. More importantly, the attacker must first clear the hardest step with a different bug: renderer compromise. That is major real-world friction and should materially suppress patch priority versus standalone browser RCEs.

Why not lower?

This is still a real browser security-boundary failure in a ubiquitous enterprise application. If paired with a renderer exploit, it can turn one compromised web context into cross-origin data access, which is meaningful even without native code execution or sandbox escape.

05 · Compensating Control

What to do — in priority order.

  1. Enforce rapid browser auto-update — Keep Chrome and Chromium-derived browsers on centralized update policy with version compliance reporting. For a MEDIUM noisgate verdict there is no mitigation SLA; use this as standard hygiene and complete actual patch rollout within the 365-day remediation window.
  2. Reduce high-risk browsing exposure — Apply hardened browsing profiles for admin users, privileged access workstations, and sensitive web apps so a renderer exploit chain has less useful data to steal. There is no mitigation SLA here; treat it as baseline hardening while patching inside the 365-day remediation window.
  3. Maintain exploit-prevention telemetry — Keep EDR, browser crash collection, and proxy/DLP monitoring tuned for exploit staging and unusual outbound exfiltration. This will not fix the bug, but it is the control most likely to catch the upstream renderer exploit this CVE depends on.
  4. Inventory Chromium forks separately — Track Chrome, Edge, Brave, Electron-embedded browsers, VDI golden images, and kiosk systems as distinct patch objects. This avoids the common failure mode where Chrome is patched but downstream Chromium consumers lag for months.
What doesn't work
  • A WAF does not help; this is a client-side browser flaw, not a server-side HTTP parser issue.
  • Perimeter network scanning does not meaningfully measure exposure; browsers are endpoints, not internet-facing services.
  • Relying on MFA alone misses the point; if cross-origin session data is exposed inside the browser, MFA has already been bypassed by possession of the in-session context.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or in your software-inventory job on each workstation/server image. Invoke it as python3 check_cve_2026_11008.py on macOS/Linux or py check_cve_2026_11008.py on Windows; no admin rights are usually needed, but registry access on Windows and app bundle access on macOS must be permitted.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11008.py
# Detects whether locally installed Google Chrome appears vulnerable to CVE-2026-11008.
# Output: 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

TARGET = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def get_version_from_command(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=5)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(out.strip())
    except Exception:
        return None


def windows_candidates():
    paths = []
    for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
        if not base:
            continue
        paths.append(Path(base) / 'Google' / 'Chrome' / 'Application' / 'chrome.exe')
    return [str(p) for p in paths if p.exists()]


def mac_candidates():
    paths = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        str(Path.home() / 'Applications' / 'Google Chrome.app' / 'Contents' / 'MacOS' / 'Google Chrome'),
    ]
    return [p for p in paths if Path(p).exists()]


def linux_candidates():
    names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    found = []
    for name in names:
        p = shutil.which(name)
        if p:
            found.append(p)
    return found


def get_installed_versions():
    system = platform.system().lower()
    versions = []

    if 'windows' in system:
        for exe in windows_candidates():
            v = get_version_from_command([exe, '--version'])
            if v:
                versions.append(('Google Chrome', exe, v))

    elif 'darwin' in system:
        for exe in mac_candidates():
            v = get_version_from_command([exe, '--version'])
            if v:
                versions.append(('Google Chrome', exe, v))

    else:
        for exe in linux_candidates():
            v = get_version_from_command([exe, '--version'])
            if v:
                versions.append(('Chrome/Chromium', exe, v))

    return versions


def compare(v1, v2):
    return (v1 > v2) - (v1 < v2)


def main():
    versions = get_installed_versions()
    if not versions:
        print('UNKNOWN: Chrome/Chromium executable not found or version unreadable')
        sys.exit(2)

    vulnerable = []
    patched = []

    for name, path, ver in versions:
        if compare(ver, TARGET) < 0:
            vulnerable.append((name, path, ver))
        else:
            patched.append((name, path, ver))

    if vulnerable:
        joined = '; '.join(f'{name} {".".join(map(str, ver))} at {path}' for name, path, ver in vulnerable)
        print(f'VULNERABLE: {joined}')
        sys.exit(1)

    joined = '; '.join(f'{name} {".".join(map(str, ver))} at {path}' for name, path, ver in patched)
    print(f'PATCHED: {joined}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: do not treat this like an emergency browser zero-day. Fold it into your normal Chrome currency program, verify fleet inventory for anything below 149.0.7827.53 (or .54 on Windows/macOS where applicable), and push updates through standard endpoint management; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, and your noisgate remediation SLA is therefore ≤365 days. In practice, because browsers are high-churn software, most enterprises should still clear this in their next routine browser update cycle rather than letting it age on the books.

Sources

  1. Chrome Releases stable desktop update for Chrome 149
  2. VulDB entry with full public description for CVE-2026-11008
  3. Chromium Security overview
  4. Chromium Site Isolation overview
  5. FIRST EPSS API documentation
  6. FIRST EPSS API endpoint
  7. CISA Known Exploited Vulnerabilities catalog
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.