This is not a burglar kicking in the front door, it is a fake contractor getting a badge and then wandering past an internal rope line
CVE-2026-11014 is an Extensions policy-enforcement flaw in Google Chrome affecting versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS, per Google's June 2026 desktop stable update advisory. The public description available in the prompt and indexed feeds is incomplete, but the authoritative record consistently places it in the Extensions component and requires the attacker to convince a user to install a malicious extension before the bug matters.
paragraph 2 vendor severity does not exist here, so the right move is a ground-up assessment. In real fleets this is much lower risk than a normal Chrome RCE because it is not reachable by simply browsing to a page; it depends on a successful malicious-extension install, and in mature enterprises extension allowlisting, store restrictions, and user friction cut the reachable population hard. The bug still matters because Chrome is ubiquitous and extension-boundary failures can expose browser-resident data or permissions, but this is a narrow, post-social-engineering abuse path, not an internet-edge patch-now event.
3 steps from start to impact.
Land a malicious extension
crx or Chrome Web Store listing referenced by the attacker; the public CVE text itself says the attacker must convince the user to install it.- User can install extensions at all
- User accepts the extension prompt or sideload path
- Enterprise policy does not block the extension or installation source
- Many enterprise Chrome deployments use force-install or allowlists only
- Chrome Web Store trust prompts and permission prompts add user friction
- Security teams often block developer mode, sideloading, and off-store installs
Trigger the Extensions policy bypass
- Victim is running a vulnerable Chrome build
- The extension code reaches the affected API or policy path
- The extension's intended permissions are insufficient without exploiting the flaw
- If the attacker already got a powerful extension installed, the incremental value of the CVE may be modest
- Modern extension permission models, store review, and enterprise policy narrow the reachable set
- Some exploit paths may fail if the target user profile has restricted extension capabilities
Abuse the extra capability
- User profile contains valuable browser data or sessions
- The target workflows are actually used in that browser profile
- No compensating extension restrictions stop the follow-on action
- Blast radius is usually the current user profile, not remote code execution across the host
- No evidence found of in-the-wild exploitation or commodity tooling
- Enterprise session protections and conditional access can reduce downstream value
The supporting signals.
| In-the-wild status | No active exploitation signal found in the sources reviewed; not in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC located in the sources reviewed. Public Chromium issue references exist for related Chrome extension-boundary bugs, but I did not find a weaponized repo or exploit kit for this CVE. |
| EPSS | 0.00008 from the user-provided intel block, which is effectively negligible; percentile was not surfaced in the authoritative sources I could access. |
| KEV status | No. CISA's KEV catalog does not list CVE-2026-11014 as of 2026-06-05. |
| CVSS baseline | No vendor or authority CVSS exists for this CVE. *Inference from comparable Chrome extension-policy bugs:* similar cases have landed around 4.2-4.3 / Medium in downstream enrichment, but this CVE itself has no official baseline score. |
| Affected versions | Chrome before 149.0.7827.53 on Linux; Google's desktop advisory lists 149.0.7827.53/54 for Windows/macOS stable updates. |
| Fixed versions | 149.0.7827.53 or later on Linux; 149.0.7827.53/54 or later on Windows/macOS, depending on platform build. |
| Exposure reality | Not meaningfully internet-enumerable with Shodan/Censys because this is a client-side browser/extension logic flaw, not a server-side listening service. *Inference:* exposure is governed by extension installation freedom and browser patch lag, not by network perimeter reachability. |
| Disclosure date | 2026-06-04. |
| Reporter / researcher | Not publicly attributed in the sources I could verify. |
noisgate verdict.
The decisive factor is the attacker position requirement: exploitation starts only after the attacker gets a user to install a malicious extension, which is a major real-world filter in managed Chrome fleets. That prerequisite makes this a narrow post-social-engineering abuse path with limited reachable population, despite Chrome's massive footprint.
Why this verdict
- Downward pressure: requires malicious extension install first — attacker position is neither unauthenticated remote nor normal browsing; they must win a user-consent/social-engineering step that many enterprise Chrome policies block outright.
- Downward pressure: reachable population is much smaller than 'all Chrome users' — only tenants that allow user-installed extensions, sideloading, or weak extension governance are plausibly exposed.
- Downward pressure: this is incremental abuse, not initial host compromise — the attacker already has extension code executing in the browser, so the CVE amplifies that foothold instead of creating a clean drive-by path.
- Downward pressure: weak threat-intel signal — no KEV listing, no public exploitation evidence found, and the provided EPSS of 0.00008 is near floor.
- Upward pressure: Chrome is everywhere — if you do permit user-installed extensions, one bug in the extension trust boundary can still reach a large number of endpoints and sensitive browser sessions.
Why not higher?
This is not a webpage-only exploit, not an unauthenticated remote code execution path, and not a practical internet-edge issue. The chain begins with a malicious extension install, which implies either failed user judgment or weak enterprise extension governance before the CVE adds value.
Why not lower?
It is not IGNORE because Chrome is ubiquitous and browser sessions are high-value targets in large enterprises. If even a subset of your fleet allows user-installed extensions, this kind of boundary failure can still expose internal app sessions, browser data, or trusted UI flows.
What to do — in priority order.
- Enforce extension allowlisting — Restrict Chrome to approved extension IDs using enterprise policy and disable off-store installs. For a LOW verdict there is no formal mitigation SLA; treat this as backlog hygiene and fold it into your normal browser-governance cycle.
- Block developer mode and sideloading — Shut off the easiest non-store delivery paths for malicious
crxpackages and unpacked extensions. This directly attacks the highest-friction prerequisite in the chain; again, no SLA for LOW, but do it as standard hardening. - Audit high-risk extension permissions — Review extensions requesting broad host access,
debugger, clipboard, cookies, tabs, downloads, or identity permissions. Where possible, remove or replace them in the next governance review because a policy-bypass bug is more dangerous when the starting extension set is already over-permissioned. - Turn on browser and extension telemetry — Use Chrome enterprise reporting, EDR browser telemetry, and software inventory to alert on newly installed extension IDs and unmanaged installs. This helps you catch the prerequisite event that traditional network tools will miss.
- A WAF or reverse proxy does not help; this is not an inbound web-app attack against your servers.
- Perimeter vulnerability scanning will not tell you who is about to install a malicious extension; at best it identifies outdated Chrome versions.
- Email filtering alone is insufficient because the social-engineering lure can arrive through chat, docs, ads, forums, or direct user browsing.
Crowdsourced verification payload.
Run this on the endpoint itself or through your fleet management agent. Invoke it as python3 chrome_cve_2026_11014_check.py on macOS/Linux or py chrome_cve_2026_11014_check.py on Windows; no administrator rights are required, but local file/process access to discover the Chrome binary helps coverage.
#!/usr/bin/env python3
# Check Chrome version against CVE-2026-11014 fixed build
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
FIXED = (149, 0, 7827, 53)
def parse_ver(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (a < b)
def run_version(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=5)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return parse_ver(out)
except Exception:
return None
def windows_candidates():
env = os.environ
paths = []
for base in [env.get('ProgramFiles'), env.get('ProgramFiles(x86)'), env.get('LocalAppData')]:
if base:
paths.append(Path(base) / 'Google' / 'Chrome' / 'Application' / 'chrome.exe')
return [p for p in paths if p and p.exists()]
def mac_candidates():
paths = [
Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
]
return [p for p in paths if p.exists()]
def linux_candidates():
bins = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
found = []
for b in bins:
p = shutil.which(b)
if p:
found.append(Path(p))
extra = [
Path('/opt/google/chrome/chrome'),
Path('/usr/bin/google-chrome'),
Path('/usr/bin/google-chrome-stable'),
Path('/snap/bin/chromium'),
]
for p in extra:
if p.exists():
found.append(p)
dedup = []
seen = set()
for p in found:
s = str(p)
if s not in seen:
seen.add(s)
dedup.append(p)
return dedup
def discover():
system = platform.system().lower()
candidates = []
if 'windows' in system:
candidates = windows_candidates()
elif 'darwin' in system:
candidates = mac_candidates()
else:
candidates = linux_candidates()
for c in candidates:
ver = run_version([str(c), '--version'])
if ver:
return str(c), ver
# Fallbacks
if 'windows' in system:
try:
import winreg
keys = [
r'SOFTWARE\Google\Chrome\BLBeacon',
r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
]
for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
for key in keys:
try:
with winreg.OpenKey(hive, key) as k:
version, _ = winreg.QueryValueEx(k, 'version')
ver = parse_ver(version)
if ver:
return 'registry', ver
except OSError:
pass
except Exception:
pass
return None, None
def main():
src, ver = discover()
if not ver:
print('UNKNOWN: Google Chrome version not found')
sys.exit(2)
ver_str = '.'.join(map(str, ver))
src_str = src or 'unknown source'
if cmp_ver(ver, FIXED) < 0:
print(f'VULNERABLE: Chrome {ver_str} from {src_str} is older than fixed build 149.0.7827.53')
sys.exit(1)
else:
print(f'PATCHED: Chrome {ver_str} from {src_str} is at or newer than 149.0.7827.53')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Stable Channel Update for Desktop
- Canadian Centre for Cyber Security advisory AV26-544
- GovCERT.HK alert A26-06-08
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS data and statistics
- NVD entry for analogous Chrome extension-policy issue CVE-2026-11212
- Chromium historical enterprise extension policy issue
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.