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

Inappropriate implementation in Extensions in Google Chrome prior to 149

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

This is a peep hole in the browser wall, not a front-door lock failure

CVE-2026-11020 is an Extensions implementation flaw in Google Chrome that affects versions prior to 149.0.7827.53. Google’s public advisory classifies it as an issue that can let a remote attacker leak cross-origin data via attacker-controlled web content; the affected population is essentially desktop Chrome installs that have not yet updated to the fixed 149 build.

Reality check: this is important, but it is not an all-hands fire. The attacker still needs to drive a victim into rendering malicious content in a vulnerable browser, and the public record points to confidentiality loss, not clean RCE or a sandbox escape. With no KEV, no public exploitation evidence, no public PoC, and a very low EPSS, the right enterprise reading is ASSESSED AT MEDIUM, not panic-tier.

"ASSESSED AT MEDIUM: real confidentiality impact, but it still needs a user in a vulnerable browser to visit attacker content"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Stage the lure page

The attacker hosts or embeds a crafted web page designed to exercise the vulnerable Extensions implementation path in Chrome. The practical weapon here is just a normal browser delivery vector: phishing link, malvertising, chat link, or compromised site content.
Conditions required:
  • Attacker can deliver a URL or web content to the victim
  • Victim uses Chrome prior to 149.0.7827.53
Where this breaks in practice:
  • This is UI-required; no drive-by network-only exploitation against a headless service
  • Email filtering, browser isolation, safe browsing, and user habits reduce reach
Detection/coverage: Traditional network vulnerability scanners will not see this. Coverage is mostly indirect through browser version inventory, web filtering telemetry, Safe Browsing hits, and proxy logs.
STEP 02

Trigger the Extensions flaw

When the victim renders the page, the browser hits the vulnerable code path in the Extensions subsystem. Public details are intentionally sparse, but the advisory ties the bug to cross-origin data leakage rather than code execution, so the exploit objective is data boundary bypass, not process takeover.
Conditions required:
  • Victim browses to attacker-controlled content
  • The specific vulnerable execution path is reachable in that browser build
Where this breaks in practice:
  • Chrome bug details are still restricted, so exploit development is not turnkey from public data
  • Modern browser mitigations and site isolation still force the attacker into a narrower confidentiality-oriented path
Detection/coverage: EDR usually will not see a distinct exploit artifact here unless follow-on theft or unusual child-process behavior occurs. Browser crash telemetry or forensic reproduction is more likely than signature-based detection.
STEP 03

Read cross-origin data

Successful exploitation lets the attacker exfiltrate data that should remain isolated across origins. In enterprise terms, think session-linked page content, tokens, or sensitive application state visible to the browser but not normally readable by the attacker’s origin.
Conditions required:
  • The victim is concurrently authenticated to a target origin or handling valuable browser data
  • The leak yields data of real value to the attacker
Where this breaks in practice:
  • Impact is bounded by what the victim has open or accessible in-session
  • HttpOnly cookies, re-auth walls, short-lived tokens, and application-side CSRF/session controls can limit practical payoff
Detection/coverage: DLP and secure web gateways may catch exfiltration patterns, but there is no dependable standalone signature for the leak itself.
STEP 04

Monetize the stolen context

The attacker uses leaked cross-origin data for account takeover support, internal app reconnaissance, or follow-on phishing against the same user. This is where the business risk shows up, but it is a second-stage payoff, not immediate host compromise.
Conditions required:
  • Leaked data is reusable or reveals meaningful business context
  • The target application does not fully neutralize replay or context abuse
Where this breaks in practice:
  • Many enterprise apps bind sessions to device, MFA, or conditional access
  • The bug does not by itself imply endpoint persistence, lateral movement, or domain compromise
Detection/coverage: Look for suspicious session reuse, identity anomalies, impossible travel, and unusual application access after browser lure activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in authoritative sources checked; not present in CISA KEV as of the catalog page reviewed
Proof-of-concept availabilityNo public PoC located. Chromium issue details appear restricted, which raises attacker friction versus fully disclosed browser bugs
EPSS0.00035 from the supplied intel block; that is extremely low probability in absolute terms. *Percentile was not independently verified from an authoritative page during this review*
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog
Vendor severity postureGoogle’s June 2, 2026 Chrome stable release lists CVE-2026-11020 as Medium in the desktop advisory
Affected versionsGoogle Chrome prior to 149.0.7827.53 on desktop platforms called out by the stable release notes: Windows, Mac, and Linux
Fixed versionsPatch to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and Mac per Google’s stable channel post
CVSS baselineNo vendor/authority CVSS published. *Inference:* this behaves like a UI-required, confidentiality-focused browser bug, not a remote unauthenticated host-takeover path
Exposure and scanning reality*Inference:* this is not internet-enumerable in the usual Shodan/Censys sense because the vulnerable surface is a client browser, so prioritize by endpoint version inventory, not external attack-surface scans
Disclosure / reporterDisclosed 2026-06-04 in CVE/NVD feeds, with the Chrome stable release published 2026-06-02; the advisory credits Google as reporter for this specific bug entry
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.6/10)

The decisive downward pressure here is attacker reachability: this is a client-side, UI-required browser bug that needs a victim on a vulnerable Chrome build to render attacker content. The upside risk is real because cross-origin data leakage can expose authenticated business data, but the absence of RCE, sandbox escape, KEV listing, public PoC, or observed exploitation keeps it in MEDIUM.

