CVE-2026-11092 · Google Chrome DevTools policy bypass lets a malicious extension leak…

01 · The Real Story

This is a fake contractor badge that only matters after someone is already inside the building

The authoritative public record does not support the user-supplied 8.8/HIGH story. The description you provided maps to CVE-2026-11212, not CVE-2026-11092: Google says Chrome before 149.0.7827.53 let a malicious Chrome extension abuse a DevTools policy gap to leak cross-origin data. A separate CVE, CVE-2026-11092, is also a DevTools policy-enforcement bug in Chrome 149, but the full public description, CVSS, and EPSS you supplied belong to CVE-2026-11212.

In real enterprise conditions this lands MEDIUM, not HIGH. The decisive friction is that the attacker must first get a user to install a malicious extension; that is already a distinct compromise step that good browser policy, extension allowlisting, Safe Browsing, store controls, and user privilege limits should suppress. The impact is also narrower than a code-exec bug: the public scoring for the matching record is 4.3 / MEDIUM with confidentiality-only impact, no integrity or availability loss.

"This is a malicious-extension assist, not a drive-by RCE; keep it in browser hygiene, not break-glass patching"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a malicious extension

The attacker needs a user to install a crafted Chrome extension, likely via phishing, fake productivity tooling, or sideloading-style social engineering. The extension is the weaponized delivery mechanism; without it, the vulnerability is inert.

Conditions required:

Target is running Chrome below 149.0.7827.53
User can install extensions or attacker can abuse an allowed install path
User is tricked into installing the extension

Where this breaks in practice:

Enterprise extension allowlists/blocklists kill a lot of this population
Managed browsers often restrict extension installation
Phishing the user into installing a browser add-on is materially harder than a silent web exploit

Detection/coverage: Good EDR/browser telemetry and Chrome Enterprise policy reporting can flag new extension installs, non-approved extension IDs, and force-installed vs user-installed drift.

STEP 02

Abuse the DevTools policy gap

Once installed, the crafted extension abuses the DevTools policy-enforcement flaw to reach across origin boundaries it should not access. The public bug details remain restricted, so the exact primitive is inferred from the advisory text and adjacent DevTools/Debugger research, but the end state is a cross-origin read capability beyond intended policy.

Conditions required:

The malicious extension is running in the victim profile
The vulnerable DevTools code path is reachable in that browser context

Where this breaks in practice:

No public CVE-specific PoC was located
Restricted Chromium bug details slow opportunistic weaponization
The bug appears to be a policy bypass, not a memory-corruption primitive

Detection/coverage: Signature-based vuln scanners can identify vulnerable Chrome versions, but they generally cannot prove exploitability of the restricted DevTools path.

STEP 03

Read authenticated cross-origin data

If the victim is logged into corporate SaaS or internal web apps, the extension can potentially read data from those sessions and stage it for theft. This is a confidentiality problem centered on the active user profile, not a host takeover or browser escape.

Conditions required:

Victim has interesting authenticated sessions open
The targeted web content is reachable from the victim device

Where this breaks in practice:

Blast radius is per-user and per-profile
No server compromise occurs; the attacker only sees what that user session can reach
Some sensitive apps may have additional client controls that limit useful data exposure

Detection/coverage: Watch for unusual extension-origin requests, unexpected data egress from browser processes, and browser access to high-value SaaS shortly before outbound exfil.

STEP 04

Exfiltrate to attacker infrastructure

The extension ships the collected data out over normal browser networking, blending into standard HTTPS traffic. At that point the vulnerability has amplified a bad extension into a better data thief.

Conditions required:

Outbound network access from the browser is allowed
The extension can contact attacker-controlled infrastructure

Where this breaks in practice:

Egress filtering, SWG/CASB controls, and domain reputation can still break the chain
Extension telemetry or DLP may catch high-volume or suspicious outbound transfers

Detection/coverage: Proxy/SWG logs, browser extension inventory, and DLP around browser processes are more useful than perimeter exposure scanners here.

03 · Compensating Control

Block unmanaged extensions — Use Chrome Enterprise ExtensionSettings / ExtensionInstallBlocklist controls to stop arbitrary add-on installs and disable already-blocklisted extensions. For a MEDIUM verdict there is no noisgate mitigation SLA; this is still the best control to apply first because it removes the exploit precondition.

Restrict DevTools where business allows — Use DeveloperToolsAvailability to reduce DevTools exposure on managed browsers, especially high-risk user groups and kiosk/shared profiles. This will not replace patching, but it reduces the attack surface while you roll browser updates.

Inventory and hunt extension drift — Pull extension IDs from managed-browser telemetry and compare against your approved set; investigate newly installed, unapproved, or recently enabled extensions. This is the fastest way to find users who could actually traverse the exploit chain.

Watch browser egress from sensitive users — Apply SWG/CASB/DLP focus to browser-origin outbound traffic for admins, finance, engineering, and other SaaS-heavy roles. The likely impact here is session-adjacent data theft, so egress monitoring gives you a practical backstop.

