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.
4 steps from start to impact.
Land a malicious extension
- 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
- Managed Chrome fleets commonly use
ExtensionInstallBlocklist,ExtensionInstallAllowlist, orExtensionSettings - Extension install/update flows can show permission warnings
- Security teams already treat rogue extensions as a separate control problem
Obtain debugging-style extension capability
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.- Extension manifest requests the needed permissions
- User accepts the permission prompt or the extension is already trusted/installed
- The
debuggerpermission is unusual and suspicious in ordinary business extensions - Permission reviews, store vetting, and enterprise extension governance reduce reach
debugger, broad host access, or tabs. Chrome admin consoles and endpoint extension inventories can surface this.Exploit the DevTools policy gap
- Victim browses to or is already authenticated to sites holding interesting data
- The extension can attach to relevant tabs or contexts
- The attacker still depends on the victim having valuable session state in the browser
- Confidentiality impact is limited compared with full browser compromise
Exfiltrate stolen cross-origin data
- Outbound network from the browser is allowed
- Captured data is useful enough to monetize or chain
- 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
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | 0.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 status | Not KEV-listed. No CISA due date applies. |
| CVSS vector readout | CVSS: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 versions | Google 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 versions | Upgrade 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 reality | No 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 timeline | Chrome 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 / org | The stable release notes attribute this one to Google, reported on 2026-04-28 via Chromium issue 507216833. |
noisgate verdict.
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.
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.
What to do — in priority order.
- Block unapproved extensions — Set
ExtensionInstallBlocklistto*and useExtensionInstallAllowlistorExtensionSettingsfor 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. - 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. - 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. - 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.
- 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.
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.
#!/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()
If you remember one thing.
Sources
- NVD CVE-2026-11212
- Chrome stable channel update for desktop (2026-06-02)
- Chrome early stable update for desktop (2026-05-29)
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Chrome extension permission warning guidelines
- Chrome debugger API reference
- Chrome Enterprise extension allowlist policy
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.