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.
4 steps from start to impact.
Land a malicious extension
- 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
- 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
Abuse the DevTools policy gap
- The malicious extension is running in the victim profile
- The vulnerable DevTools code path is reachable in that browser context
- 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
Read authenticated cross-origin data
- Victim has interesting authenticated sessions open
- The targeted web content is reachable from the victim device
- 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
Exfiltrate to attacker infrastructure
- Outbound network access from the browser is allowed
- The extension can contact attacker-controlled infrastructure
- 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
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. |
noisgate verdict.
The single biggest downward pressure is the malicious-extension prerequisite: the attacker needs a user to install browser code first, which means this is not a silent web exploit against your fleet. Once that friction is applied, the remaining impact is mainly per-user data leakage from active sessions rather than enterprise-wide takeover.
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.
What to do — in priority order.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
CVE-2026-11092. Then treat this as managed-browser hygiene: verify extension governance, hunt for unapproved extension installs, and roll Chrome 149.0.7827.53+ through the normal browser update train. Because this is MEDIUM and there is no KEV or exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; under the noisgate remediation SLA, complete patching within 365 days, but most mature fleets should fold it into the next scheduled browser rollout rather than letting it sit.Sources
- NVD - CVE-2026-11212
- Chrome stable channel update for desktop - June 2 2026
- Chrome early stable updates label
- GitHub Advisory Database - GHSA-3cxh-6mgp-qvhv
- Chrome Enterprise policy - DeveloperToolsAvailability
- Chrome Enterprise Help - Allow or block apps and extensions
- CISA Known Exploited Vulnerabilities Catalog
- Chrowned by an Extension: Abusing the Chrome DevTools Protocol through the Debugger API
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.