This is a side door around one room's house rules, not a key to the whole building
CVE-2026-11252 is a policy bypass in Chrome Content Settings. Google says Chrome versions before 149.0.7827.53 are affected, with the stable fix shipped as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS on June 2, 2026. The public description says a remote attacker can use a crafted HTML page to bypass discretionary access control, which strongly suggests a site can make Chrome mishandle a browser-enforced content permission or restriction rather than achieve code execution or broad data theft.
The 4.3/Medium CVSS is a little generous for enterprise triage. In practice this is a client-side, user-driven, per-visit browser logic flaw with no known exploitation, no KEV listing, ultra-low EPSS, and low stated impact; the attacker must still get a user onto the malicious page, and the likely payoff is a narrow policy bypass inside one browser session. That's real, but it is not the kind of bug that should jump ahead of server-side RCEs, auth bypasses, or already-exploited browser sandbox escapes.
3 steps from start to impact.
Lure user to attacker-controlled page
- Victim is running Chrome earlier than
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced web content
- Chrome auto-update is delayed, disabled, or unmanaged on that endpoint
- Requires user interaction; this is not a drive-by network service exploit against a server
- Secure email/web gateways, URL filtering, and user browsing isolation can break the lure stage
- Modern Chrome fleets often self-update quickly, shrinking the exposed window
Trigger the Content Settings policy bypass
- Specific vulnerable code path in Content Settings must be reachable from normal web content
- The victim must perform whatever interaction the page requires
- Bug details are still restricted, which usually slows broad weaponization
- Enterprise-hardening such as site isolation, restrictive browser policy, or click-to-play style controls may reduce reachable abuse paths depending on the underlying setting
- The impact appears limited by design: C:N/I:L/A:N
Abuse the relaxed browser restriction
- The bypassed control must be relevant to the attacker's page objective
- The user session must continue long enough to exploit the relaxed restriction
- Blast radius is usually one user, one browser session, one endpoint
- No evidence here of sandbox escape, credential theft primitive, or persistence mechanism
- Any meaningful follow-on impact still needs another weakness or successful social engineering
The supporting signals.
| In-the-wild status | No public exploitation evidence found. Google did not flag active exploitation in the release notes, and the CVE is not listed in CISA KEV. |
|---|---|
| PoC availability | No public PoC located in primary sources at time of assessment. The Chromium bug is referenced as issue 498373018, but Google notes bug access may remain restricted until most users are patched. |
| EPSS | 0.0002 probability with about 5.678th percentile per EPSS data surfaced for 2026-06-05 — basically background-noise exploit likelihood. |
| KEV status | Not KEV-listed as of this assessment. That removes the strongest external urgency signal. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — the key downward pressure is UI:R plus only low integrity impact. |
| Affected versions | Google Chrome before 149.0.7827.53. Stable advisory covers desktop Chrome prior to 149.0.7827.53/54 depending on platform. |
| Fixed versions | Linux: 149.0.7827.53. Windows/macOS: 149.0.7827.53/54. Example downstream packaging/backport evidence: openSUSE published maintenance metadata including CVE-2026-11252. |
| Exposure reality | This is widely deployed software but not internet-addressable infrastructure. Shodan/Censys-style external exposure counts are not meaningful here; the reachable population is your browser fleet, and exploitation requires the user to browse to malicious content. |
| Disclosure timeline | Chrome stable update published 2026-06-02; CVE record published 2026-06-05; Chrome release notes say the issue was reported by Google on 2026-04-01. |
| Reporter / bug lineage | Reported by Google, Chromium issue 498373018. Chrome release notes classify it as Low (Policy bypass in Content Settings). |
noisgate verdict.
The decisive factor is attack-path friction: this bug needs a user to browse to malicious content and appears to deliver only a narrow browser policy bypass rather than code execution or data exposure. On a 10,000-host fleet, that makes it a real hygiene item but not an incident-response-grade fire.
Why this verdict
- User interaction is mandatory — this starts only after the victim lands on attacker-controlled HTML, which is a meaningful real-world choke point.
- Impact is narrow by the vendor's own scoring profile —
C:N/I:L/A:Nsays no direct confidentiality loss, no availability loss, and only low integrity impact. - No exploitation pressure — no KEV entry, no public active-exploitation statement, and EPSS is effectively floor-level.
- Per-endpoint blast radius — this is a browser-session problem, not an unauthenticated server-side foothold across your estate.
- Modern controls should break stage one — secure web gateways, URL filtering, browser isolation, and normal Chrome auto-update all suppress the practical hit rate.
Why not higher?
It is not higher because the path is post-click, not unauthenticated service exploitation, and the published impact is not host compromise. There is also no evidence of chaining to sandbox escape, credential theft, or broad tenant-wide blast radius. If a reliable PoC appears showing bypass of an enterprise-enforced content restriction with high abuse value, this would need a fresh look.
Why not lower?
It is not IGNORE because Chrome is everywhere, and even a low-grade browser policy bypass can still help phishing, policy evasion, or nuisance abuse on individual endpoints. It also crosses a real security boundary in a high-frequency client application, so you should still verify patch uptake rather than wave it away.
What to do — in priority order.
- Force browser auto-update — Ensure enterprise policy does not defer Chrome stable updates longer than necessary and verify fleet uptake through your browser/MDM telemetry. For a LOW verdict there is no fixed mitigation SLA beyond backlog hygiene, but this is the cleanest control because browser bugs age badly once details spread.
- Block known-malicious browsing paths — Keep secure web gateway, DNS filtering, and browser isolation controls tight on categories that commonly deliver lure pages such as newly registered domains, file-sharing links, ad-tech redirects, and disposable hosting. This reduces the only mandatory prerequisite: getting the user onto attacker content.
- Audit Chrome version compliance — Use EDR, MDM, SCCM, Jamf, or Linux package inventory to identify endpoints still below
149.0.7827.53. For a LOW verdict, treat this as backlog hygiene and close it through your normal browser maintenance cycle. - Constrain risky browser exceptions — Review enterprise browser policies that relax content restrictions for internal sites or legacy apps, because policy-bypass bugs become more useful when you already carry broad allowlists. Document and shrink those exceptions during the same maintenance cycle.
- A network perimeter scan will not find this; it is a client-side browser flaw, not a listening service.
- MFA does nothing for the exploit path itself because the prerequisite is page visit + browser logic abuse, not account takeover.
- A WAF is mostly irrelevant unless it protects a specific internal site serving the malicious content; it does not shield users from arbitrary external pages.
- AV-only posture is weak here because there may be no dropped file or process-level exploit artifact at all.
Crowdsourced verification payload.
Run this on the target endpoint or via EDR live response; it is designed for Windows, macOS, and Linux Chrome installs. Invoke it with python3 check_chrome_cve_2026_11252.py; no admin rights are normally required, though some managed install paths or registry access on locked-down Windows hosts may need elevated read access.
#!/usr/bin/env python3
# check_chrome_cve_2026_11252.py
# Detects whether Google Chrome is older than the fixed version for CVE-2026-11252.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import plistlib
import re
import shutil
import subprocess
import sys
from pathlib import Path
TARGET = (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_lt(a, b):
return a < b
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
if p.returncode == 0:
return p.stdout.strip() or p.stderr.strip()
except Exception:
pass
return None
def check_windows():
candidates = [
Path(os.environ.get('ProgramFiles', '')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('ProgramFiles(x86)', '')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('LocalAppData', '')) / 'Google/Chrome/Application/chrome.exe',
]
found = []
for p in candidates:
if p and p.exists():
found.append(str(p))
ps = shutil.which('powershell') or shutil.which('pwsh')
for exe in found:
if ps:
script = f"(Get-Item '{exe}').VersionInfo.ProductVersion"
out = run_cmd([ps, '-NoProfile', '-Command', script])
v = parse_version(out)
if v:
return v, exe
reg_queries = [
r'HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
r'HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
r'HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
]
reg = shutil.which('reg')
if reg:
for key in reg_queries:
out = run_cmd([reg, 'query', key, '/ve'])
if out:
v = parse_version(out)
if v:
return v, key
return None, None
def check_macos():
app = Path('/Applications/Google Chrome.app/Contents/Info.plist')
if app.exists():
try:
with app.open('rb') as f:
plist = plistlib.load(f)
ver = plist.get('KSVersion') or plist.get('CFBundleShortVersionString')
v = parse_version(ver)
if v:
return v, str(app)
except Exception:
pass
chrome_bin = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if Path(chrome_bin).exists():
out = run_cmd([chrome_bin, '--version'])
v = parse_version(out)
if v:
return v, chrome_bin
return None, None
def check_linux():
names = ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']
for name in names:
binpath = shutil.which(name)
if binpath:
out = run_cmd([binpath, '--version'])
v = parse_version(out)
if v:
return v, binpath
package_cmds = [
['dpkg-query', '-W', '-f=${Version}', 'google-chrome-stable'],
['rpm', '-q', '--qf', '%{VERSION}-%{RELEASE}', 'google-chrome-stable'],
]
for cmd in package_cmds:
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v, 'package-manager'
return None, None
def main():
system = platform.system().lower()
version = None
source = None
if 'windows' in system:
version, source = check_windows()
elif 'darwin' in system:
version, source = check_macos()
elif 'linux' in system:
version, source = check_linux()
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not version:
print('UNKNOWN: Google Chrome version not found')
sys.exit(2)
if ver_lt(version, TARGET):
print(f'VULNERABLE: found Chrome {".".join(map(str, version))} via {source}; fixed version is >= {".".join(map(str, TARGET))}')
sys.exit(1)
else:
print(f'PATCHED: found Chrome {".".join(map(str, version))} via {source}; fixed version is >= {".".join(map(str, TARGET))}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and clean them up in your routine browser maintenance lane; for a LOW verdict there is no noisgate mitigation SLA and noisgate remediation SLA is no SLA (treat as backlog hygiene). In plain terms: keep auto-update healthy, verify compliance this cycle, and finish patching through normal endpoint hygiene rather than burning scarce urgent-patching capacity.Sources
- Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue 498373018
- CVE.org record for CVE-2026-11252
- NVD entry for CVE-2026-11252
- FIRST EPSS API for CVE-2026-11252
- CISA Known Exploited Vulnerabilities Catalog
- Canadian Centre for Cyber Security advisory AV26-544
- openSUSE maintenance metadata referencing CVE-2026-11252
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.