This is a booby-trapped webpage that still has to get past the seatbelt before it crashes the car
The user-supplied intel does not match the current authoritative record for CVE-2026-10886. Google and NVD currently describe it as a use-after-free in FileSystem, not an integer overflow in Media. Affected versions are Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS; the advisory says a remote attacker can trigger it with a crafted HTML page and potentially perform a sandbox escape.
Vendor labeling says *Critical* in Chromium terms, and the CISA ADP vector lands at 9.6 because the advisory implies post-renderer escape potential. In enterprise reality, that still overstates immediate patch urgency: this is a client-side browser bug that requires user interaction and a reliable exploit chain, and there is no KEV listing, no public exploitation evidence, and no public PoC in the sources reviewed. That keeps it firmly urgent, but not in the same bucket as unauthenticated internet-facing server RCE.
4 steps from start to impact.
Get a user onto attacker-controlled web content
- Unauthenticated remote reach to the victim through normal web browsing
- A Chrome user opens or is redirected to attacker-controlled content
- The endpoint is running a vulnerable Chrome build
- Requires user interaction; this is not a spray-the-internet server bug
- URL filtering, Safe Browsing, email security, and user training cut down delivery success
- Managed enterprises often auto-update Chrome quickly, shrinking the window
Trigger the FileSystem memory corruption in the renderer
- The target executes the vulnerable code path in FileSystem
- The attacker has a stable exploit for the victim's platform and build
- Modern Chrome hardening and allocator behavior make reliability harder than the CVSS headline suggests
- Exploit reliability may vary by OS, architecture, and exact point release
Escape the browser sandbox
- A working exploit primitive beyond simple renderer corruption
- A path to break out of Chrome's sandbox on the victim platform
- This is the biggest real-world brake on severity: reliable sandbox escape is materially harder than renderer-only code execution
- OS exploit mitigations and EDR behavior prevention increase failure rate
Establish endpoint impact
- Post-sandbox code execution on the host
- User context with access to useful sessions, secrets, or internal apps
- Impact is bounded to the compromised endpoint unless the attacker can pivot further
- EDR, browser isolation, and application control can still break the chain after initial success
The supporting signals.
| Record sanity check | The prompt's title/CWE/vector do not align with the current authoritative record. Official sources currently describe CVE-2026-10886 as Use after free in FileSystem with CWE-416 and an ADP vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. |
|---|---|
| In-the-wild status | No active exploitation evidence found in the reviewed sources, and not listed in CISA KEV as of the browsed data. |
| PoC availability | No credible public GitHub PoC or exploit write-up surfaced in the reviewed sources. That is meaningful downward pressure for Monday-morning prioritization. |
| EPSS | User-supplied EPSS is 0.0008; third-party aggregation also shows an extremely low score (~0.07% probability language). Either way, this is low statistical exploitation likelihood right now, not a hot exploit signal. |
| KEV status | No KEV listing found. That matters because client-side Chrome bugs only jump to emergency status when there is actual campaign evidence. |
| CVSS vector meaning | AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H means remote, no auth, but user interaction required and the impact assumes crossing a trust boundary. That is why the theoretical score is severe while real-world urgency is a notch lower. |
| Affected versions | Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. |
| 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 Android 149.0.7827.59 inherits the desktop security fixes per Google's release notes. |
| Scanning / exposure reality | This is an endpoint/browser exposure problem, not an internet-facing service footprint. *Inference from product type:* Shodan/Censys/FOFA-style exposure counts are the wrong lens here; your authoritative dataset is endpoint inventory and browser version telemetry. |
| Disclosure / reporter | Publicly disclosed 2026-06-04. Google credits Andrew Boni in the Chrome 149 desktop advisory. |
noisgate verdict.
The single biggest reason this stays HIGH instead of CRITICAL is that exploitation still depends on a user rendering malicious web content and then achieving a reliable browser-to-host escape path. What keeps it out of MEDIUM is Chrome's enormous endpoint footprint and the advisory's explicit sandbox escape potential, which can turn a routine browse into real workstation compromise.
Why this verdict
- Start from 9.6, then discount for UI:R: the official record is critical on paper, but this still requires a victim to browse to attacker content, which narrows reachable population versus unauthenticated server RCE.
- Discount again for chain reliability: a browser memory bug is one thing; a *reliable* sandbox escape across enterprise builds is materially harder and often where campaigns fail.
- Hold it at HIGH because Chrome is everywhere: unlike niche software, Chrome is deployed broadly across enterprise endpoints, so the reachable target population is huge even though the attack is client-side.
- No KEV, no campaign evidence, low EPSS: there is no current signal that defenders should treat this like an actively burning zero-day.
- Do not downgrade to MEDIUM: the advisory's stated ability to *potentially perform a sandbox escape* means the upside for an attacker is still host compromise, not just a renderer crash.
Why not higher?
There is no verified in-the-wild exploitation, no KEV listing, and no public PoC in the sources reviewed. More importantly, the attack requires user interaction and a dependable post-renderer escape path, which is materially less immediate than internet-exposed server bugs that hand over systems on first packet.
Why not lower?
This is still a remotely triggerable Chrome memory corruption issue in one of the most widely deployed client applications in the enterprise. If the exploit is stable, the blast radius at the endpoint level is serious enough that treating it as backlog hygiene would be too casual.
What to do — in priority order.
- Force Chrome auto-update and relaunch — Use your browser management stack to push Chrome onto the fixed build and enforce restart prompts where policy allows. For a HIGH verdict, deploy this mitigation within 30 days if patch rollout is staggered; it directly shrinks the vulnerable population.
- Prioritize high-risk browsing tiers — Patch first on admin workstations, developers, finance, executives, help desk, and users with broad SaaS session access. Those personas turn a browser compromise into higher-value credential theft and lateral movement; complete this prioritization within 30 days.
- Use browser isolation or remote browsing where already deployed — If you already have RBI or equivalent isolation for risky destinations, route uncategorized or high-risk web traffic through it while the patch wave completes. For a HIGH verdict, apply this compensating control within 30 days.
- Tighten browser-child-process controls — Use EDR or application control to block or alert on Chrome spawning script engines, LOLBins, or unsigned executables. This does not fix the bug, but it breaks common post-exploit moves; deploy within 30 days.
- Verify fleet version coverage from endpoint telemetry — Track Chrome versions through EDR, MDM, GPO, package management, or software inventory rather than relying on network scanners. For a HIGH verdict, establish verified coverage within 30 days so you know where the risk remains.
- A WAF does not help; the exploit lands in the browser client, not your web applications.
- Perimeter vulnerability scanning does not help; there is no server-side listening service to probe for this bug.
- MFA is valuable for account abuse after compromise, but it does not stop initial browser exploitation on the endpoint.
- Relying on browser crash telemetry alone is weak; successful exploitation may not crash at all.
Crowdsourced verification payload.
Run this on the target endpoint through your EDR remote shell, software inventory agent, or a local terminal. Invoke with python3 check_cve_2026_10886_chrome.py on macOS/Linux or py check_cve_2026_10886_chrome.py on Windows; standard user rights are usually enough because it only reads installed version data from common paths and registry locations.
#!/usr/bin/env python3
# check_cve_2026_10886_chrome.py
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET = (149, 0, 7827, 53)
def parse_version(s):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_version(a, b):
return (a > b) - (a < b)
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_version_windows():
candidates = []
# Registry uninstall keys
reg_paths = [
r'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome',
r'HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome',
r'HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome',
]
for rp in reg_paths:
out = run_cmd(['reg', 'query', rp, '/v', 'DisplayVersion'])
v = parse_version(out)
if v:
candidates.append(v)
# Common file paths
envs = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData'),
]
rels = [
os.path.join('Google', 'Chrome', 'Application', 'chrome.exe'),
]
for base in envs:
if not base:
continue
for rel in rels:
path = os.path.join(base, rel)
if os.path.exists(path):
out = run_cmd(['wmic', 'datafile', 'where', 'name="{}"'.format(path.replace('\\', '\\\\')), 'get', 'Version', '/value'])
v = parse_version(out)
if v:
candidates.append(v)
return max(candidates) if candidates else None
def get_version_macos():
path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if not os.path.exists(path):
return None
out = run_cmd([path, '--version'])
return parse_version(out)
def get_version_linux():
bins = ['google-chrome', 'google-chrome-stable', '/opt/google/chrome/chrome']
for b in bins:
cmd = [b, '--version'] if not b.startswith('/') else [b, '--version']
if b.startswith('/') and not os.path.exists(b):
continue
if not b.startswith('/') and shutil.which(b) is None:
continue
out = run_cmd(cmd)
v = parse_version(out)
if v:
return v
return None
def main():
system = platform.system().lower()
version = None
if 'windows' in system:
version = get_version_windows()
elif 'darwin' in system:
version = get_version_macos()
elif 'linux' in system:
version = get_version_linux()
if not version:
print('UNKNOWN - Google Chrome version not found')
sys.exit(2)
if cmp_version(version, TARGET) < 0:
print('VULNERABLE - Google Chrome version {} is older than 149.0.7827.53'.format('.'.join(map(str, version))))
sys.exit(1)
else:
print('PATCHED - Google Chrome version {} is at or above 149.0.7827.53'.format('.'.join(map(str, version))))
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 and push restart-enforced browser updates across the fleet; if you cannot fully patch immediately, apply compensating controls such as browser isolation for risky traffic and tightened browser child-process controls within the noisgate mitigation SLA of 30 days, and complete vendor patching inside the noisgate remediation SLA of 180 days.Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- NVD - CVE-2026-10886
- Chromium issue tracker entry 505096898
- CISA Known Exploited Vulnerabilities Catalog
- Chromium Security Overview Page
- FIRST EPSS API documentation
- FIRST EPSS overview
- Canadian Centre for Cyber Security advisory for Chrome 149 updates
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.