← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11190 · CWE-284 · 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 fake contractor badge that only works after security already let the person into the building

CVE-2026-11190 is an *Extensions* access-control failure in Chrome desktop that lets a *malicious extension* overstep Chrome's intended boundaries after the user installs it. The fixed builds are Chrome 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS; anything older is in scope. One important cleanup point: the vendor release post labels this issue as insufficient policy enforcement in Extensions, while the title in your intel says inappropriate implementation. For defenders, the operational meaning is the same: a hostile extension can bypass an internal browser control once present.

Google's MEDIUM 6.5 is technically defensible in a lab, but too generous for enterprise prioritization. This is *not* unauthenticated remote exploitation from a web page; it requires the attacker to first convince a user to install a malicious extension, and many managed Chrome estates already suppress that with extension allowlisting, force-install, or store restrictions. In other words, the exploit chain starts after a major security control failure or a deliberately permissive browser policy, so the real-world reachable population is much smaller than the CVSS baseline implies.

"This is a bad-extension multiplier, not a drive-by browser bug; most managed estates should downgrade it."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land a malicious extension

The attacker needs a weaponized CRX or Chrome Web Store listing and a delivery channel such as phishing, malvertising, or a fake productivity tool. The bug is useless until the extension is actually installed in the victim's Chrome profile.
Conditions required:
  • Attacker can deliver a malicious extension or store link
  • Target users are allowed to install extensions or sideload them
  • User interaction succeeds
Where this breaks in practice:
  • Many enterprises block arbitrary extension installs with ExtensionSettings
  • Force-installed allowlisted extensions sharply reduce the attack surface
  • Users still have to click through installation and permission prompts unless policy bypasses normal governance
Detection/coverage: Traditional network scanners will miss this entirely. Coverage is mainly extension inventory, browser policy telemetry, and user-reporting rather than perimeter vulnerability scanning.
STEP 02

Abuse the policy-enforcement flaw

Once installed, the extension abuses CVE-2026-11190 to bypass a discretionary access-control check in Chrome's Extensions subsystem. The vendor description does not indicate OS-level code execution or sandbox escape; the impact is bounded to extension trust and browser policy semantics.
Conditions required:
  • Victim is running Chrome before 149.0.7827.53
  • The malicious extension reaches the vulnerable code path
Where this breaks in practice:
  • Attack value depends on what extra access the extension can obtain beyond its normal grant set
  • Browser version roll-forward usually closes the window quickly in auto-updating estates
Detection/coverage: There is unlikely to be high-fidelity signature coverage for the exploit primitive itself. Detection comes from spotting suspicious extension IDs, unusual permission combinations, and Chrome version lag.
STEP 03

Operate inside the user's browser trust zone

After the bypass, the extension can perform actions Chrome intended to restrict, which is why the published CVSS gives the issue high integrity impact. Practically, that means browser-context abuse against the user's profile and browsing session, not turnkey host takeover.
Conditions required:
  • The target user meaningfully uses Chrome for enterprise workflows
  • The extension remains enabled long enough to act
Where this breaks in practice:
  • Impact stays tied to the browser profile rather than the operating system
  • Managed profile telemetry can expose the installed extension, version, and status
  • Removing or disabling the extension cuts off the attacker even before patching
