← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-10931 · CWE-416 · Disclosed 2026-06-04

Use after free in FileSystem in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"= ASSESSED AT HIGH: dangerous as a chainable sandbox escape, but not a standalone browser-to-host break"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a renderer foothold first

Weaponized tool: custom malicious HTML/JS plus a separate renderer bug. The published Chrome text describes this as a sandbox-escape style issue; I infer the attacker first needs code execution or memory corruption inside a renderer, because Chromium rates renderer-precondition sandbox escapes as High rather than Critical. In practice this means CVE-2026-10931 is usually the second bug in a chain, not the initial compromise.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners will miss this entirely. Detection is mainly via browser crash telemetry, EDR signals on browser exploit behavior, and software inventory showing affected versions.
STEP 02

Trigger the FileSystem use-after-free

Weaponized tool: crafted HTML page targeting the FileSystem component. Once a renderer foothold exists, the attacker drives the vulnerable FileSystem code path to produce a dangling-pointer condition and attempts controlled heap reuse. Public issue details remain restricted, so reliability specifics are not visible yet.
Conditions required:
  • Successful access to the vulnerable FileSystem code path
  • Memory layout favorable enough to turn a UAF into a usable primitive
  • Affected version still deployed
Where this breaks in practice:
  • 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
Detection/coverage: Most commercial scanners can only do version-based detection here. No dependable network signature should be expected.
STEP 03

Cross the sandbox boundary

Weaponized tool: browser exploit chain from compromised renderer into a more privileged Chrome process. The value of this CVE is that it can move an attacker from a sandboxed web-content context toward browser-level or host-adjacent access, which is exactly why sandbox escapes stay important even when they are not initial-entry bugs. On some platforms the exact landing process and available privileges vary, so post-trigger impact is platform-dependent.
Conditions required:
  • Renderer-level execution or equivalent primitive already obtained
  • Successful exploitation of the FileSystem UAF
  • Target platform/process architecture permits meaningful privilege transition
Where this breaks in practice:
  • 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
Detection/coverage: Look for anomalous browser process behavior, suspicious child-process launches, odd broker/IPC use, or exploit-prevention hits in EDR.
STEP 04

Act on the endpoint

Weaponized tool: post-escape payload chosen by the operator. Once the sandbox boundary is broken, the attacker can pivot into credential theft, local data access, or follow-on user-context execution depending on what the chain delivers. The enterprise impact comes from Chrome's massive footprint across user workstations, not from internet-exposed service count.
Conditions required:
  • Sandbox escape succeeded
  • Useful post-escape objective exists on the host
  • User context provides access to targeted data or sessions
Where this breaks in practice:
  • 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
Detection/coverage: EDR should have the best shot here; watch for token theft, browser data access, unusual process injection, and persistence attempts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityNo public PoC repo or exploit write-up found. The Chromium issue exists as 501115599, but detailed internals appear restricted, which meaningfully slows copycat weaponization.
EPSSUser-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 statusNo. There is no KEV entry date because the CVE is not present in the CISA KEV catalog.
CVSS / vectorNo 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 versionsChrome 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 versionsUpgrade 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 realityThis 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 / reporterThe 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 qualityThe 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.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.8/10)

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.

HIGH Affected/fixed version mapping
MEDIUM Severity bucket based on Chromium's sandbox-escape guidance
LOW Exact exploitation mechanics due to restricted upstream bug details

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, pull a browser version inventory from your endpoint platform, identify every Chrome install below 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS, and move those systems into your fast browser-update ring. There is no active-exploitation override here, so follow the noisgate mitigation SLA for a HIGH finding by putting compensating controls on exception systems within 30 days, and complete the actual Chrome update across the fleet within 180 days under the noisgate remediation SLA—though for a browser this widely deployed, most teams should finish far earlier than the outer limit.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
  2. Chromium severity guidelines for security issues
  3. Chromium Security overview
  4. Chrome 149 release notes
  5. Canadian Centre for Cyber Security advisory AV26-544
  6. CISA Known Exploited Vulnerabilities catalog
  7. StatCounter browser market share worldwide (May 2026)
  8. Quanteta CVE-2026-10931 record
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.