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

Insufficient policy enforcement in DevTools in Google Chrome prior to 149

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

Like a thief who still needs you to hand over the master key before the side door matters

CVE-2026-11212 is an improper access-control flaw in Chrome DevTools policy enforcement. In Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS, an attacker can use a crafted malicious Chrome extension to leak cross-origin data after the user installs that extension. The affected population is broad in theory because Chrome is everywhere, but the vulnerable path is narrow in practice because the bug does not give an unauthenticated website direct reach into the browser.

Google's Medium 4.3 label is fair in lab conditions, but for enterprise patch triage it overstates urgency. The decisive friction is that the attacker must first convince the user to install a malicious extension, which is already a meaningful compromise step and one that well-run enterprise Chrome fleets often blunt with allowlists, blocklists, and forced-install policies. This is real, patchable, and worth rolling up in normal browser currency management, but it is not the thing that should jump ahead of remotely reachable server-side bugs or true browser drive-by RCEs.

"This is a browser-policy paper cut, not a fleet-wide fire: it needs a malicious extension first."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a malicious extension

The attacker needs the user to install a crafted Chrome extension. That is the real initial access event here: without extension installation, the vulnerability is inert. The likely weapon is a fake productivity, developer, or AI helper extension delivered through phishing, sideloading, or an abused store listing.
Conditions required:
  • User can install extensions or accepts an extension update
  • Enterprise policy does not fully block unapproved extensions
  • Attacker can socially engineer or otherwise distribute the extension
Where this breaks in practice:
  • Managed Chrome fleets commonly use ExtensionInstallBlocklist, ExtensionInstallAllowlist, or ExtensionSettings
  • Extension install/update flows can show permission warnings
  • Security teams already treat rogue extensions as a separate control problem
Detection/coverage: Traditional network and vuln scanners will miss this path. Browser management telemetry, extension inventory, and Chrome policy compliance checks are the useful controls.
STEP 02

Obtain debugging-style extension capability

The crafted extension likely relies on privileged extension APIs associated with DevTools-style instrumentation, especially the chrome.debugger transport to the Chrome DevTools Protocol. That API is powerful enough to inspect network interaction and page state, which is why Chrome documents it as a warning-triggering permission.
Conditions required:
  • Extension manifest requests the needed permissions
  • User accepts the permission prompt or the extension is already trusted/installed
Where this breaks in practice:
  • The debugger permission is unusual and suspicious in ordinary business extensions
  • Permission reviews, store vetting, and enterprise extension governance reduce reach
Detection/coverage: Look for installed extensions with sensitive permissions such as debugger, broad host access, or tabs. Chrome admin consoles and endpoint extension inventories can surface this.
STEP 03

Exploit the DevTools policy gap

Once installed, the extension abuses the DevTools policy-enforcement flaw to bypass intended restrictions and expose cross-origin data that should remain segregated. The impact described by the vendor is information disclosure, not code execution, sandbox escape, or broad integrity loss.
Conditions required:
  • Victim browses to or is already authenticated to sites holding interesting data
  • The extension can attach to relevant tabs or contexts
Where this breaks in practice:
  • The attacker still depends on the victim having valuable session state in the browser
  • Confidentiality impact is limited compared with full browser compromise
Detection/coverage: No reliable off-the-shelf signature for the CVE itself. Detection is mostly indirect: suspicious extension behavior, anomalous browser API use, or extension governance exceptions.
STEP 04

Exfiltrate stolen cross-origin data

After the leak, the extension can transmit harvested data to attacker infrastructure using normal extension networking. The blast radius is typically the user's browser context and active sessions, not arbitrary code execution across the endpoint.
Conditions required:
  • Outbound network from the browser is allowed
  • Captured data is useful enough to monetize or chain
Where this breaks in practice:
  • DLP, CASB, proxy controls, and extension reviews may catch noisy exfiltration
  • The attacker gains low-to-moderate data value unless they already targeted privileged users