Detection/coverage: Chrome Enterprise profile reporting can show installed extensions and browser versions. EDR may see browser profile tampering, but many products will not attribute activity cleanly to this CVE.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation evidence found in the sources reviewed, and the CVE is not KEV-listed. That materially lowers urgency versus Chrome's true zero-days.
PoC availabilityNo public PoC located in the sources reviewed. That does not make it safe, but it does reduce copy-paste attacker access compared with heavily weaponized browser bugs.
EPSS0.00012 from your intel, which is extremely low. *Inference:* that places it in the extreme low tail of likely exploitation probability rather than the operator hot zone.
KEV statusNot listed in CISA KEV as of 2026-06-06. For Chrome issues, KEV absence usually means no public government-confirmed exploitation signal yet.
CVSS meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N says *network-reachable with user interaction and no prior privileges*, but that hides the decisive real-world prerequisite: the attacker must first get a malicious extension installed.
Affected versionsChrome desktop before 149.0.7827.53. Google shipped fixes in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS).
Fixed versions / backportsPrimary fix is in Google Chrome stable 149.0.7827.53+. No downstream distro backport information was identified in the reviewed sources; if you run distro-packaged Chromium, verify the distro advisory separately.
Exposure and scanning realityThis is not an internet-facing service flaw, so Shodan/Censys/FOFA-style population counts are largely irrelevant. Exposure is driven by endpoint count, browser version lag, and whether users can install arbitrary extensions.
DisclosurePublished 2026-06-04; the Chrome stable channel release carrying the fix was announced 2026-06-02.
Reporter / attributionThe Chrome release notes attribute CVE-2026-11190 to Google and mark it as a Medium severity issue. Notably, the release post calls it insufficient policy enforcement in Extensions, which is the wording I would trust over secondary summaries.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.4/10)

The single biggest severity suppressor is that exploitation starts with getting a malicious extension installed, which is already a major control failure in a managed enterprise. This sharply narrows the exposed population compared with a normal browser RCE or drive-by web bug and keeps the blast radius centered on the browser profile, not direct host compromise.

HIGH Attacker prerequisite analysis: malicious extension installation is the gating factor
MEDIUM Practical impact estimate inside the browser trust boundary

Why this verdict

  • Baseline starts at vendor MEDIUM 6.5, then drops hard because this is not drive-by exploitable; the attacker needs user interaction *and* a successful malicious extension install first.
  • Enterprise exposure is much smaller than Chrome's install base because modern managed deployments commonly use ExtensionSettings, allowlists, force-install, or store restrictions that prevent arbitrary CRX installation.
  • The prerequisite implies post-control-failure abuse, not clean initial access. Requiring an already-installed malicious extension compounds downward pressure on severity even if the in-browser integrity impact is real.

Why not higher?

This is not the kind of Chrome bug that turns any page view into compromise. There is no evidence here of zero-click exploitation, KEV listing, or host-level escape; the attacker must first land a malicious extension and then exploit a browser-internal trust failure.

Why not lower?

It is still a real security-boundary failure in one of the most widely deployed enterprise applications on the planet. In permissive or lightly managed fleets where users can install extensions freely, a phishing campaign or fake store listing could abuse this at scale against the browser profile.

05 · Compensating Control

What to do — in priority order.

  1. Lock down extension installs — Use Chrome Enterprise ExtensionSettings to default-deny unapproved extensions and explicitly allow or force-install only sanctioned ones. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene, but if your extension governance is currently open, close that gap in the normal hardening cycle because it removes the exploit's main prerequisite.
  2. Turn on browser and profile reporting — Enable Chrome managed browser and managed profile reporting so you can query browser versions and installed extension inventories centrally. For a LOW verdict there is no mitigation SLA; do this through the next normal admin change window because it improves both this case and every future extension-borne incident.
  3. Hunt for non-admin extensions — Review managed profile inventories for extensions with install type other than admin-controlled and investigate anything unexpected. For a LOW verdict there is no mitigation SLA; fold it into routine browser hygiene unless you already suspect extension abuse.
  4. Preserve auto-update defaults — Keep Chrome auto-updates enabled and avoid version pinning beyond what your testing program truly requires, so minor security fixes like 149.0.7827.53 land without manual intervention. For a LOW verdict there is no mitigation SLA; this is steady-state operational discipline rather than emergency action.
What doesn't work
  • A perimeter WAF does nothing here because the exploit lives in the local browser extension subsystem, not a server-side web app.
  • Email filtering helps only at the delivery edge; it does not stop users from installing a malicious extension from other channels or direct store links.
  • Relying on CVSS alone does not prioritize this correctly because the score underweights the real-world prerequisite of malicious extension installation.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tool to check the locally installed Chrome/Chromium version. Example: python3 check_chrome_cve_2026_11190.py; it needs no admin rights for standard paths and registry reads, though broader file-system visibility helps on locked-down hosts.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11190.py
