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

Insufficient policy enforcement in Extensions in Google Chrome prior to 149

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

This is not a burglar kicking in the front door, it is a fake contractor getting a badge and then wandering past an internal rope line

CVE-2026-11014 is an Extensions policy-enforcement flaw in Google Chrome affecting versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS, per Google's June 2026 desktop stable update advisory. The public description available in the prompt and indexed feeds is incomplete, but the authoritative record consistently places it in the Extensions component and requires the attacker to convince a user to install a malicious extension before the bug matters.

paragraph 2 vendor severity does not exist here, so the right move is a ground-up assessment. In real fleets this is much lower risk than a normal Chrome RCE because it is not reachable by simply browsing to a page; it depends on a successful malicious-extension install, and in mature enterprises extension allowlisting, store restrictions, and user friction cut the reachable population hard. The bug still matters because Chrome is ubiquitous and extension-boundary failures can expose browser-resident data or permissions, but this is a narrow, post-social-engineering abuse path, not an internet-edge patch-now event.

"Assessed at LOW: this starts with a malicious extension install, not a drive-by browser compromise"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land a malicious extension

The attacker first has to get code execution in the browser's extension context by persuading the user to install a malicious Chrome extension. Weaponized tool: a crafted crx or Chrome Web Store listing referenced by the attacker; the public CVE text itself says the attacker must convince the user to install it.
Conditions required:
  • User can install extensions at all
  • User accepts the extension prompt or sideload path
  • Enterprise policy does not block the extension or installation source
Where this breaks in practice:
  • Many enterprise Chrome deployments use force-install or allowlists only
  • Chrome Web Store trust prompts and permission prompts add user friction
  • Security teams often block developer mode, sideloading, and off-store installs
Detection/coverage: Good coverage if you log extension installs from Chrome enterprise reporting, EDR browser telemetry, or Windows/macOS configuration changes. Weak coverage in unmanaged BYOD.
STEP 02

Trigger the Extensions policy bypass

Once the extension is installed, the attacker abuses the vulnerable Extensions policy boundary in Chrome versions before 149.0.7827.53. Weaponized tool: the malicious extension itself; this is not a separate network exploit and does not look like classic drive-by browser exploitation.
Conditions required:
  • Victim is running a vulnerable Chrome build
  • The extension code reaches the affected API or policy path
  • The extension's intended permissions are insufficient without exploiting the flaw
Where this breaks in practice:
  • If the attacker already got a powerful extension installed, the incremental value of the CVE may be modest
  • Modern extension permission models, store review, and enterprise policy narrow the reachable set
  • Some exploit paths may fail if the target user profile has restricted extension capabilities
Detection/coverage: Limited scanner coverage beyond version detection. Behavioral detection depends on extension telemetry and browser audit events, not perimeter tools.
STEP 03

Abuse the extra capability

The payoff is whatever policy boundary the flaw lets the malicious extension cross: typically extra data access, UI abuse, or bypass of browser-enforced restrictions. Weaponized tool: extension JavaScript running under the attacker's control after the policy bypass, potentially targeting browser sessions, internal web apps, or user trust.
Conditions required:
  • User profile contains valuable browser data or sessions
  • The target workflows are actually used in that browser profile
  • No compensating extension restrictions stop the follow-on action
Where this breaks in practice:
  • Blast radius is usually the current user profile, not remote code execution across the host
  • No evidence found of in-the-wild exploitation or commodity tooling
  • Enterprise session protections and conditional access can reduce downstream value
Detection/coverage: Look for anomalous extension behavior, unexpected new extension IDs, browser profile changes, and suspicious access patterns to internal apps shortly after extension installation.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation signal found in the sources reviewed; not in CISA KEV.
Proof-of-concept availabilityNo public PoC located in the sources reviewed. Public Chromium issue references exist for related Chrome extension-boundary bugs, but I did not find a weaponized repo or exploit kit for this CVE.
EPSS0.00008 from the user-provided intel block, which is effectively negligible; percentile was not surfaced in the authoritative sources I could access.
KEV statusNo. CISA's KEV catalog does not list CVE-2026-11014 as of 2026-06-05.
CVSS baselineNo vendor or authority CVSS exists for this CVE. *Inference from comparable Chrome extension-policy bugs:* similar cases have landed around 4.2-4.3 / Medium in downstream enrichment, but this CVE itself has no official baseline score.
Affected versionsChrome before 149.0.7827.53 on Linux; Google's desktop advisory lists 149.0.7827.53/54 for Windows/macOS stable updates.
Fixed versions149.0.7827.53 or later on Linux; 149.0.7827.53/54 or later on Windows/macOS, depending on platform build.
Exposure realityNot meaningfully internet-enumerable with Shodan/Censys because this is a client-side browser/extension logic flaw, not a server-side listening service. *Inference:* exposure is governed by extension installation freedom and browser patch lag, not by network perimeter reachability.
Disclosure date2026-06-04.
Reporter / researcherNot publicly attributed in the sources I could verify.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to LOW (2.9/10)

The decisive factor is the attacker position requirement: exploitation starts only after the attacker gets a user to install a malicious extension, which is a major real-world filter in managed Chrome fleets. That prerequisite makes this a narrow post-social-engineering abuse path with limited reachable population, despite Chrome's massive footprint.

MEDIUM Severity assessment from incomplete public CVE text
HIGH Affected version floor and fixed build
HIGH Low exploitation pressure from KEV/EPSS signals

