This is a bad valet key, not a broken front door
CVE-2026-11267 is an insufficient policy enforcement flaw in Chrome Extensions affecting Google Chrome before 149.0.7827.53. Based on the Chromium fix that blocks message connections from sandboxed extension pages, the practical issue is that a malicious extension could abuse an extension-internal trust boundary and reach messaging or privileged flows it should not have reached. The affected desktop builds were fixed in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.
Google's MEDIUM 4.3 label is already restrained, and in enterprise reality it still trends down, not up. The decisive friction is that the attacker does not get this from a random website alone; they need the victim to install a malicious extension first, which is a separate social-engineering or policy-control failure. That makes this a post-user-action browser hardening issue with narrow real-world reach, not a broad remote compromise bug.
4 steps from start to impact.
Deliver a malicious extension
- Target user can install extensions or already has an attacker-controlled extension
- User accepts install prompts or admin policy allows the extension
- Managed Chrome can block all but allowlisted extensions
- Users must perform a visible install action
- Chrome Web Store review, post-publication monitoring, and Safety Check reduce but do not eliminate bad extensions
Reach the flawed extension trust boundary
- Attacker controls extension code execution
- Victim is on a vulnerable Chrome build prior to 149.0.7827.53
- This is not reachable from arbitrary network traffic alone
- The bug appears tied to a specific extension messaging edge case rather than a general browser RCE path
Bypass policy enforcement inside Extensions
- The specific sandboxed-page or messaging abuse path works against the installed build
- The extension's follow-on logic is built to exploit the bypass
- Impact is bounded by browser/extension context, not an instant OS-level compromise
- Enterprise restrictions on extension permissions and host access can reduce blast radius
Abuse gained access for tampering
- The malicious extension has a useful post-bypass payload
- Users continue running the extension long enough for abuse
- No evidence here of in-the-wild exploitation or KEV status
- No direct internet-exposed attack surface to mass-scan and spray
The supporting signals.
| In-the-wild status | No public in-the-wild evidence found from the supplied intel, and not KEV-listed in CISA's catalog (CISA KEV) |
|---|---|
| Proof-of-concept availability | No public PoC located during this review. The strongest technical breadcrumb is the Chromium branch fix "[Extensions] Don't allow message connections from sandboxed pages" in the 149 branch (Chromium log) |
| EPSS | 0.00017 from the user-supplied intel, which is effectively background noise for mass exploitation probability |
| KEV status | No; no known CISA KEV entry as of this assessment (catalog) |
| CVSS vector readout | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N = network-reachable in theory, but requires user interaction, has low integrity-only impact, and no scope change |
| Affected versions | Chrome desktop prior to 149.0.7827.53; Canada Cyber Centre summarizes affected stable builds as before 149.0.7827.53/54 on Windows/Mac and before 149.0.7827.53 on Linux (advisory) |
| Fixed versions | 149.0.7827.53+ covers Linux and the early-stable Windows/macOS release line; Google's release note confirms 149.0.7827.53/.54 for Windows/Mac (Chrome Releases) |
| Exposure and scanability | Not internet-scannable in the normal sense. This is a client-side browser/extension flaw, so Shodan/Censys/FOFA-style exposure data is not materially useful here; exposure is determined by fleet versioning and extension-install policy, not by open ports |
| Enterprise control surface | Chrome Enterprise can allowlist/blocklist extensions, block risky permissions, and force install approved extensions only (allow/block, Windows policy) |
| Researcher / reporting trail | The public breadcrumb is the Chromium fix and Google's June 2026 desktop release stream; researcher attribution was not identified in the reviewed public sources |
noisgate verdict.
The single biggest severity suppressor is the attacker position requirement: this bug matters only after a user installs a malicious extension or the attacker already controls one. That makes the reachable population far smaller than the browser's install base and shifts this from a broad remote exploit to a constrained trust-boundary bypass inside an already suspicious execution context.
Why this verdict
- Requires a malicious extension first: the attacker is not just sending packets at Chrome; they must land a hostile extension, which implies prior social engineering, unmanaged installs, or weak admin policy
- Reachable population collapses fast in managed fleets: enterprises using
ExtensionSettings, allowlists, or force-install-only models remove most of the practical attack surface - Impact is modest even on success: the published CVSS is integrity-only and user-interaction-dependent, with no stated confidentiality or availability impact and no evidence of host-level takeover
- No exploitation pressure: no KEV listing, no public campaign evidence, and a near-zero EPSS keep this out of urgent patch-now territory
Why not higher?
A higher rating would require either broad pre-auth remote reach, active exploitation, or a blast radius that extends beyond the browser extension boundary. None of those are present here. Every meaningful path starts with a malicious extension install, which is exactly the kind of compounding prerequisite that should drag severity down for enterprise prioritization.
Why not lower?
This is still a real security boundary failure in one of the most widely deployed enterprise applications on the planet. If your environment allows permissive extension installs, the social-engineering hurdle is not hypothetical, and a malicious extension gaining extra reach is worth fixing rather than ignoring.
What to do — in priority order.
- Allowlist extensions only — Use Chrome Enterprise
ExtensionSettingsor Admin Console allow/block mode so users can install only approved extensions. For a LOW verdict there is no mitigation SLA; treat this as policy hygiene and fold it into your next browser-governance review rather than an emergency change. - Block risky extension permissions — Use Chrome app/extension policy controls to block permissions your org does not need, especially broad webpage access and sensitive capabilities. This shrinks post-install blast radius even if a bad extension slips through; again, no mitigation SLA applies here, so do it in the normal hardening cycle.
- Inventory installed extensions — Pull the Chrome Apps & Extensions usage report and identify user-installed extensions, especially anything not force-installed by IT. This is the fastest way to find where the prerequisite for this CVE actually exists in your fleet.
- Restrict unmanaged browsers — The real exposure lives in unmanaged Chrome instances where users can self-install extensions. Push devices into Chrome management or enforce enterprise browser policy so the extension gate is closed by default.
- A WAF does not help; this is not a server-side web attack path against your perimeter apps
- Network vulnerability scanning does not meaningfully measure exploitability here; at best it can find browser version data, not whether users can install malicious extensions
- Email filtering alone is insufficient because the payload is an extension install decision, not necessarily a malicious attachment or exploit document
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tooling. Invoke it with python3 check_chrome_cve_2026_11267.py; it needs only normal user rights and checks common Chrome install locations on Windows, macOS, and Linux. It reports VULNERABLE, PATCHED, or UNKNOWN based on whether the detected Chrome version is before 149.0.7827.53.
#!/usr/bin/env python3
# check_chrome_cve_2026_11267.py
# Detect exposure to CVE-2026-11267 by checking local Google Chrome version.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
THRESHOLD = (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 run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_windows_version():
candidates = [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LOCALAPPDATA', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for path in candidates:
if path and os.path.exists(path):
cmd = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path.replace("'", "''")}').VersionInfo.ProductVersion"
]
out = run_cmd(cmd)
ver = parse_version(out)
if ver:
return ver, path
return None, None
def get_macos_version():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in candidates:
if os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, path
return None, None
def get_linux_version():
bins = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']
for b in bins:
exe = which(b)
if exe:
out = run_cmd([exe, '--version'])
ver = parse_version(out)
if ver:
return ver, exe
return None, None
def main():
system = platform.system().lower()
version = None
source = None
if 'windows' in system:
version, source = get_windows_version()
elif 'darwin' in system:
version, source = get_macos_version()
elif 'linux' in system:
version, source = get_linux_version()
else:
print('UNKNOWN - Unsupported OS')
sys.exit(2)
if not version:
print('UNKNOWN - Google Chrome not found or version unreadable')
sys.exit(2)
version_str = '.'.join(str(x) for x in version)
threshold_str = '.'.join(str(x) for x in THRESHOLD)
if version < THRESHOLD:
print(f'VULNERABLE - Detected Chrome {version_str} at {source}; fixed version is {threshold_str} or later')
sys.exit(1)
else:
print(f'PATCHED - Detected Chrome {version_str} at {source}; meets fixed version threshold {threshold_str}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases: Early Stable Update for Desktop
- Chromium 149 branch log
- Canadian Centre for Cyber Security advisory AV26-544
- Chrome Enterprise: Allow or block apps and extensions
- Chrome Enterprise: View app and extension usage details
- Chrome Enterprise: Set Chrome app and extension policies (Windows)
- Google Online Security Blog: Staying Safe with Chrome Extensions
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.