This is the second lock on the door failing after the first lock has already been picked
CVE-2026-10931 is a use-after-free in Chrome FileSystem. The affected range is Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS; Android inherits the same desktop security fixes in the corresponding 149 release. Public bug internals are still mostly restricted, but the published description ties the bug to a crafted HTML page and a potential sandbox escape, which means the bug matters most as a browser exploit-chain component rather than a simple crash.
There is no vendor CVSS baseline, so this is a first-principles assessment. My read is that vendor reality and defender reality line up on HIGH, not CRITICAL: the phrase *sandbox escape* plus Chromium's own severity rules strongly implies a prior renderer foothold or equivalent first-stage browser compromise, which is major friction. Still, if an attacker already has stage one, defeating Chrome's sandbox on one of the most widely deployed enterprise clients is absolutely not a backlog item.
4 steps from start to impact.
Land a renderer foothold first
- Victim browses to attacker-controlled or attacker-influenced content
- Attacker has a separate renderer/V8/Blink-stage exploit or equivalent foothold
- Target runs an affected Chrome build
- Requires a prior compromise stage inside Chrome's sandbox
- Modern site isolation, sandboxing, and browser hardening raise the cost of stage one
- No public exploit chain for this CVE was found in indexed sources
Trigger the FileSystem use-after-free
- Successful access to the vulnerable FileSystem code path
- Memory layout favorable enough to turn a UAF into a usable primitive
- Affected version still deployed
- Use-after-free does not equal reliable code execution by default
- Allocator hardening and exploit mitigations may reduce determinism
- Restricted bug details slow copycat weaponization
Cross the sandbox boundary
- Renderer-level execution or equivalent primitive already obtained
- Successful exploitation of the FileSystem UAF
- Target platform/process architecture permits meaningful privilege transition
- Chrome's multi-process architecture and platform-specific sandboxing still constrain the blast radius
- An endpoint user's OS permissions remain the upper bound absent further local escalation
- Exploit quality must be high enough to survive modern browser mitigations
Act on the endpoint
- Sandbox escape succeeded
- Useful post-escape objective exists on the host
- User context provides access to targeted data or sessions
- User-context access is still less than full admin
- EDR, browser isolation, and application control may catch follow-on actions
- A single client compromise does not automatically become domain-wide impact
The supporting signals.
| In-the-wild status | No confirmed public exploitation found in indexed primary sources, and not listed in CISA KEV as of 2026-06-05. That removes the emergency premium, but not the browser-chain risk. |
|---|---|
| PoC availability | No public PoC repo or exploit write-up found. The Chromium issue exists as 501115599, but detailed internals appear restricted, which meaningfully slows copycat weaponization. |
| EPSS | User-supplied EPSS is 0.00035 (0.035%), which is effectively floor-level exploit prediction. I could not confirm a percentile from indexed primary sources, and a secondary tracker currently shows EPSS metadata lag for this record. |
| KEV status | No. There is no KEV entry date because the CVE is not present in the CISA KEV catalog. |
| CVSS / vector | No vendor or authority CVSS is published. Based on Chromium's severity guidelines, sandbox escapes that imply a compromised renderer belong in High/S1, not Critical/S0. |
| Affected versions | Chrome before 149.0.7827.53 (Linux) and before 149.0.7827.53/54 (Windows/macOS); Android 149 inherits the corresponding desktop security fixes per Chrome release notes. |
| Fixed versions | Upgrade to 149.0.7827.53+ on Linux and 149.0.7827.53/54+ on Windows/macOS. For fleet hygiene, treat anything older than those builds as exposed. |
| Exposure / scan reality | This is a client-side browser bug, so Shodan/Censys/FOFA do not meaningfully enumerate exposure. Real exposure is your managed endpoint population, and Chrome still holds about 70.25% worldwide browser share per StatCounter May 2026. |
| Disclosure / reporter | The Chrome stable advisory was published 2026-06-02 for version 149; the CVE record is shown as published 2026-06-04 in a secondary index. The Chrome release note credits asjidkalam as the reporter, with Chromium issue 501115599. |
| Metadata quality | The exact CVE is present in the official Chrome 149 stable release note, but NVD/CVE indexing and enriched scoring are incomplete or unavailable in indexed results right now. Confidence is high on affected/fixed versions, lower on the exact exploit mechanics because bug details remain restricted. |
noisgate verdict.
This lands in HIGH because the decisive friction is that it appears to be a sandbox-escape leg, which implies a prior renderer compromise rather than a one-bug browser-to-host break. That keeps it out of CRITICAL, but the ubiquity of Chrome means a reliable second-stage escape still has serious enterprise value once an attacker gets stage one.
Why this verdict
- Down from hypothetical Critical: this reads like a classic post-renderer sandbox escape, so the attacker position is not unauthenticated remote-to-host in one shot; it likely assumes a first-stage browser compromise.
- Still firmly High: the affected product is Chrome, not a niche plugin, so the reachable population inside most enterprises is enormous even if the bug is not internet-scanable like a server flaw.
- Threat heat is low today: no KEV listing, no public campaign evidence, no public PoC, and a tiny EPSS all push the score down from the top of the High band.
Why not higher?
I do not see evidence that CVE-2026-10931 is a standalone remote code execution path to the host OS. The strongest downward pressure is the likely renderer-compromise prerequisite; that means this bug usually matters as bug two in a chain, not bug one. Lack of KEV, public weaponization, and authoritative CVSS also argues against a CRITICAL call.
Why not lower?
I also would not demote this to MEDIUM. Breaking Chrome's sandbox is one of the few client-side outcomes that can turn a routine browser foothold into real endpoint impact, and Chrome's deployment base means the population is anything but narrow. Even with exploit friction, this is meaningful attacker infrastructure once paired with a renderer bug.
What to do — in priority order.
- Force browser auto-update — Push managed Chrome updates and verify endpoints are moving to 149.0.7827.53+ / 149.0.7827.54+. For a HIGH verdict, deploy this control within 30 days; it is the cleanest way to collapse exposure on a ubiquitous client.
- Block stale Chrome from sensitive apps — Use IdP, reverse proxy, ZTNA, or conditional-access controls to deny or step-up-authentication for outdated Chrome builds accessing admin consoles, VDI portals, and high-value SaaS. Apply within 30 days so unpatched browsers are not the default path to sensitive sessions.
- Isolate risky browsing — Route high-risk user groups and internet-open browsing through remote browser isolation or hardened VDI where available. This is especially useful for exception cases that cannot update promptly; put it in place within 30 days for those holdouts.
- Watch for browser exploit chains — Tune EDR and SOC detections for suspicious browser child processes, memory-protection hits, odd IPC behavior, and credential-store access immediately following Chrome activity. Stand this up within 30 days because this CVE is most dangerous when it appears as stage two of a chain.
- A WAF does not help; this is a client-side browser bug, not a vulnerability in your web server.
- Internet exposure scanning does not answer the question; Shodan/Censys-style tools cannot meaningfully inventory endpoint browser versions for this flaw.
- Email filtering alone is insufficient; the trigger path is browsing to attacker-controlled content, not necessarily opening a malicious attachment.
Crowdsourced verification payload.
Run this on the target endpoint or through your software deployment/EDR scripting channel. Invoke it as python3 chrome_cve_2026_10931_check.py on macOS/Linux or py chrome_cve_2026_10931_check.py on Windows; no admin rights are required if the browser is installed in standard locations.
#!/usr/bin/env python3
# CVE-2026-10931 Chrome version check
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
VERSION_RE = re.compile(r'(\d+\.\d+\.\d+\.\d+)')
FIXED = {
'Windows': (149, 0, 7827, 53),
'Darwin': (149, 0, 7827, 53),
'Linux': (149, 0, 7827, 53),
}
def parse_version(text):
m = VERSION_RE.search(text or '')
if not m:
return None
return tuple(int(x) for x in m.group(1).split('.'))
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 '')
v = parse_version(out)
if v:
return v, out.strip(), ' '.join(cmd)
except Exception:
pass
return None, None, None
def candidate_commands():
system = platform.system()
cmds = []
if system == 'Windows':
local = os.environ.get('LOCALAPPDATA', r'C:\Users\Default\AppData\Local')
pf = os.environ.get('ProgramFiles', r'C:\Program Files')
pfx86 = os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)')
paths = [
Path(local) / 'Google/Chrome/Application/chrome.exe',
Path(pf) / 'Google/Chrome/Application/chrome.exe',
Path(pfx86) / 'Google/Chrome/Application/chrome.exe',
Path(local) / 'Chromium/Application/chrome.exe',
Path(pf) / 'Chromium/Application/chrome.exe',
Path(pfx86) / 'Chromium/Application/chrome.exe',
]
for p in paths:
cmds.append([str(p), '--version'])
elif system == 'Darwin':
paths = [
'/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'),
]
for p in paths:
cmds.append([p, '--version'])
else:
binaries = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome'
]
for b in binaries:
resolved = shutil.which(b)
if resolved:
cmds.append([resolved, '--version'])
common_paths = [
'/usr/bin/google-chrome', '/usr/bin/google-chrome-stable',
'/usr/bin/chromium', '/usr/bin/chromium-browser',
'/opt/google/chrome/chrome'
]
for p in common_paths:
cmds.append([p, '--version'])
return cmds
def main():
system = platform.system()
if system not in FIXED:
print('UNKNOWN: unsupported OS for this check: {}'.format(system))
sys.exit(2)
fixed = FIXED[system]
seen = []
for cmd in candidate_commands():
path = cmd[0]
if not Path(path).exists() and not shutil.which(path):
continue
v, raw, used = run_version(cmd)
if v:
seen.append((v, raw, used))
if not seen:
print('UNKNOWN: Chrome/Chromium not found or version could not be determined')
sys.exit(2)
# Prefer highest discovered version if multiple installs exist.
seen.sort(key=lambda x: x[0], reverse=True)
version, raw, used = seen[0]
print('Detected via: {}'.format(used))
print('Reported version: {}'.format('.'.join(str(x) for x in version)))
print('Raw output: {}'.format(raw))
print('Fixed threshold for {}: {}'.format(system, '.'.join(str(x) for x in fixed)))
if version < fixed:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
- Chromium severity guidelines for security issues
- Chromium Security overview
- Chrome 149 release notes
- Canadian Centre for Cyber Security advisory AV26-544
- CISA Known Exploited Vulnerabilities catalog
- StatCounter browser market share worldwide (May 2026)
- Quanteta CVE-2026-10931 record
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.