# Detects whether the local Chrome/Chromium installation is vulnerable to CVE-2026-11190.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

PATCHED_MIN = (149, 0, 7827, 53)


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


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


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


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


def get_windows_versions():
    findings = []
    try:
        import winreg
    except Exception:
        return findings

    reg_paths = [
        (winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon', 'version', 'Chrome HKCU'),
        (winreg.HKEY_LOCAL_MACHINE, r'Software\Google\Chrome\BLBeacon', 'version', 'Chrome HKLM'),
        (winreg.HKEY_CURRENT_USER, r'Software\Chromium\BLBeacon', 'version', 'Chromium HKCU'),
        (winreg.HKEY_LOCAL_MACHINE, r'Software\Chromium\BLBeacon', 'version', 'Chromium HKLM'),
        (winreg.HKEY_LOCAL_MACHINE, r'Software\WOW6432Node\Google\Chrome\BLBeacon', 'version', 'Chrome WOW6432Node'),
        (winreg.HKEY_LOCAL_MACHINE, r'Software\WOW6432Node\Chromium\BLBeacon', 'version', 'Chromium WOW6432Node'),
    ]

    for hive, path, value_name, label in reg_paths:
        try:
            key = winreg.OpenKey(hive, path)
            value, _ = winreg.QueryValueEx(key, value_name)
            v = parse_version(str(value))
            if v:
                findings.append((label, v))
        except Exception:
            pass
    return findings


def get_macos_versions():
    findings = []
    apps = [
        ('Google Chrome', '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ('Chromium', '/Applications/Chromium.app/Contents/MacOS/Chromium'),
    ]
    for label, path in apps:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                findings.append((label, v))
    return findings


def get_linux_versions():
    findings = []
    candidates = [
        ('google-chrome', ['google-chrome', '--version']),
        ('google-chrome-stable', ['google-chrome-stable', '--version']),
        ('chromium', ['chromium', '--version']),
        ('chromium-browser', ['chromium-browser', '--version']),
        ('chrome', ['chrome', '--version']),
    ]
    for label, cmd in candidates:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            findings.append((label, v))
    return findings


def main():
    system = platform.system().lower()
    findings = []

    if 'windows' in system:
        findings = get_windows_versions()
    elif 'darwin' in system:
        findings = get_macos_versions()
    else:
        findings = get_linux_versions()

    if not findings:
        print('UNKNOWN - No Chrome/Chromium version found')
        sys.exit(2)

    vulnerable = []
    patched = []
    for label, version in findings:
        if compare(version, PATCHED_MIN) < 0:
            vulnerable.append((label, version))
        else:
            patched.append((label, version))

    for label, version in findings:
        status = 'VULNERABLE' if compare(version, PATCHED_MIN) < 0 else 'PATCHED'
        print(f'{status} - {label} {ver_to_str(version)}')

    if vulnerable:
        worst = ', '.join(f'{label} {ver_to_str(version)}' for label, version in vulnerable)
        print(f'VERDICT: VULNERABLE - Found version(s) older than {ver_to_str(PATCHED_MIN)}: {worst}')
        sys.exit(1)

    best = ', '.join(f'{label} {ver_to_str(version)}' for label, version in patched)
    print(f'VERDICT: PATCHED - All discovered version(s) are >= {ver_to_str(PATCHED_MIN)}: {best}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: do not treat this like a Chrome zero-day firefight. Query your fleet for Chrome versions and extension inventories, confirm that arbitrary extension installs are blocked where they should be, and make sure lagging browsers roll to 149.0.7827.53+ through your normal browser update channel. Because this is LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene; the practical work is governance: tighten extension policy, verify reporting, and let auto-update clean up version lag without burning emergency patch capacity.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  2. Canadian Centre for Cyber Security advisory AV26-544
  3. Chrome Enterprise: Configure the ExtensionSettings policy
  4. Chrome Enterprise: View Chrome version details
  5. Chrome Enterprise: View Chrome browser profile details
  6. Chrome Enterprise: Manage Chrome updates
  7. FIRST EPSS documentation
  8. 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.