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

Inappropriate implementation in WebAppInstalls in Google Chrome prior to 149

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

This is a burglar already inside the house finding an unlocked interior door, not kicking in the front entrance

CVE-2026-11023 is a Chrome *same-origin policy bypass* in WebAppInstalls. Affected builds are Google Chrome versions prior to 149.0.7827.53; Google shipped the fix in Chrome 149 for Linux as 149.0.7827.53 and for Windows/macOS as 149.0.7827.53/.54. The important clause in the description is not WebAppInstalls—it is *"who had compromised the renderer process"*: the attacker must already have code execution or equivalent control inside Chrome's sandboxed renderer before this bug matters.

Google's *Medium* label matches reality better than the scary-sounding browser context might suggest. This is not a one-click workstation takeover, not a sandbox escape, and not a standalone internet-exploitable entry point; it is a chain-enabler that turns a renderer compromise into cross-origin data access. For enterprise prioritization, that is worth fixing, but it does not outrank true initial-access or sandbox-escape Chrome bugs.

"This is a second-stage browser boundary break, not an initial-access bug"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a renderer foothold first

The attacker needs a *separate* weaponized browser bug or another method that already compromises Chrome's renderer process, typically via a crafted web page. In practice this means a private exploit chain, a different CVE, or a browser-based post-exploitation position inside the sandbox. CVE-2026-11023 does nothing for an attacker who only has a URL and a target user.
Conditions required:
  • Target is running Chrome prior to 149.0.7827.53
  • Victim visits attacker-controlled content
  • Attacker already has renderer-process compromise through another flaw or chain
Where this breaks in practice:
  • This is *post-initial-browser-compromise*; most opportunistic actors do not have a renderer exploit to pair with it
  • Modern browser exploit mitigations and site isolation raise the cost of landing step 1
  • No public exploit chain was found for this CVE specifically
Detection/coverage: Standalone vuln scanners will usually only flag version exposure here; they will not prove exploitability because the decisive prerequisite is a separate renderer compromise.
STEP 02

Drive the vulnerable WebAppInstalls path

Once inside the renderer, the attacker uses a crafted HTML page to reach WebAppInstalls behavior covered by issue 497538899. The bug is described as inappropriate implementation / insufficient input validation, which implies a logic or trust-boundary failure rather than memory corruption. That generally means the attacker must steer execution into a fairly specific code path instead of getting broad, reliable memory primitives.
Conditions required:
  • Renderer is already compromised
  • Attacker can script page behavior in the victim tab
  • The vulnerable code path is reachable in the victim's browsing context
Where this breaks in practice:
  • Bug details remain restricted in the Chromium tracker
  • Exploit reliability is narrower than classic memory-corruption bugs
  • Enterprise browsing restrictions or disabled app-install surfaces may reduce reachable population
Detection/coverage: You may see browser crash/telemetry only if the first-stage exploit is noisy; this step itself is more likely to blend in as normal page activity.
STEP 03

Break the origin boundary

The practical security impact is a bypass of the browser's same-origin policy. That lets the attacker cross a boundary Chrome is supposed to enforce between websites, enabling access to data or interactions that should stay isolated to another origin. This is materially useful for session theft, cross-origin reads, or chaining toward higher-value browser abuse, but it still stays inside browser/user context.
Conditions required:
  • The victim has valuable authenticated web sessions or cross-origin data in the browser
  • The targeted origin interaction is present and reachable from the compromised context
Where this breaks in practice:
  • Impact depends on what the user is signed into at the time
  • HttpOnly cookies, origin-scoped APIs, and app-specific server-side checks can limit blast radius
  • This does not itself escape the Chrome sandbox or execute native OS code
Detection/coverage: Network detections are weak because cross-origin abuse may look like legitimate browser traffic; focus on browser telemetry, exploit detection, and suspicious child-process or crash patterns from the first-stage foothold.
STEP 04

Monetize browser-resident access

With origin isolation weakened, the attacker can harvest selected cross-origin data, abuse authenticated state, or support account takeover objectives. This is the point where business impact shows up, but only if the attacker successfully completed the earlier renderer-compromise stage. That compounding prerequisite is the main reason this stays in the MEDIUM bucket.
Conditions required:
  • High-value browser sessions exist on the endpoint
  • The chain stays stable long enough to access target data
