Like a valet key that only matters after the owner hands it over
CVE-2026-11258 is an inappropriate implementation flaw in Chrome's File System Access feature affecting versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. Based on the affected component, the supplied CVSS (AV:N/AC:L/PR:N/UI:R/C:N/I:H/A:N), and Chrome's own File System Access design docs, the realistic impact is unauthorized modification of user-selected local files or directories after a victim is lured into interacting with a malicious site and granting file access.
The supplied baseline of MEDIUM 6.5 overshoots real-world enterprise risk. The decisive friction is that File System Access is already fenced behind user activation and permission grants, so the attacker is not breaking into arbitrary host files from a cold start; they're abusing a workflow where the user has to open or save through the browser first. Chrome's own June 2026 release notes classify this CVE as Low, and that lines up better with how narrow the reachable population and blast radius are.
4 steps from start to impact.
Deliver a malicious web app
- Victim browses to attacker-controlled or attacker-influenced content in Chrome
- Chrome version is older than the fixed build
- This is client-side exposure, not a remotely reachable enterprise service
- Email/web filtering and user behavior cut initial reach substantially
Obtain user activation and file access
- Victim performs a trusted UI action
- Victim selects a file or directory and/or approves write access
- Requires active user participation, not passive page view
- Permission prompts and file choosers break commodity mass exploitation
- Many enterprises do not rely on browser-based local file workflows for most users
Abuse the implementation flaw
- The victim-granted handle is still valid in the session
- The exploit path successfully triggers the vulnerable logic
- The blast radius is constrained by what the user exposed to the page
- No confidentiality or availability impact is indicated by the supplied vector
- No evidence this chains directly to code execution or privilege escalation
Land file tampering impact
- The selected file or folder contains something operationally meaningful
- The user relies on browser-based file editing or saving
- Impact is usually limited to user-context files, not system-wide control
- Many targets will have backups, sync/version history, or app-level recovery
chrome/google-chrome/Google Chrome to user document, repo, or workspace paths.The supporting signals.
| In-the-wild status | No public evidence of active exploitation found, and not listed in CISA KEV as of the reviewed catalog state. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repo surfaced in primary-source review. Chromium issue 499078161 exists but public bug details are effectively unavailable. |
| EPSS | 0.0002 from the supplied intel — effectively background noise, consistent with a narrow exploitation path. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — the important word is UI:R. The attacker needs user participation, and the impact is integrity-only. |
| Vendor vs public scoring | The supplied baseline says MEDIUM 6.5, but Google's June 2, 2026 Chrome release notes classify CVE-2026-11258 as Low. I weight the vendor component classification more heavily here because the attack is tightly coupled to File System Access workflow controls. |
| Affected versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS; Android release notes state corresponding desktop security fixes carry over. |
| Fixed versions | Upgrade to 149.0.7827.53 or later on Linux, and 149.0.7827.53/.54 or later on Windows/macOS. Chrome for Testing also publishes 149.0.7827.53 artifacts, which is useful for validation. |
| Exposure/scanning reality | Shodan/Censys/FOFA style exposure data is not meaningful for this CVE because Chrome desktop is not an internet-facing service. Treat it as an endpoint/browser inventory problem, not an external attack-surface problem. |
| Researcher / reporting | Google's release notes show Reported by Google on 2026-04-02 for the underlying issue entry. |
noisgate verdict.
The single biggest reason this lands in LOW is that exploitation appears to require the victim to actively grant a website file-system access before the bug becomes useful. That prerequisite crushes both the reachable population and the blast radius: this is a post-consent browser abuse path, not a generic remote browser compromise.
Why this verdict
- User-consent gate cuts the population hard: File System Access write permission is normally guarded by user activation and prompts, so the attacker needs more than a page hit.
- Blast radius is scoped to what the user exposed: even if exploited, the realistic outcome is tampering with selected files/directories, not turnkey system compromise.
- No exploitation pressure: no KEV listing, no public campaign reporting, and a near-zero supplied EPSS value remove the main reasons to keep this in MEDIUM.
Why not higher?
There is no sign of sandbox escape, arbitrary code execution, or privilege escalation in the available evidence. The exploit path also depends on a very specific browser feature workflow that many enterprise users never touch, which sharply limits both scale and impact.
Why not lower?
This is still a real integrity issue in a ubiquitous client. On developer workstations, browser-based IDEs, content systems, and internal web tools that legitimately use File System Access, unauthorized modification of local files can be operationally meaningful enough that it should not be ignored entirely.
What to do — in priority order.
- Block File System API writes by policy where you can — If business workflows allow it, set Chrome enterprise policy
DefaultFileSystemWriteGuardSetting=2or use per-site blocks such asFileSystemWriteBlockedForUrls. For a LOW verdict there is no formal mitigation SLA, but if you choose to harden this, do it as backlog hygiene alongside routine browser policy maintenance. - Allowlist trusted file-access sites only — Use the Chrome enterprise File System read/write URL policies so only sanctioned web apps can request local file access. This reduces exposure immediately without waiting for browser patch adoption; for LOW, fold it into normal policy review rather than emergency change.
- Watch for Chrome touching sensitive user paths — Add or tune FIM/EDR detections for browser processes modifying developer repos, scripts, templates, or line-of-business content stores. This won't prevent exploitation, but it improves odds of catching the integrity impact that matters here.
- Suppress risky browser-based file workflows for high-risk groups — For admins, developers, and finance users, reduce ad hoc use of untrusted web editors and file managers until the fixed Chrome version is universal. This is a practical exposure reduction move, especially in mixed patch-state fleets.
- A network IPS/WAF doesn't solve this well because the vulnerable surface is a local browser permissioned API, not a stable server-side request pattern.
- MFA is irrelevant here; there is no account-authentication control in the exploit chain to interrupt.
- Generic Safe Browsing alone is not a dependable control if the lure is hosted on a newly created or compromised-but-reputable site.
Crowdsourced verification payload.
Run this on the target endpoint or via your endpoint-management runner. Invoke it with python3 check_chrome_cve_2026_11258.py; no admin rights are required for normal file/path checks, but Windows registry reads work best in a standard user session with local registry access.
#!/usr/bin/env python3
# check_chrome_cve_2026_11258.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIX_VERSION = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(s):
if not s:
return None
m = VERSION_RE.search(s)
if not m:
return None
return tuple(int(x) for x in m.groups())
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=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_version_linux():
candidates = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium', '--version'],
['chromium-browser', '--version'],
]
for cmd in candidates:
if shutil.which(cmd[0]):
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v, ' '.join(cmd)
return None, ''
def get_version_macos():
app_paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Chromium.app/Contents/MacOS/Chromium',
]
for p in app_paths:
if os.path.exists(p):
out = run_cmd([p, '--version'])
v = parse_version(out)
if v:
return v, p
return None, ''
def get_version_windows():
reg_queries = [
['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
['reg', 'query', r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon', '/v', 'version'],
['reg', 'query', r'HKCU\Software\Chromium\BLBeacon', '/v', 'version'],
['reg', 'query', r'HKLM\Software\Chromium\BLBeacon', '/v', 'version'],
]
for cmd in reg_queries:
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v, ' '.join(cmd)
exe_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 p in exe_candidates:
if p and os.path.exists(p):
out = run_cmd([p, '--version'])
v = parse_version(out)
if v:
return v, p
return None, ''
def main():
system = platform.system().lower()
version = None
source = ''
if 'linux' in system:
version, source = get_version_linux()
elif 'darwin' in system:
version, source = get_version_macos()
elif 'windows' in system:
version, source = get_version_windows()
else:
print('UNKNOWN: unsupported platform {}'.format(platform.system()))
sys.exit(2)
if not version:
print('UNKNOWN: could not determine installed Chrome/Chromium version')
sys.exit(2)
if compare(version, FIX_VERSION) < 0:
print('VULNERABLE: detected version {} via {} (fixed at {}.{}.{}.{})'.format(
'.'.join(map(str, version)), source, *FIX_VERSION
))
sys.exit(1)
else:
print('PATCHED: detected version {} via {} (meets/exceeds {}.{}.{}.{})'.format(
'.'.join(map(str, version)), source, *FIX_VERSION
))
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 installs, patch them in your routine browser wave, and if you have high-risk browser-based file workflows, tighten File System Access policies as part of standard hardening. The noisgate remediation SLA for LOW is no SLA (treat as backlog hygiene), but in practice you should still roll the fixed Chrome build through your next scheduled browser update cycle rather than letting stale versions linger indefinitely.Sources
- Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue 499078161
- Chrome for Developers - File System Access API
- MDN - File System API
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Chrome Enterprise - DefaultFileSystemWriteGuardSetting
- Chrome Enterprise - FileSystemWriteBlockedForUrls
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.