Roll Chrome to 149.0.7827.53+ — Standardize browser rollout to 149.0.7827.53 or later across Windows, macOS, Linux, and aligned Android channels. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but most orgs should finish this in the next normal browser release cadence, not let it age.

What doesn't work

A WAF does not solve this; the exploit lives in the client browser and malicious extension context, not your web edge.
Perimeter internet exposure scanning does not help much; browser version exposure is an endpoint inventory problem, not a Shodan problem.
Server-side app hardening alone is insufficient; once a malicious extension can read in-browser data, CSP and origin policy on the server side are not the main choke points.

04 · Intelligence Metadata

The supporting signals.

Record correction	The supplied narrative matches CVE-2026-11212, while Chrome 149's fix list shows `CVE-2026-11092` as a different DevTools policy-enforcement issue.
In-the-wild status	No public evidence of active exploitation found; not present in CISA's Known Exploited Vulnerabilities Catalog as of 2026-06-06.
PoC availability	No CVE-specific public PoC or exploit repo located. Adjacent academic work on Chrome extension abuse of DevTools/Debugger APIs exists in Chrowned by an Extension, which makes the class plausible but not turnkey.
EPSS	0.00008 (0.008%), roughly 1st percentile, as reflected in the GitHub advisory and sourced from FIRST.
KEV status	No KEV listing. No addition date because it is absent from the CISA catalog.
CVSS and what it means	CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N = 4.3/MEDIUM on the authoritative matching record: network reachable in theory, but user interaction is required and impact is confidentiality-only.
Affected versions	Chrome before 149.0.7827.53 on desktop channels; Android stable notes say Android carries the same desktop fixes unless noted otherwise in the stable release post.
Fixed versions	Desktop stable moved to 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac) in the stable update; early rollout started in the early stable release stream.
Scanning / exposure data	This is a client-side browser flaw, so Shodan/Censys/GreyNoise style external-exposure counts are largely not meaningful. You cannot internet-scan your way to browser version coverage; asset inventory and browser management telemetry matter more.
Disclosure / reporter	Public disclosure was 2026-06-04 in the CVE/NVD flow; Chrome's stable post credits the matching record to Google, reported on 2026-04-28 in the fix list.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (4.1/10)

Why this verdict

Authoritative baseline is already lower: the matching public record is 4.3/MEDIUM, not the user-supplied 8.8/HIGH.
Attacker position is post-social-engineering: exploitation requires a user-installed malicious extension, which implies the attacker has already won a meaningful initial foothold in the browser.
Reachable population is narrowed by policy: enterprises that enforce extension allowlists/blocklists or managed-browser controls cut exposure sharply compared with consumer Chrome.
Blast radius is user-session scoped: public scoring shows confidentiality loss only, with no integrity or availability impact and no host-level code execution.

Why not higher?

This is not unauthenticated drive-by code execution, and it is not a server-side remotely reachable service you can scan from the internet. The exploit chain depends on extension installation, which compounds friction and limits the affected population to users who can be socially engineered or whose browser policy is weak.

Why not lower?

It is still a browser-wide issue in an extremely common application, and the data at risk may include authenticated enterprise SaaS content. If your extension governance is loose, this bug can turn a commodity malicious extension into a more capable cross-origin data thief, so it is not something to ignore outright.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet management tool with normal user rights; admin is not required unless your environment blocks access to the browser binary. Example: python3 check_chrome_cve_2026_11212.py on macOS/Linux or py check_chrome_cve_2026_11212.py on Windows. It checks installed Chrome/Chromium version only and reports VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3
# check_chrome_cve_2026_11212.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

import os
import platform
import re
import subprocess
import sys
from typing import Optional, Tuple

THRESHOLD = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


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


def get_windows_version() -> Optional[Tuple[int, int, int, int]]:
    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'),
        os.path.expandvars(r'%ProgramFiles%\Chromium\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Chromium\Application\chrome.exe'),
    ]
    for path in candidates:
        if os.path.exists(path):
            ps = [
                'powershell', '-NoProfile', '-Command',
                f"(Get-Item '{path}').VersionInfo.ProductVersion"
            ]
            out = run_cmd(ps)
            ver = parse_version(out)
            if ver:
                return ver
    return None


def get_macos_version() -> Optional[Tuple[int, int, int, int]]:
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ]
    for path in candidates:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver
    return None


def get_linux_version() -> Optional[Tuple[int, int, int, int]]:
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium', '--version'],
        ['chromium-browser', '--version'],
        ['/opt/google/chrome/chrome', '--version'],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver
    return None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        ver = get_windows_version()
    elif 'darwin' in system:
        ver = get_macos_version()
    elif 'linux' in system:
        ver = get_linux_version()
    else:
        print('UNKNOWN - unsupported platform')
        sys.exit(2)

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

    version_str = '.'.join(str(x) for x in ver)
    if ver < THRESHOLD:
        print(f'VULNERABLE - installed version {version_str} is below 149.0.7827.53')
        sys.exit(1)
    else:
        print(f'PATCHED - installed version {version_str} is at or above 149.0.7827.53')
        sys.exit(0)


if __name__ == '__main__':
    main()