HIGH Affected version floor and fixed build identification
MEDIUM Practical exploitability and impact without full bug-detail disclosure
MEDIUM Severity bucket selection in the absence of vendor CVSS

Why this verdict

  • UI-required delivery lowers the score: the attacker needs a user to browse attacker-controlled content; this is not an unauthenticated network service exploit
  • Confidentiality-focused impact, not host takeover: the public description points to cross-origin data leakage, which matters, but it is materially narrower than code execution or sandbox escape
  • No exploitation signals: no KEV listing, no public PoC, and the supplied EPSS 0.00035 all push downward from any hypothetical worst-case browser severity
  • Client-side population is broad, but reachable exposure is narrower: Chrome is everywhere, yet only users on vulnerable builds who hit malicious content are in play
  • Enterprise controls can blunt payoff: application session controls, short-lived tokens, conditional access, browser isolation, and web filtering all reduce the real-world blast radius after successful leakage

Why not higher?

There is no public evidence that this bug yields code execution, sandbox escape, or zero-click compromise. The attacker must first win browser interaction and then get useful data out of the victim’s authenticated context, which is a meaningful chain with real friction.

Why not lower?

Cross-origin isolation is a serious browser trust boundary, and a remote website that can read data across that boundary is not just hygiene noise. Chrome’s deployment scale means even a medium-confidence data leak can matter broadly if you have large unmanaged or slow-updating browser populations.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure managed endpoints are actually accepting Chrome stable updates and not pinned below 149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA, but this is still the cleanest control because browser fleet drift is what keeps this bug alive.
  2. Block risky browsing paths — Use secure web gateway, DNS filtering, Safe Browsing enforcement, or remote browser isolation for high-risk user groups to reduce the chance that attacker-controlled pages get rendered. There is no mitigation SLA — go straight to the 365-day remediation window, but these controls are worth tightening immediately if you have slow patch rings.
  3. Harden session reuse — Prefer short-lived sessions, conditional access, step-up MFA for sensitive apps, and device-bound auth where available so leaked browser-side context is harder to replay. This reduces real business impact even if the browser bug is triggered.
  4. Inventory version laggards — Find endpoints still below 149.0.7827.53 and map them to business owners. In a 10,000-host fleet, the problem is usually not the patch existing; it is the unmanaged or pinned population.
What doesn't work
  • A perimeter vulnerability scan will not reliably find this, because the vulnerable surface is the endpoint browser, not an externally listening service
  • Server-side WAF rules do not meaningfully solve a client-browser implementation flaw unless they happen to block the exact lure content path
  • Endpoint AV signatures alone are weak here; without a public exploit artifact, version control and browsing-path controls do more than hoping for malware-style detection
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management agent, not from an auditor workstation. Invoke it with python3 chrome_cve_2026_11020_check.py on macOS/Linux or py chrome_cve_2026_11020_check.py on Windows; no admin rights are required if Chrome is installed in standard locations.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11020 local exposure check for Google Chrome
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

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 cmp_ver(a, b):
    return (a > b) - (a < b)


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


def get_windows_versions():
    versions = []
    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 path in candidates:
        if path and os.path.exists(path):
            out = run_cmd([
                'powershell', '-NoProfile', '-Command',
                f"(Get-Item '{path}').VersionInfo.ProductVersion"
            ])
            ver = parse_version(out)
            if ver:
                versions.append((path, ver))
    return versions


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


def get_linux_versions():
    versions = []
    bins = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    seen = set()
    for b in bins:
        p = which(b)
        if p and p not in seen:
            seen.add(p)
            out = run_cmd([p, '--version'])
            ver = parse_version(out)
            if ver:
                versions.append((p, ver))
    return versions


def main():
    system = platform.system().lower()
    if 'windows' in system:
        versions = get_windows_versions()
    elif 'darwin' in system:
        versions = get_macos_versions()
    else:
        versions = get_linux_versions()

    if not versions:
        print('UNKNOWN - Google Chrome not found or version could not be determined')
        sys.exit(2)

    vulnerable = []
    patched = []
    for path, ver in versions:
        if cmp_ver(ver, FIXED) < 0:
            vulnerable.append((path, ver))
        else:
            patched.append((path, ver))

    if vulnerable:
        for path, ver in vulnerable:
            print(f'VULNERABLE - {path} version {".".join(map(str, ver))} < {".".join(map(str, FIXED))}')
        sys.exit(1)

    for path, ver in patched:
        print(f'PATCHED - {path} version {".".join(map(str, ver))} >= {".".join(map(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 browser-fleet hygiene issue with real data-leak potential, not as an emergency outage event. Under the noisgate mitigation SLA, there is no mitigation SLA — go straight to the 365-day remediation window; under the noisgate remediation SLA, get every managed endpoint to Chrome 149.0.7827.53 or later by 2027-06-04, and use version inventory right away to flush out pinned, unmanaged, or update-broken systems that would otherwise sit vulnerable indefinitely.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chrome stable updates label page showing CVE-2026-11020 severity listing
  3. Chromium issue 497440270
  4. CISA Known Exploited Vulnerabilities Catalog
  5. CISA KEV JSON feed
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. Chrome Security Page
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.