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

Insufficient policy enforcement in Extensions in Google Chrome prior to 149

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

This is a bad valet key, not a broken front door

CVE-2026-11267 is an insufficient policy enforcement flaw in Chrome Extensions affecting Google Chrome before 149.0.7827.53. Based on the Chromium fix that blocks message connections from sandboxed extension pages, the practical issue is that a malicious extension could abuse an extension-internal trust boundary and reach messaging or privileged flows it should not have reached. The affected desktop builds were fixed in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.

Google's MEDIUM 4.3 label is already restrained, and in enterprise reality it still trends down, not up. The decisive friction is that the attacker does not get this from a random website alone; they need the victim to install a malicious extension first, which is a separate social-engineering or policy-control failure. That makes this a post-user-action browser hardening issue with narrow real-world reach, not a broad remote compromise bug.

"This is a trust-boundary bug behind a bigger gate: the attacker first has to get a malicious extension installed."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious extension

The attacker needs a weaponized Chrome extension / CRX or a trojanized Web Store listing and must convince a user to install it. In enterprise fleets, this usually means social engineering, abusing unmanaged browsers, or finding an organization that allows broad user-driven extension installs.
Conditions required:
  • Target user can install extensions or already has an attacker-controlled extension
  • User accepts install prompts or admin policy allows the extension
Where this breaks in practice:
  • Managed Chrome can block all but allowlisted extensions
  • Users must perform a visible install action
  • Chrome Web Store review, post-publication monitoring, and Safety Check reduce but do not eliminate bad extensions
Detection/coverage: Good coverage from Chrome Enterprise extension inventory, allow/block policies, EDR browser telemetry, and suspicious-extension reporting; weak coverage on unmanaged personal browsers.
STEP 02

Reach the flawed extension trust boundary

The likely exploit path matches the Chromium security fix titled "[Extensions] Don't allow message connections from sandboxed pages". A malicious extension uses a sandboxed or spoofed source context to attempt an extension message-channel operation that policy should have denied.
Conditions required:
  • Attacker controls extension code execution
  • Victim is on a vulnerable Chrome build prior to 149.0.7827.53
Where this breaks in practice:
  • This is not reachable from arbitrary network traffic alone
  • The bug appears tied to a specific extension messaging edge case rather than a general browser RCE path
Detection/coverage: Vulnerability scanners will mostly identify version exposure, not exploit success. Browser crash/process-kill telemetry may show bad-message terminations in failed exploit attempts.
STEP 03

Bypass policy enforcement inside Extensions

If the bypass succeeds, the malicious extension crosses a boundary Chrome intended to enforce and can interact with extension messaging or privileged logic in ways that sandboxing rules should have prevented. That is a privilege amplifier inside the extension model, not a clean remote takeover of the host.
Conditions required:
  • The specific sandboxed-page or messaging abuse path works against the installed build
  • The extension's follow-on logic is built to exploit the bypass
Where this breaks in practice:
  • Impact is bounded by browser/extension context, not an instant OS-level compromise
  • Enterprise restrictions on extension permissions and host access can reduce blast radius
Detection/coverage: Look for anomalous extension behavior, unusual permission usage, and browser telemetry tied to extension IDs; most network controls will not see this cleanly.
STEP 04

Abuse gained access for tampering

The CVSS vector and vendor scoring indicate integrity-only impact, so the realistic end state is tampering with browser actions, extension workflows, or data handling rather than broad confidentiality loss or host denial of service. In practice, this becomes dangerous mainly when paired with a widely deployed malicious extension campaign.
Conditions required:
  • The malicious extension has a useful post-bypass payload
  • Users continue running the extension long enough for abuse
Where this breaks in practice:
  • No evidence here of in-the-wild exploitation or KEV status
  • No direct internet-exposed attack surface to mass-scan and spray
Detection/coverage: Behavioral detections on risky extensions and admin-side extension inventory are more useful than perimeter scanning.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public in-the-wild evidence found from the supplied intel, and not KEV-listed in CISA's catalog (CISA KEV)
Proof-of-concept availabilityNo public PoC located during this review. The strongest technical breadcrumb is the Chromium branch fix "[Extensions] Don't allow message connections from sandboxed pages" in the 149 branch (Chromium log)
EPSS0.00017 from the user-supplied intel, which is effectively background noise for mass exploitation probability
KEV statusNo; no known CISA KEV entry as of this assessment (catalog)
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N = network-reachable in theory, but requires user interaction, has low integrity-only impact, and no scope change
Affected versionsChrome desktop prior to 149.0.7827.53; Canada Cyber Centre summarizes affected stable builds as before 149.0.7827.53/54 on Windows/Mac and before 149.0.7827.53 on Linux (advisory)
Fixed versions149.0.7827.53+ covers Linux and the early-stable Windows/macOS release line; Google's release note confirms 149.0.7827.53/.54 for Windows/Mac (Chrome Releases)
Exposure and scanabilityNot internet-scannable in the normal sense. This is a client-side browser/extension flaw, so Shodan/Censys/FOFA-style exposure data is not materially useful here; exposure is determined by fleet versioning and extension-install policy, not by open ports
Enterprise control surfaceChrome Enterprise can allowlist/blocklist extensions, block risky permissions, and force install approved extensions only (allow/block, Windows policy)
Researcher / reporting trailThe public breadcrumb is the Chromium fix and Google's June 2026 desktop release stream; researcher attribution was not identified in the reviewed public sources
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The single biggest severity suppressor is the attacker position requirement: this bug matters only after a user installs a malicious extension or the attacker already controls one. That makes the reachable population far smaller than the browser's install base and shifts this from a broad remote exploit to a constrained trust-boundary bypass inside an already suspicious execution context.

