This is a mislabeled exit sign in a crowded building, not a master key to the building
CVE-2026-11257 is a Chrome browser policy/trust flaw: a crafted HTML page can bypass navigation restrictions in the browser layer. Public sources tie it to Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS, with downstream distro fixes also rolling out. That puts the issue on endpoints, not servers; the attacker needs a user in the browser seat.
The vendor/NVD-style MEDIUM 4.3 baseline is already restrained, but in enterprise reality this still grades lower. There is no code execution, no sandbox escape, no credential theft primitive by itself, no KEV entry, no public exploitation signal, and the attack path starts with *user-driven browsing to attacker content*; that combination makes this a patchable browser hygiene issue, not a fire drill.
4 steps from start to impact.
Land the user on attacker-controlled web content
- Target is running Chrome prior to
149.0.7827.53 - User browses to attacker-controlled content
- Normal web content execution is allowed
- Requires user interaction (
UI:R) - Enterprise web filtering, Safe Browsing, and mail gateways can cut off the lure before render
- Modern Chrome auto-update shrinks dwell time on managed fleets
Trigger the navigation restriction bypass
- The vulnerable browser code path is reachable from the page
- The specific navigation sequence used by the attacker still behaves as described
- Behavioral edge cases in browser policy bugs are often brittle across channels and minor builds
- Many such bugs degrade into UI confusion or limited origin/trust bypass rather than durable attacker control
Turn bypass into user deception or session abuse
- Victim continues interacting with the malicious or redirected content
- The enterprise relies on browser trust indicators or blocked navigation behavior as a control boundary
- Impact stays bounded to what the user is willing to do next
- MFA, IdP risk checks, passwordless auth, and user awareness blunt the follow-on payoff
Exploit downstream trust, not the endpoint
- A follow-on business process or identity abuse path exists
- The victim takes a second action after the browser flaw is triggered
- No evidence this CVE alone yields code execution or lateral movement
- Blast radius is generally one browsing session at a time
The supporting signals.
| In-the-wild status | No public exploitation evidence found. PCWorld's coverage of the Chrome 149 release says Google reported none of the patched flaws were known to be exploited in the wild at release time. PCWorld |
|---|---|
| PoC availability | No public PoC located in the sources reviewed. Public bug details also appear sparse/restricted, which is common for Chrome until update saturation improves. |
| EPSS | 0.0002 from the user-provided intel, which is effectively negligible operational pressure. FIRST documents EPSS as a probability of exploitation in the next 30 days. FIRST EPSS FIRST data stats |
| KEV status | Not listed in CISA KEV per user-provided intel, and no matching listing is visible from the public KEV catalog path reviewed. CISA KEV catalog |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — remote and unauthenticated, but user interaction is mandatory and impact is limited to low integrity change rather than confidentiality loss, availability loss, or code execution. |
| Affected versions | Chrome prior to 149.0.7827.53 per multiple public advisories; Chrome desktop release notes show 149.0.7827.53/.54 on Windows/macOS in the early stable wave. GovCERT.HK Chrome Releases |
| Fixed versions | Upgrade to 149.0.7827.53 or later; for Windows/macOS that maps to the desktop early stable 149.0.7827.53/.54 train. Downstream package maintainers such as openSUSE also rolled the fix in their Chromium maintenance stream. Chrome Releases openSUSE patchinfo |
| Exposure / scanning reality | Not meaningfully internet-scannable. This is endpoint client software, so Shodan/Censys-style exposure counts do not map cleanly. Real exposure is fleet prevalence: wherever users run vulnerable Chrome builds, the reachable population is broad, but only through user browsing. |
| Disclosure date | 2026-06-05 from the provided intel; public feeds also show the CVE landing on that date. CVE Alert feed |
| Researcher / source attribution | Not publicly attributed in the sources reviewed. The public Chrome and feed entries available here identify the bug class/component but do not expose a public researcher credit for this specific CVE. |
noisgate verdict.
The decisive factor is mandatory user interaction on a client-side trust bug with only low-integrity impact. This is a browser-session policy bypass that still needs a second-stage social-engineering payoff, and there is no current exploitation signal pushing it higher.
Why this verdict
- Start from 4.3, then cut for UI:R: the attacker must get a user onto malicious content first, which means phishing, malvertising, or some other lure has to work before the CVE matters.
- This is post-lure, not initial compromise: requiring a browser session implies the attacker is operating through user browsing, not directly against an exposed enterprise service.
- Impact is narrow: the public description is a navigation restriction bypass with
I:Land no stated confidentiality or availability impact, so this is trust abuse, not endpoint takeover. - No active-threat pressure: user-provided intel says KEV is negative and EPSS is
0.0002; reviewed public reporting also says no known in-the-wild exploitation at release. - Wide deployment keeps it patch-worthy: Chrome is everywhere, so this is not
IGNORE; it still deserves version hygiene and update verification across the fleet.
Why not higher?
A higher rating would need at least one of three things: active exploitation, a public weaponized chain, or materially stronger impact such as same-origin bypass with credential theft implications, sandbox escape, or code execution. None of that is in the public record reviewed here. The user-interaction requirement compounds the downgrade because it puts this behind your phishing controls and user behavior.
Why not lower?
It is not IGNORE because Chrome is high-prevalence client software and the bug is remotely reachable through normal browsing. Even low-grade browser trust breaks can be folded into phishing kits and identity attacks, so you still want the fleet updated and exceptions documented.
What to do — in priority order.
- Enforce browser auto-update — Make sure enterprise policy actually forces Chrome/Chromium updates and relaunch behavior, because version churn is the cleanest control here. For a LOW verdict there is no SLA; treat as backlog hygiene, but validate policy compliance in the next routine endpoint maintenance cycle.
- Tighten phishing and web filtering — Because the bug starts with a user visiting attacker-controlled content, mail gateway URL rewriting, DNS/web filtering, Safe Browsing enforcement, and high-risk category blocking remove the first prerequisite. For a LOW verdict there is no SLA; treat as backlog hygiene unless your environment is under targeted phishing pressure.
- Instrument browser version inventory — Track Chrome versions through EDR, MDM, SCCM/Intune/Jamf, or package management so you can prove which endpoints remain below
149.0.7827.53. For a LOW verdict there is no SLA; treat as backlog hygiene, but do not rely on network scanners for browser client coverage. - Harden identity follow-on controls — Since the likely real-world payoff is phishing or deceptive navigation, make sure phishing-resistant MFA, conditional access, and suspicious sign-in alerts are enforced. For a LOW verdict there is no SLA; treat as backlog hygiene, but this control meaningfully reduces the bug's downstream business impact.
- A perimeter firewall does not solve this; the vulnerable surface is ordinary outbound web browsing.
- Server-side WAF rules do not meaningfully help unless you fully control every site the user can browse, which enterprises do not.
- Exploit-block signatures alone are weak here; this is not a noisy memory-corruption bug with stable crash indicators.
Crowdsourced verification payload.
Run this on the target endpoint or via your software inventory/remote execution tooling. Invoke it with python3 check_chrome_cve_2026_11257.py on macOS/Linux or py check_chrome_cve_2026_11257.py on Windows; local user rights are usually enough, but admin rights may help if Chrome is installed system-wide in nonstandard paths.
#!/usr/bin/env python3
# check_chrome_cve_2026_11257.py
# Purpose: Detect whether local Google Chrome / Chromium appears vulnerable to CVE-2026-11257
# Output: 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
THRESHOLD = (149, 0, 7827, 53)
def parse_version(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 version_to_str(v):
return '.'.join(str(x) for x in v)
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 candidate_paths():
system = platform.system().lower()
paths = []
if 'windows' in system:
envs = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData')
]
rels = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe'
]
for base in envs:
if base:
for rel in rels:
paths.append(str(Path(base) / rel))
elif 'darwin' in system:
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
str(Path.home() / 'Applications/Chromium.app/Contents/MacOS/Chromium'),
])
else:
# Linux and other Unix-like
binaries = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome'
]
for b in binaries:
found = shutil.which(b)
if found:
paths.append(found)
paths.extend([
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser'
])
# Deduplicate while preserving order
seen = set()
uniq = []
for p in paths:
if p and p not in seen:
seen.add(p)
uniq.append(p)
return uniq
def discover_versions():
found = []
for p in candidate_paths():
if not os.path.exists(p):
continue
out = run_cmd([p, '--version'])
ver = parse_version(out)
if ver:
found.append((p, ver, out))
return found
def assess(ver):
return 'PATCHED' if ver >= THRESHOLD else 'VULNERABLE'
def main():
installs = discover_versions()
if not installs:
print('UNKNOWN: No Google Chrome/Chromium binary found in common locations.')
sys.exit(2)
# If any detected installation is vulnerable, call the host vulnerable.
vulnerable = []
patched = []
for path, ver, raw in installs:
state = assess(ver)
record = f'{path} -> {version_to_str(ver)} ({state})'
if state == 'VULNERABLE':
vulnerable.append(record)
else:
patched.append(record)
print(f'Threshold: {version_to_str(THRESHOLD)}')
print('Detected installations:')
for rec in vulnerable + patched:
print(f' - {rec}')
if vulnerable:
print('VULNERABLE')
sys.exit(1)
elif patched:
print('PATCHED')
sys.exit(0)
else:
print('UNKNOWN')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and fold the upgrade into your next routine endpoint/browser rollout; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat as backlog hygiene. If you have high-risk user groups regularly targeted by phishing, prioritize them first, but for the broader fleet this is normal patch validation work, not an incident-response tempo task.Sources
- Google Chrome Releases - Early Stable Update for Desktop
- Google Chrome Releases - 2026 archive
- GovCERT.HK alert for Chrome 149 fixes
- openSUSE Chromium patchinfo including CVE-2026-11257
- CVE Alert feed entry for CVE-2026-11257
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS data and methodology
- PCWorld coverage of Chrome 149 security fixes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.