Where this breaks in practice:
  • Blast radius is per-browser-profile, not per-host or per-domain-controller
  • Session re-auth, MFA prompts, and server-side anti-abuse checks can interrupt abuse
Detection/coverage: Account-side detections are often stronger than host-side ones here: impossible travel, unusual session reuse, and anomalous web actions may reveal downstream abuse.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation found in the reviewed sources, and not listed in CISA KEV as of 2026-06-05.
Public PoC statusNo public proof-of-concept or exploit repo was found during review. The Chromium issue is still access-restricted, which usually suppresses copycat weaponization in the short term.
EPSS0.00021 from the user-supplied intel — extremely low, which fits a chained, second-stage browser bug rather than a broadly reusable entry bug.
KEV statusNo. No CISA KEV listing date because it is not in the catalog.
Vendor severity / scoreGoogle labels it Medium in the Chrome 149 release notes, but no vendor or authority CVSS score/vector is published.
CVSS viewNo official vector exists. *Inference:* comparable Chrome cases involving renderer already compromised plus same-origin policy bypass have landed between roughly 3.1 and 6.5; this case looks closer to the lower-middle end because it is confidentiality-focused and explicitly chained.
Affected versionsGoogle Chrome desktop prior to 149.0.7827.53. Google shipped fixed Chrome 149 on 2026-06-02; Windows/macOS received 149.0.7827.53/.54, Linux received 149.0.7827.53.
Fixed versionsPatch level is Chrome 149.0.7827.53 or later. For managed fleets, validate the platform-specific stable build actually deployed, especially Windows/macOS 149.0.7827.54 channels and downstream Chromium-based browsers once they rebase.
Exposure realityThis is an endpoint browser flaw, not an internet-facing service. Shodan/Censys-style exposure counts are not a meaningful denominator; your true exposure is the number of enterprise endpoints still running pre-149 Chrome.
Disclosure / reportingPublished 2026-06-04. Google release notes show it was reported by Google on 2026-03-29 under Chromium issue 497538899.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.4/10)

The decisive downgrading factor is the prerequisite that the attacker must have already compromised Chrome's renderer process before this bug is reachable in a meaningful way. That makes CVE-2026-11023 a *chain extender*, not a front-door exploit, and sharply reduces the number of real-world attacks that can operationalize it at scale.

HIGH It is a second-stage flaw requiring prior renderer compromise
MEDIUM Business impact estimate from same-origin-policy bypass wording
MEDIUM Score calibration without an official vendor/authority CVSS baseline

Why this verdict

  • Major downward pressure: requires prior renderer compromise — attacker position is not just unauthenticated remote; it implies successful exploitation of a separate browser bug first, which is a compounding prerequisite that excludes most opportunistic threat activity.
  • Impact is browser-bound, not host-bound — the stated outcome is *same-origin policy bypass*, which is serious for web sessions and data, but it is not native code execution, not a sandbox escape, and not direct OS compromise.
  • Population is broad but not uniformly reachable — Chrome is everywhere, but the exploitable population is really the subset of endpoints still on old builds *and* exposed to a functioning first-stage renderer exploit *and* carrying valuable authenticated web state at the moment of exploitation.
  • No active exploitation signal — no KEV listing, no public PoC found, and a tiny EPSS all point away from urgent internet-scale abuse.
  • Google already classed it as Medium — with no official CVSS to compare against, the vendor's own severity label is a sensible baseline, and the real-world friction audit does not justify moving it upward.

Why not higher?

Because this is not a standalone one-click compromise. The attacker must already be inside the renderer, and the described impact is a browser trust-boundary bypass rather than sandbox escape or host takeover. No public exploitation evidence or KEV listing removes the main amplifier that would otherwise push a chained browser flaw into HIGH.

Why not lower?