MEDIUM Root-cause mapping of the public Chromium fix to this CVE
HIGH Real-world severity downgrade driven by malicious-extension prerequisite

Why this verdict

  • Requires a malicious extension first: the attacker is not just sending packets at Chrome; they must land a hostile extension, which implies prior social engineering, unmanaged installs, or weak admin policy
  • Reachable population collapses fast in managed fleets: enterprises using ExtensionSettings, allowlists, or force-install-only models remove most of the practical attack surface
  • Impact is modest even on success: the published CVSS is integrity-only and user-interaction-dependent, with no stated confidentiality or availability impact and no evidence of host-level takeover
  • No exploitation pressure: no KEV listing, no public campaign evidence, and a near-zero EPSS keep this out of urgent patch-now territory

Why not higher?

A higher rating would require either broad pre-auth remote reach, active exploitation, or a blast radius that extends beyond the browser extension boundary. None of those are present here. Every meaningful path starts with a malicious extension install, which is exactly the kind of compounding prerequisite that should drag severity down for enterprise prioritization.

Why not lower?

This is still a real security boundary failure in one of the most widely deployed enterprise applications on the planet. If your environment allows permissive extension installs, the social-engineering hurdle is not hypothetical, and a malicious extension gaining extra reach is worth fixing rather than ignoring.

05 · Compensating Control

What to do — in priority order.

  1. Allowlist extensions only — Use Chrome Enterprise ExtensionSettings or Admin Console allow/block mode so users can install only approved extensions. For a LOW verdict there is no mitigation SLA; treat this as policy hygiene and fold it into your next browser-governance review rather than an emergency change.
  2. Block risky extension permissions — Use Chrome app/extension policy controls to block permissions your org does not need, especially broad webpage access and sensitive capabilities. This shrinks post-install blast radius even if a bad extension slips through; again, no mitigation SLA applies here, so do it in the normal hardening cycle.
  3. Inventory installed extensions — Pull the Chrome Apps & Extensions usage report and identify user-installed extensions, especially anything not force-installed by IT. This is the fastest way to find where the prerequisite for this CVE actually exists in your fleet.
  4. Restrict unmanaged browsers — The real exposure lives in unmanaged Chrome instances where users can self-install extensions. Push devices into Chrome management or enforce enterprise browser policy so the extension gate is closed by default.
What doesn't work
  • A WAF does not help; this is not a server-side web attack path against your perimeter apps
  • Network vulnerability scanning does not meaningfully measure exploitability here; at best it can find browser version data, not whether users can install malicious extensions
  • Email filtering alone is insufficient because the payload is an extension install decision, not necessarily a malicious attachment or exploit document
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tooling. Invoke it with python3 check_chrome_cve_2026_11267.py; it needs only normal user rights and checks common Chrome install locations on Windows, macOS, and Linux. It reports VULNERABLE, PATCHED, or UNKNOWN based on whether the detected Chrome version is before 149.0.7827.53.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11267.py
# Detect exposure to CVE-2026-11267 by checking local Google Chrome version.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

THRESHOLD = (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 run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_windows_version():
    candidates = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LOCALAPPDATA', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]
    for path in candidates:
        if path and os.path.exists(path):
            cmd = [
                'powershell', '-NoProfile', '-Command',
                f"(Get-Item '{path.replace("'", "''")}').VersionInfo.ProductVersion"
            ]
            out = run_cmd(cmd)
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


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 path in candidates:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


def get_linux_version():
    bins = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']
    for b in bins:
        exe = which(b)
        if exe:
            out = run_cmd([exe, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, exe
    return None, None


def main():
    system = platform.system().lower()
    version = None
    source = None

    if 'windows' in system:
        version, source = get_windows_version()
    elif 'darwin' in system:
        version, source = get_macos_version()
    elif 'linux' in system:
        version, source = get_linux_version()
    else:
        print('UNKNOWN - Unsupported OS')
        sys.exit(2)

    if not version:
        print('UNKNOWN - Google Chrome not found or version unreadable')
        sys.exit(2)

    version_str = '.'.join(str(x) for x in version)
    threshold_str = '.'.join(str(x) for x in THRESHOLD)

    if version < THRESHOLD:
        print(f'VULNERABLE - Detected Chrome {version_str} at {source}; fixed version is {threshold_str} or later')
        sys.exit(1)
    else:
        print(f'PATCHED - Detected Chrome {version_str} at {source}; meets fixed version threshold {threshold_str}')
        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 fleet fire drill. Use your browser inventory to find Chrome builds below 149.0.7827.53 and, more importantly, identify OUs where users can self-install extensions. For a LOW verdict, the noisgate mitigation SLA does not apply and there is no remediation SLA beyond backlog hygiene, so fold the browser update into your next normal evergreen rollout and use the same cycle to tighten extension allowlisting where it is still permissive.

Sources

  1. Chrome Releases: Early Stable Update for Desktop
  2. Chromium 149 branch log
  3. Canadian Centre for Cyber Security advisory AV26-544
  4. Chrome Enterprise: Allow or block apps and extensions
  5. Chrome Enterprise: View app and extension usage details
  6. Chrome Enterprise: Set Chrome app and extension policies (Windows)
  7. Google Online Security Blog: Staying Safe with Chrome Extensions
  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.