Detection/coverage: Proxy logs, DLP events, and extension-to-domain egress patterns may help. Vulnerability scanners provide essentially no direct coverage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo verified in-the-wild exploitation found in the sources reviewed. As of 2026-06-06, CISA KEV does not list CVE-2026-11212.
Proof-of-concept availabilityNo public PoC located in the reviewed search results. The Chromium issue exists, but details are restricted; practical reproduction would likely center on a crafted extension using DevTools-related APIs.
EPSS0.00013 per the user-supplied intel; that is extremely low. I could verify FIRST's API/documentation, but not independently pull this CVE's live percentile in-browser during this session.
KEV statusNot KEV-listed. No CISA due date applies.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N = remote delivery path, user interaction required, confidentiality-only impact, no integrity or availability hit. That already tells you this is not a drive-by RCE.
Affected versionsGoogle Chrome prior to 149.0.7827.53; release notes show 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac) as fixed stable builds.
Fixed versionsUpgrade to Chrome 149.0.7827.53 or later on Linux, and 149.0.7827.53/54 or later on Windows/macOS. I did not find vendor guidance for distro-style backports here; this is a browser-version upgrade story, not a package-level backport story.
Scanning / exposure realityNo meaningful Shodan/Censys-style external exposure metric applies because Chrome is client software, not a listening enterprise service. Real exposure is your extension install posture and the number of users allowed to add unapproved extensions.
Disclosure timelineChrome published the stable fix on 2026-06-02; the CVE record was published on 2026-06-04; NVD shows the entry on 2026-06-04 with CISA-ADP enrichment on 2026-06-05.
Reporting researcher / orgThe stable release notes attribute this one to Google, reported on 2026-04-28 via Chromium issue 507216833.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.7/10)

The single biggest downgrader is the attacker position requirement: they need a malicious extension installed first. In a managed enterprise, that shifts this from a raw browser bug to a policy-governance edge case with a much narrower reachable population and a blast radius mostly confined to the victim's browser data.

HIGH Affected/fixed version mapping from Google release notes and NVD
MEDIUM Real-world severity downgrade based on enterprise extension-governance friction
MEDIUM No-public-PoC / no-known-exploitation assessment from reviewed sources

Why this verdict

  • Requires prior foothold in the browser trust boundary: the attacker must get a user to install a malicious extension before the CVE matters.
  • Exposure is policy-dependent, not internet-wide: if you already restrict extension installs, the reachable population collapses hard.
  • Impact is confidentiality-only and modest: vendor vector shows low confidentiality impact with no integrity or availability damage.
  • No exploitation signal: not KEV-listed, no public PoC found, and the provided EPSS is extremely low.
  • Modern enterprise tools should stop step 1: extension allowlists, blocklists, browser management, and user-install restrictions are exactly the right brakes here.

Why not higher?

This is not unauthenticated remote code execution, not a renderer escape, and not a no-click web attack. The full chain assumes user action plus extension installation plus useful session data in the browser, which is too much compounded friction to justify MEDIUM-or-higher patch urgency in a 10,000-host queue.

Why not lower?

I am not calling it IGNORE because Chrome is ubiquitous and a successful malicious extension can still harvest sensitive cross-origin data from real business sessions. If your fleet allows broad extension self-service, the reachable population is non-trivial enough that you still want this fixed as part of browser hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Block unapproved extensions — Set ExtensionInstallBlocklist to * and use ExtensionInstallAllowlist or ExtensionSettings for approved IDs. For a LOW verdict there is no mitigation SLA, so use this where governance is weak and fold it into backlog hardening rather than emergency change.
  2. Inventory risky extension permissions — Hunt for extensions requesting debugger, broad host permissions, or unusual tab/network access. Prioritize privileged users and developer workstations; this is the fastest way to find the prerequisite that makes the CVE exploitable.
  3. Restrict developer tooling where business-safe — Use DeveloperToolsAvailability, DeveloperToolsAvailabilityBlocklist, and related policies to narrow where DevTools can be used. This will not fully replace patching, but it reduces abuse paths in managed environments and can be rolled into normal policy maintenance.
  4. Tighten extension exception workflow — Require approval for new extension IDs and review permission prompts during exceptions. The CVE's whole attack path depends on winning this trust decision first.