Why this verdict

  • Downward pressure: requires malicious extension install first — attacker position is neither unauthenticated remote nor normal browsing; they must win a user-consent/social-engineering step that many enterprise Chrome policies block outright.
  • Downward pressure: reachable population is much smaller than 'all Chrome users' — only tenants that allow user-installed extensions, sideloading, or weak extension governance are plausibly exposed.
  • Downward pressure: this is incremental abuse, not initial host compromise — the attacker already has extension code executing in the browser, so the CVE amplifies that foothold instead of creating a clean drive-by path.
  • Downward pressure: weak threat-intel signal — no KEV listing, no public exploitation evidence found, and the provided EPSS of 0.00008 is near floor.
  • Upward pressure: Chrome is everywhere — if you do permit user-installed extensions, one bug in the extension trust boundary can still reach a large number of endpoints and sensitive browser sessions.

Why not higher?

This is not a webpage-only exploit, not an unauthenticated remote code execution path, and not a practical internet-edge issue. The chain begins with a malicious extension install, which implies either failed user judgment or weak enterprise extension governance before the CVE adds value.

Why not lower?

It is not IGNORE because Chrome is ubiquitous and browser sessions are high-value targets in large enterprises. If even a subset of your fleet allows user-installed extensions, this kind of boundary failure can still expose internal app sessions, browser data, or trusted UI flows.

05 · Compensating Control

What to do — in priority order.

  1. Enforce extension allowlisting — Restrict Chrome to approved extension IDs using enterprise policy and disable off-store installs. For a LOW verdict there is no formal mitigation SLA; treat this as backlog hygiene and fold it into your normal browser-governance cycle.
  2. Block developer mode and sideloading — Shut off the easiest non-store delivery paths for malicious crx packages and unpacked extensions. This directly attacks the highest-friction prerequisite in the chain; again, no SLA for LOW, but do it as standard hardening.
  3. Audit high-risk extension permissions — Review extensions requesting broad host access, debugger, clipboard, cookies, tabs, downloads, or identity permissions. Where possible, remove or replace them in the next governance review because a policy-bypass bug is more dangerous when the starting extension set is already over-permissioned.
  4. Turn on browser and extension telemetry — Use Chrome enterprise reporting, EDR browser telemetry, and software inventory to alert on newly installed extension IDs and unmanaged installs. This helps you catch the prerequisite event that traditional network tools will miss.
What doesn't work
  • A WAF or reverse proxy does not help; this is not an inbound web-app attack against your servers.
  • Perimeter vulnerability scanning will not tell you who is about to install a malicious extension; at best it identifies outdated Chrome versions.
  • Email filtering alone is insufficient because the social-engineering lure can arrive through chat, docs, ads, forums, or direct user browsing.
06 · Verification

Crowdsourced verification payload.

Run this on the endpoint itself or through your fleet management agent. Invoke it as python3 chrome_cve_2026_11014_check.py on macOS/Linux or py chrome_cve_2026_11014_check.py on Windows; no administrator rights are required, but local file/process access to discover the Chrome binary helps coverage.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Chrome version against CVE-2026-11014 fixed build
# Outputs: 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

FIXED = (149, 0, 7827, 53)


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


def run_version(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=5)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_ver(out)
    except Exception:
        return None


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


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


def linux_candidates():
    bins = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    found = []
    for b in bins:
        p = shutil.which(b)
        if p:
            found.append(Path(p))
    extra = [
        Path('/opt/google/chrome/chrome'),
        Path('/usr/bin/google-chrome'),
        Path('/usr/bin/google-chrome-stable'),
        Path('/snap/bin/chromium'),
    ]
    for p in extra:
        if p.exists():
            found.append(p)
    dedup = []
    seen = set()
    for p in found:
        s = str(p)
        if s not in seen:
            seen.add(s)
            dedup.append(p)
    return dedup


def discover():
    system = platform.system().lower()
    candidates = []
    if 'windows' in system:
        candidates = windows_candidates()
    elif 'darwin' in system:
        candidates = mac_candidates()
    else:
        candidates = linux_candidates()

    for c in candidates:
        ver = run_version([str(c), '--version'])
        if ver:
            return str(c), ver

    # Fallbacks
    if 'windows' in system:
        try:
            import winreg
            keys = [
                r'SOFTWARE\Google\Chrome\BLBeacon',
                r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
            ]
            for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
                for key in keys:
                    try:
                        with winreg.OpenKey(hive, key) as k:
                            version, _ = winreg.QueryValueEx(k, 'version')
                            ver = parse_ver(version)
                            if ver:
                                return 'registry', ver
                    except OSError:
                        pass
        except Exception:
            pass

    return None, None


def main():
    src, ver = discover()
    if not ver:
        print('UNKNOWN: Google Chrome version not found')
        sys.exit(2)

    ver_str = '.'.join(map(str, ver))
    src_str = src or 'unknown source'

    if cmp_ver(ver, FIXED) < 0:
        print(f'VULNERABLE: Chrome {ver_str} from {src_str} is older than fixed build 149.0.7827.53')
        sys.exit(1)
    else:
        print(f'PATCHED: Chrome {ver_str} from {src_str} is at or newer than 149.0.7827.53')
        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 emergency RCE. First, verify whether your fleet already blocks user-installed or sideloaded extensions; if it does, document that as the key compensating control and push the browser update through your routine channel. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene — but you should still roll patched Chrome in your normal browser maintenance cycle and prioritize any business units that allow unmanaged extensions.

Sources

  1. Google Chrome Stable Channel Update for Desktop
  2. Canadian Centre for Cyber Security advisory AV26-544
  3. GovCERT.HK alert A26-06-08
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS data and statistics
  7. NVD entry for analogous Chrome extension-policy issue CVE-2026-11212
  8. Chromium historical enterprise extension policy issue
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.