This is a fake contractor badge that only works after security already let the person into the building
CVE-2026-11190 is an *Extensions* access-control failure in Chrome desktop that lets a *malicious extension* overstep Chrome's intended boundaries after the user installs it. The fixed builds are Chrome 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS; anything older is in scope. One important cleanup point: the vendor release post labels this issue as insufficient policy enforcement in Extensions, while the title in your intel says inappropriate implementation. For defenders, the operational meaning is the same: a hostile extension can bypass an internal browser control once present.
Google's MEDIUM 6.5 is technically defensible in a lab, but too generous for enterprise prioritization. This is *not* unauthenticated remote exploitation from a web page; it requires the attacker to first convince a user to install a malicious extension, and many managed Chrome estates already suppress that with extension allowlisting, force-install, or store restrictions. In other words, the exploit chain starts after a major security control failure or a deliberately permissive browser policy, so the real-world reachable population is much smaller than the CVSS baseline implies.
3 steps from start to impact.
Land a malicious extension
- Attacker can deliver a malicious extension or store link
- Target users are allowed to install extensions or sideload them
- User interaction succeeds
- Many enterprises block arbitrary extension installs with
ExtensionSettings - Force-installed allowlisted extensions sharply reduce the attack surface
- Users still have to click through installation and permission prompts unless policy bypasses normal governance
Abuse the policy-enforcement flaw
- Victim is running Chrome before 149.0.7827.53
- The malicious extension reaches the vulnerable code path
- Attack value depends on what extra access the extension can obtain beyond its normal grant set
- Browser version roll-forward usually closes the window quickly in auto-updating estates
Operate inside the user's browser trust zone
- The target user meaningfully uses Chrome for enterprise workflows
- The extension remains enabled long enough to act
- Impact stays tied to the browser profile rather than the operating system
- Managed profile telemetry can expose the installed extension, version, and status
- Removing or disabling the extension cuts off the attacker even before patching
The supporting signals.
| In-the-wild status | No confirmed exploitation evidence found in the sources reviewed, and the CVE is not KEV-listed. That materially lowers urgency versus Chrome's true zero-days. |
|---|---|
| PoC availability | No public PoC located in the sources reviewed. That does not make it safe, but it does reduce copy-paste attacker access compared with heavily weaponized browser bugs. |
| EPSS | 0.00012 from your intel, which is extremely low. *Inference:* that places it in the extreme low tail of likely exploitation probability rather than the operator hot zone. |
| KEV status | Not listed in CISA KEV as of 2026-06-06. For Chrome issues, KEV absence usually means no public government-confirmed exploitation signal yet. |
| CVSS meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N says *network-reachable with user interaction and no prior privileges*, but that hides the decisive real-world prerequisite: the attacker must first get a malicious extension installed. |
| Affected versions | Chrome desktop before 149.0.7827.53. Google shipped fixes in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). |
| Fixed versions / backports | Primary fix is in Google Chrome stable 149.0.7827.53+. No downstream distro backport information was identified in the reviewed sources; if you run distro-packaged Chromium, verify the distro advisory separately. |
| Exposure and scanning reality | This is not an internet-facing service flaw, so Shodan/Censys/FOFA-style population counts are largely irrelevant. Exposure is driven by endpoint count, browser version lag, and whether users can install arbitrary extensions. |
| Disclosure | Published 2026-06-04; the Chrome stable channel release carrying the fix was announced 2026-06-02. |
| Reporter / attribution | The Chrome release notes attribute CVE-2026-11190 to Google and mark it as a Medium severity issue. Notably, the release post calls it insufficient policy enforcement in Extensions, which is the wording I would trust over secondary summaries. |
noisgate verdict.
The single biggest severity suppressor is that exploitation starts with getting a malicious extension installed, which is already a major control failure in a managed enterprise. This sharply narrows the exposed population compared with a normal browser RCE or drive-by web bug and keeps the blast radius centered on the browser profile, not direct host compromise.
Why this verdict
- Baseline starts at vendor MEDIUM 6.5, then drops hard because this is not drive-by exploitable; the attacker needs user interaction *and* a successful malicious extension install first.
- Enterprise exposure is much smaller than Chrome's install base because modern managed deployments commonly use
ExtensionSettings, allowlists, force-install, or store restrictions that prevent arbitrary CRX installation. - The prerequisite implies post-control-failure abuse, not clean initial access. Requiring an already-installed malicious extension compounds downward pressure on severity even if the in-browser integrity impact is real.
Why not higher?
This is not the kind of Chrome bug that turns any page view into compromise. There is no evidence here of zero-click exploitation, KEV listing, or host-level escape; the attacker must first land a malicious extension and then exploit a browser-internal trust failure.
Why not lower?
It is still a real security-boundary failure in one of the most widely deployed enterprise applications on the planet. In permissive or lightly managed fleets where users can install extensions freely, a phishing campaign or fake store listing could abuse this at scale against the browser profile.
What to do — in priority order.
- Lock down extension installs — Use Chrome Enterprise
ExtensionSettingsto default-deny unapproved extensions and explicitly allow or force-install only sanctioned ones. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene, but if your extension governance is currently open, close that gap in the normal hardening cycle because it removes the exploit's main prerequisite. - Turn on browser and profile reporting — Enable Chrome managed browser and managed profile reporting so you can query browser versions and installed extension inventories centrally. For a LOW verdict there is no mitigation SLA; do this through the next normal admin change window because it improves both this case and every future extension-borne incident.
- Hunt for non-admin extensions — Review managed profile inventories for extensions with
install typeother than admin-controlled and investigate anything unexpected. For a LOW verdict there is no mitigation SLA; fold it into routine browser hygiene unless you already suspect extension abuse. - Preserve auto-update defaults — Keep Chrome auto-updates enabled and avoid version pinning beyond what your testing program truly requires, so minor security fixes like 149.0.7827.53 land without manual intervention. For a LOW verdict there is no mitigation SLA; this is steady-state operational discipline rather than emergency action.
- A perimeter WAF does nothing here because the exploit lives in the local browser extension subsystem, not a server-side web app.
- Email filtering helps only at the delivery edge; it does not stop users from installing a malicious extension from other channels or direct store links.
- Relying on CVSS alone does not prioritize this correctly because the score underweights the real-world prerequisite of malicious extension installation.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tool to check the locally installed Chrome/Chromium version. Example: python3 check_chrome_cve_2026_11190.py; it needs no admin rights for standard paths and registry reads, though broader file-system visibility helps on locked-down hosts.
#!/usr/bin/env python3
# check_chrome_cve_2026_11190.py
# Detects whether the local Chrome/Chromium installation is vulnerable to CVE-2026-11190.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
PATCHED_MIN = (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 ver_to_str(v):
return '.'.join(str(x) for x in v)
def compare(v1, v2):
return (v1 > v2) - (v1 < v2)
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=5)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_windows_versions():
findings = []
try:
import winreg
except Exception:
return findings
reg_paths = [
(winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon', 'version', 'Chrome HKCU'),
(winreg.HKEY_LOCAL_MACHINE, r'Software\Google\Chrome\BLBeacon', 'version', 'Chrome HKLM'),
(winreg.HKEY_CURRENT_USER, r'Software\Chromium\BLBeacon', 'version', 'Chromium HKCU'),
(winreg.HKEY_LOCAL_MACHINE, r'Software\Chromium\BLBeacon', 'version', 'Chromium HKLM'),
(winreg.HKEY_LOCAL_MACHINE, r'Software\WOW6432Node\Google\Chrome\BLBeacon', 'version', 'Chrome WOW6432Node'),
(winreg.HKEY_LOCAL_MACHINE, r'Software\WOW6432Node\Chromium\BLBeacon', 'version', 'Chromium WOW6432Node'),
]
for hive, path, value_name, label in reg_paths:
try:
key = winreg.OpenKey(hive, path)
value, _ = winreg.QueryValueEx(key, value_name)
v = parse_version(str(value))
if v:
findings.append((label, v))
except Exception:
pass
return findings
def get_macos_versions():
findings = []
apps = [
('Google Chrome', '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
('Chromium', '/Applications/Chromium.app/Contents/MacOS/Chromium'),
]
for label, path in apps:
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
findings.append((label, v))
return findings
def get_linux_versions():
findings = []
candidates = [
('google-chrome', ['google-chrome', '--version']),
('google-chrome-stable', ['google-chrome-stable', '--version']),
('chromium', ['chromium', '--version']),
('chromium-browser', ['chromium-browser', '--version']),
('chrome', ['chrome', '--version']),
]
for label, cmd in candidates:
out = run_cmd(cmd)
v = parse_version(out)
if v:
findings.append((label, v))
return findings
def main():
system = platform.system().lower()
findings = []
if 'windows' in system:
findings = get_windows_versions()
elif 'darwin' in system:
findings = get_macos_versions()
else:
findings = get_linux_versions()
if not findings:
print('UNKNOWN - No Chrome/Chromium version found')
sys.exit(2)
vulnerable = []
patched = []
for label, version in findings:
if compare(version, PATCHED_MIN) < 0:
vulnerable.append((label, version))
else:
patched.append((label, version))
for label, version in findings:
status = 'VULNERABLE' if compare(version, PATCHED_MIN) < 0 else 'PATCHED'
print(f'{status} - {label} {ver_to_str(version)}')
if vulnerable:
worst = ', '.join(f'{label} {ver_to_str(version)}' for label, version in vulnerable)
print(f'VERDICT: VULNERABLE - Found version(s) older than {ver_to_str(PATCHED_MIN)}: {worst}')
sys.exit(1)
best = ', '.join(f'{label} {ver_to_str(version)}' for label, version in patched)
print(f'VERDICT: PATCHED - All discovered version(s) are >= {ver_to_str(PATCHED_MIN)}: {best}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
- Canadian Centre for Cyber Security advisory AV26-544
- Chrome Enterprise: Configure the ExtensionSettings policy
- Chrome Enterprise: View Chrome version details
- Chrome Enterprise: View Chrome browser profile details
- Chrome Enterprise: Manage Chrome updates
- FIRST EPSS documentation
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.