What doesn't work
  • A WAF does not help; this is a local browser/extension abuse path, not an inbound web application attack surface.
  • Server patching on the websites users visit does not help; the weakness sits in the client browser's DevTools policy enforcement.
  • Generic perimeter scanning does not help; there is no meaningful exposed service to fingerprint for this client-side issue.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software inventory/remote execution platform, not from a scanner box. Invoke it as python3 check_chrome_cve_2026_11212.py or pass an explicit binary path like python3 check_chrome_cve_2026_11212.py "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; it needs only normal user read/execute rights on the Chrome binary.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11212.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

FIXED = (149, 0, 7827, 53)

def parse_ver(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s)
    return tuple(int(x) for x in m.groups()) if m else None

def cmp_ver(a, b):
    return (a > b) - (a < b)

def candidate_paths():
    system = platform.system()
    paths = []

    if len(sys.argv) > 1:
        paths.append(sys.argv[1])

    if system == 'Windows':
        envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
        suffixes = [
            r'Google\\Chrome\\Application\\chrome.exe',
            r'Chromium\\Application\\chrome.exe'
        ]
        for base in envs:
            if base:
                for suffix in suffixes:
                    paths.append(os.path.join(base, suffix))
    elif system == 'Darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            '/Applications/Chromium.app/Contents/MacOS/Chromium'
        ])
        for name in ['Google Chrome', 'Chromium']:
            which = shutil.which(name)
            if which:
                paths.append(which)
    else:
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
            '/snap/bin/chromium'
        ])
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            which = shutil.which(name)
            if which:
                paths.append(which)

    # de-dup while preserving order
    seen = set()
    out = []
    for p in paths:
        if p and p not in seen:
            seen.add(p)
            out.append(p)
    return out

def get_version(binary):
    try:
        proc = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=10)
        text = (proc.stdout or '') + ' ' + (proc.stderr or '')
        return parse_ver(text.strip())
    except Exception:
        return None

def main():
    found = []
    for p in candidate_paths():
        if os.path.exists(p):
            ver = get_version(p)
            found.append((p, ver))

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

    # Prefer Google Chrome if present; otherwise evaluate all discovered binaries.
    for p, ver in found:
        if ver is None:
            continue
        if cmp_ver(ver, FIXED) < 0:
            print(f'VULNERABLE - {p} version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} is below 149.0.7827.53')
            sys.exit(1)

    for p, ver in found:
        if ver is not None:
            print(f'PATCHED - {p} version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} is at or above 149.0.7827.53')
            sys.exit(0)

    print('UNKNOWN - Binary found but version could not be determined')
    sys.exit(2)

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

If you remember one thing.

TL;DR
Monday morning: treat this as normal Chrome currency work, not a fire drill. Because the reassessed verdict is LOW, there is no noisgate mitigation SLA and no emergency compensating-control deadline unless you already know users can freely install unapproved extensions; in that case, tighten extension governance as routine hardening. For remediation, use the noisgate remediation SLA for LOW issues: handle it as backlog hygiene and roll endpoints to Chrome 149.0.7827.53+ / 149.0.7827.54+ in your standard browser update cadence, while separately auditing extension-install policy because that prerequisite is the real risk multiplier here.

Sources

  1. NVD CVE-2026-11212
  2. Chrome stable channel update for desktop (2026-06-02)
  3. Chrome early stable update for desktop (2026-05-29)
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. Chrome extension permission warning guidelines
  7. Chrome debugger API reference
  8. Chrome Enterprise extension allowlist policy
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.