Same-origin policy bypasses still matter in enterprise browsers because they can expose authenticated sessions and cross-origin data from high-value SaaS applications. Chrome's footprint is enormous, so even a second-stage bug can become operationally relevant when paired with another browser exploit or a private chain.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update health — Audit whether Chrome stable is actually advancing to 149.0.7827.53+ across Windows, macOS, and Linux, and remediate broken update channels. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but for a browser fleet you should still validate update compliance this week because this control closes the issue without user action.
  2. Reduce exposure to untrusted browsing — Keep risky browsing in hardened profiles, isolated VDI, or remote browser isolation where you already use them. This does not remove the bug, but it reduces the odds that a separate renderer exploit reaches a high-value browser session before the patch is broadly deployed; for MEDIUM, there is no mitigation SLA, so use it as risk reduction while normal patching completes.
  3. Tighten web app install policy — Review enterprise policies controlling app/PWA installation surfaces and disable unneeded install capabilities where business use does not require them. This narrows reachable code paths in WebAppInstalls and is a practical containment move while remediation proceeds under the 365-day MEDIUM remediation window.
  4. Hunt for chained browser exploitation — Look for browser exploit indicators rather than this CVE in isolation: renderer crashes, abnormal Chrome child-process trees, exploit prevention hits, and suspicious follow-on web-session abuse. The CVE is only useful after a first-stage browser foothold, so detection effort belongs on the chain.
What doesn't work
  • A WAF does not meaningfully protect endpoint Chrome clients from a renderer-compromise-plus-SOP-bypass chain; this is not a server-side web app bug in your environment.
  • Perimeter internet scanning is not helpful because Chrome is client software, not a bannered external service.
  • Basic version-only vulnerability scanning is necessary but insufficient; it tells you who is unpatched, not whether the attacker can satisfy the renderer-compromise prerequisite.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke it with python3 check_chrome_cve_2026_11023.py; no admin rights are required for normal detection, though Windows registry access may work more consistently in a standard user session with local profile access.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11023.py
# Detect Google Chrome version and assess exposure to CVE-2026-11023.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED = (149, 0, 7827, 53)


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


def version_to_str(v):
    return '.'.join(str(x) for x in v)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_windows_version():
    try:
        import winreg
    except Exception:
        return None, 'winreg unavailable'

    reg_paths = [
        (winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
    ]

    for hive, path in reg_paths:
        try:
            key = winreg.OpenKey(hive, path)
            version, _ = winreg.QueryValueEx(key, 'version')
            v = parse_version(version)
            if v:
                return v, f'registry:{path}'
        except OSError:
            pass

    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]
    for exe in candidates:
        if exe and os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return v, exe

    return None, 'Chrome not found'


def get_macos_version():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for exe in candidates:
        if os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return v, exe

    plist_candidates = [
        '/Applications/Google Chrome.app/Contents/Info.plist',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/Info.plist'),
    ]
    for plist in plist_candidates:
        if os.path.exists(plist):
            out = run_cmd(['/usr/bin/defaults', 'read', plist, 'KSVersion'])
            v = parse_version(out)
            if v:
                return v, plist

    return None, 'Chrome not found'


def get_linux_version():
    cmds = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
        ['/opt/google/chrome/chrome', '--version'],
    ]
    for cmd in cmds:
        exe = cmd[0]
        if os.path.isabs(exe) and not os.path.exists(exe):
            continue
        if not os.path.isabs(exe) and shutil.which(exe) is None:
            continue
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v, ' '.join(cmd)
    return None, 'Chrome not found'


def main():
    system = platform.system().lower()
    if 'windows' in system:
        version, source = get_windows_version()
    elif 'darwin' in system:
        version, source = get_macos_version()
    else:
        version, source = get_linux_version()

    if version is None:
        print(f'UNKNOWN - Unable to determine Google Chrome version ({source})')
        sys.exit(2)

    if version < FIXED:
        print(f'VULNERABLE - Google Chrome version {version_to_str(version)} detected via {source}; fixed is {version_to_str(FIXED)} or later')
        sys.exit(1)
    else:
        print(f'PATCHED - Google Chrome version {version_to_str(version)} detected via {source}; fixed baseline is {version_to_str(FIXED)}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a chain-hardening browser update, not an emergency incident by itself. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for a MEDIUM finding, but in practice you should verify Chrome auto-update health and push remaining pre-149 endpoints through your normal browser ring this week because the actual fix is already available and low-friction. Use temporary policy tightening around app-install surfaces only where patch lag is stubborn; your formal noisgate remediation SLA is <= 365 days.

Sources

  1. Google Chrome stable release 149
  2. Chromium issue 497538899
  3. Quanteta CVE page for CVE-2026-11023
  4. GovCERT HK advisory for Chrome 149 fixes
  5. NVD analogous Chrome SOP-bypass case CVE-2026-7969
  6. NVD analogous Chrome SOP-bypass case CVE-2026-11244
  7. NVD analogous Chrome SOP-bypass case CVE-2026-5919
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.