← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-10886 · 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 a loaded nail gun left on every employee desk, but it still needs the user to pick it up and the attacker to aim perfectly

CVE-2026-10886 is a use-after-free in Chrome FileSystem fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. Google lists it as affecting Chrome prior to those builds, and the vendor description plus CVSS imply a remote attacker can drive memory corruption from malicious web content with user interaction required.

Google's 9.6 / CRITICAL label is understandable in a lab because browser memory corruption plus scope change can mean full compromise. In the field, though, this is not the same as an unauthenticated server-side RCE: the attacker still needs a user to hit malicious content, then needs a reliable exploit path through modern Chrome hardening, and there is no KEV listing, no public exploitation evidence, and no public weaponized PoC surfaced from the sources reviewed.

"Internet-facing client bug, but still a click-to-own browser chain with no KEV, no public PoC, and hard modern exploit reliability."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get a user onto attacker-controlled web content

Weaponized tool: custom phishing page / malvertising redirect; no public exploit kit was identified for this CVE. The attacker must deliver a crafted page or equivalent browser-reachable content to a target running Chrome below 149.0.7827.53/54. In an enterprise, this usually means phishing, ad-tech abuse, or compromised legitimate sites rather than direct network reachability.
Conditions required:
  • Target uses vulnerable Chrome build
  • Target visits attacker-controlled or attacker-influenced content
  • Browser auto-update has not already moved the endpoint forward
Where this breaks in practice:
  • Requires UI:R; this is not a no-click daemon flaw
  • Email security, DNS filtering, SWG, and browser isolation can break delivery
  • Chrome's auto-update shrinks dwell time on managed fleets
Detection/coverage: Web proxies, DNS logs, secure web gateways, and browser telemetry can usually see the delivery stage; CVE-specific scanner coverage here is weak because the first problem is simply version exposure.
STEP 02

Trigger the FileSystem use-after-free

Weaponized tool: crafted HTML/JavaScript exploit primitive; no public repo or off-the-shelf module was found. The malicious content has to drive Chrome's FileSystem code into a stale-object state and turn that into controlled memory corruption. That is technically plausible, but browser exploit reliability is much harder than the CVSS string makes it look.
Conditions required:
  • Victim renders the malicious content in vulnerable Chrome
  • Exploit path reaches the affected FileSystem code path
  • Attacker has a working primitive for this exact build family
Where this breaks in practice:
  • Chrome memory hardening, allocator behavior, and version drift make reliable exploitation brittle
  • Exploit often needs build-specific offsets/timing
  • Crash-only outcomes are more common than clean control-flow hijack in poorly matured browser exploits
Detection/coverage: Version scanners can flag vulnerable Chrome builds. Runtime detection is harder; EDR may only see a browser crash, anomalous child process, or suspicious memory behavior rather than a signature for CVE-2026-10886 itself.
STEP 03

Convert memory corruption into sandbox escape / privileged execution

Weaponized tool: custom post-corruption exploit chain; no public chain was identified. The vendor title and CVSS imply scope-changing impact, but in practice the attacker must convert the bug into execution that crosses Chrome's renderer sandbox boundary or lands in a more privileged browser context. That is the decisive amplifier technically, but also the decisive friction operationally.
Conditions required:
  • Successful memory corruption with control, not just crash
  • A viable path past renderer containment or into a privileged process
  • Target defenses do not interrupt unusual browser child-process or token activity
Where this breaks in practice:
  • Modern Chrome sandboxing, CFI-style hardening, and process isolation raise the exploit-development bar
  • Many enterprises run EDR that will catch obvious post-browser execution
  • A single bug does not automatically equal reliable whole-host compromise at scale
Detection/coverage: EDR has the best chance here: suspicious browser child processes, token abuse, LOLBin spawning, memory tampering, or persistence attempts. Network IDS is usually blind once the exploit is inside the browser.
STEP 04

Run payloads or steal enterprise data

Weaponized tool: custom infostealer / remote shell payload. If the attacker gets code execution beyond the sandbox, the next move is credential theft, session hijack, lateral movement staging, or installing a lightweight implant. The blast radius becomes meaningful because browsers sit next to SSO cookies, SaaS sessions, and user trust paths.
Conditions required:
  • Successful post-sandbox execution
  • User context has access to interesting SaaS, files, or internal apps
  • Payload delivery is not blocked by application control
Where this breaks in practice:
  • Least-privilege user accounts limit OS-level blast radius
  • EDR, MFA, and browser session protections can reduce monetizable outcomes
  • Payload staging is noisy compared with the initial browser crash/trigger stage
Detection/coverage: Strong EDR, identity telemetry, and cloud app detections matter more than network scanners once the attack reaches this stage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the reviewed sources, and the user-provided intel says KEV listed: No.
KEV statusNot in CISA KEV as of this assessment; browser Chrome entries do exist in KEV historically, which matters because this one is not there.
EPSS0.00068 from the user-provided intel — extremely low relative likelihood of observed exploitation in the next 30 days.
Vendor severity vs realityVendor labels it CRITICAL / 9.6 with AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. I downgrade to HIGH because UI:R plus exploit-chain reliability against modern Chrome materially narrows real-world abuse.
Affected versionsGoogle says Chrome prior to 149.0.7827.53 (Linux) and prior to 149.0.7827.53/54 (Windows/Mac).
Fixed versionsPatch level is 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. Early stable reached a small percentage of users on 2026-05-29; broad stable post is 2026-06-02.
Disclosure / reportingGoogle stable advisory published 2026-06-02; Google lists the bug as reported by Andrew Boni on 2026-04-21.
Proof-of-concept availabilityNo public PoC or GitHub exploit repo found in the reviewed sources. That does not make it safe, but it does cut copy-paste attacker volume.
Exposure / scanning realityClient-side browser issue: Shodan/Censys/GreyNoise style internet scanning is largely not applicable because Chrome endpoints are not normally directly fingerprintable as a remotely reachable service. Exposure is measured by endpoint version inventory, not external IP census.
Population and blast radiusPopulation is broad because Chrome is common across enterprises, but blast radius starts at one user session and only becomes enterprise-significant if the attacker clears the sandbox and lands useful identity material or code execution.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.2/10)

The single biggest reason this is HIGH instead of CRITICAL is that the attacker still needs a user to render malicious content and then needs a reliable browser exploit chain against modern Chrome defenses. Mass deployment of Chrome is an amplifier, but the absence of KEV/public exploitation and the exploit maturity required to convert a FileSystem UAF into a dependable sandbox escape keep this out of the top bucket.

HIGH Affected version boundary and fixed builds
MEDIUM Assessment that real-world severity is below vendor CRITICAL
LOW Exact exploit path details beyond what Google publicly disclosed

Why this verdict

  • Downward adjustment: requires user interaction — this is a browser-content bug, not a no-click service exploit; the attacker needs the victim to hit malicious content.
  • Downward adjustment: exploit reliability is hard — a Chrome UAF is dangerous, but turning it into stable, cross-build sandbox escape against modern browser hardening is specialist work, not commodity work.
  • Upward adjustment: Chrome is everywhere — if a working exploit exists, reachable population is huge because browsers are universal and sit next to identity tokens, SaaS sessions, and trusted user workflows.
  • Downward adjustment: no current threat signal — no KEV listing, no public in-the-wild confirmation, and no public PoC found.
  • Upward adjustment: scope-changing impact is plausible — the vendor vector claims S:C and full C/I/A impact, so this is not patch-later hygiene even after downgrading.

Why not higher?

I did not leave this at CRITICAL because the path assumes both victim interaction and successful exploit maturation through Chrome's sandboxing and memory-hardening layers. In practice that is a much smaller and noisier attacker set than the population that can abuse a remotely reachable unauthenticated server bug.

Why not lower?

I did not push this to MEDIUM because this is still a memory-corruption bug in the dominant enterprise browser, with vendor-assessed scope change and potentially severe post-compromise outcomes. If an attacker has a working exploit, the user-to-identity payoff is real even without broad internet scan visibility.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update compliance — Use enterprise policy or your endpoint platform to verify Chrome update channels are healthy and that endpoints can actually reach Google's update infrastructure. For a HIGH verdict, deploy and validate this control within 30 days, with special focus on VDI images, kiosks, lab systems, and unmanaged remote laptops that often drift behind.
  2. Block or isolate unpatched browsers — Use EDR, NAC, conditional access, VDI posture checks, or SWG policy to restrict access for endpoints still below 149.0.7827.53/54. For a HIGH verdict, have the temporary enforcement path in place within 30 days so stale clients cannot linger indefinitely.
  3. Harden web delivery paths — Raise phishing-resistant controls around malicious page delivery: secure web gateway filtering, DNS filtering, browser isolation for high-risk users, and ad/malvertising suppression. These are compensating controls, not substitutes; for a HIGH verdict, tighten them within 30 days for the most exposed user groups first.
  4. Tune EDR for browser child-process abuse — Alert on chrome.exe or Chrome child processes spawning unusual binaries, script interpreters, or LOLBins, and review browser crash clusters after suspicious web activity. For a HIGH verdict, deploy or validate these detections within 30 days because post-exploitation is where defenders still have leverage.
  5. Prioritize high-risk user cohorts — Front-load executives, finance, admins, help desk, developers, and users who routinely touch unknown external content. For a HIGH verdict, complete that prioritization within 30 days even if full fleet hygiene takes longer.
What doesn't work
  • A network perimeter scanner does not solve this; Chrome is a client application, so you need endpoint version inventory rather than external port scanning.
  • A WAF is irrelevant here because the attack target is the user's browser, not your web server.
  • MFA alone does not prevent exploit trigger or local browser compromise; it only limits some downstream identity abuse.
  • Generic 'user awareness' training is not enough on its own; drive-by and malvertising delivery paths do not rely on obviously suspicious emails.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your EDR/management agent with standard user rights; admin is only needed if your tooling restricts registry reads on Windows. Invoke it with python3 check_chrome_cve_2026_10886.py on macOS/Linux or py check_chrome_cve_2026_10886.py on Windows. It checks common Chrome install locations and outputs VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_10886.py
# Detects whether installed Google Chrome is below the fixed versions for CVE-2026-10886.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from pathlib import Path

FIX_LINUX = (149, 0, 7827, 53)
FIX_WIN_MAC = (149, 0, 7827, 53)  # Treat .53 and .54 as patched; anything below .53 is vulnerable.


def parse_version(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def version_str(v):
    return '.'.join(str(x) for x in v) if v else 'unknown'


def cmp_version(a, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.DEVNULL, text=True).strip()
        return out
    except Exception:
        return None


def find_windows_version():
    # Try registry first
    try:
        import winreg
        reg_paths = [
            r'SOFTWARE\Google\Chrome\BLBeacon',
            r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'
        ]
        for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
            for reg_path in reg_paths:
                try:
                    key = winreg.OpenKey(hive, reg_path)
                    val, _ = winreg.QueryValueEx(key, 'version')
                    v = parse_version(val)
                    if v:
                        return v, 'registry'
                except Exception:
                    pass
    except Exception:
        pass

    # Fallback to executable paths
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]
    for exe in candidates:
        if exe and Path(exe).exists():
            out = run_cmd([exe, '--version'])
            v = parse_version(out or '')
            if v:
                return v, exe
    return None, None


def find_macos_version():
    app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if Path(app).exists():
        out = run_cmd([app, '--version'])
        v = parse_version(out or '')
        if v:
            return v, app
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if Path(plist).exists():
        out = run_cmd(['/usr/libexec/PlistBuddy', '-c', 'Print :CFBundleShortVersionString', plist])
        v = parse_version(out or '')
        if v:
            return v, plist
    return None, None


def find_linux_version():
    candidates = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']
    for cmd in candidates:
        out = run_cmd([cmd, '--version'])
        v = parse_version(out or '')
        if v:
            return v, cmd
    desktop_paths = [
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable'
    ]
    for exe in desktop_paths:
        if Path(exe).exists():
            out = run_cmd([exe, '--version'])
            v = parse_version(out or '')
            if v:
                return v, exe
    return None, None


def main():
    sysname = platform.system().lower()
    if 'windows' in sysname:
        version, source = find_windows_version()
        fixed = FIX_WIN_MAC
    elif 'darwin' in sysname:
        version, source = find_macos_version()
        fixed = FIX_WIN_MAC
    elif 'linux' in sysname:
        version, source = find_linux_version()
        fixed = FIX_LINUX
    else:
        print('UNKNOWN: unsupported platform {}'.format(platform.system()))
        sys.exit(2)

    if not version:
        print('UNKNOWN: Google Chrome version not found')
        sys.exit(2)

    if cmp_version(version, fixed) < 0:
        print('VULNERABLE: installed Chrome {} from {} is below fixed {}'.format(version_str(version), source, version_str(fixed)))
        sys.exit(1)
    else:
        print('PATCHED: installed Chrome {} from {} meets or exceeds fixed {}'.format(version_str(version), source, version_str(fixed)))
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a broad client-side HIGH, not a hair-on-fire CRITICAL server bug: use endpoint inventory to find Chrome builds below 149.0.7827.53/54, validate update channels, and push policy-based browser updates first to high-risk users, kiosks, VDI gold images, and devices that miss auto-update. Per the noisgate mitigation SLA, put compensating controls in place within 30 days by forcing update compliance and restricting stale browsers where you can; per the noisgate remediation SLA, complete rollout of the actual vendor-fixed Chrome builds within 180 days, though any managed browser fleet should finish far sooner if it's healthy.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (2026-06-02)
  2. Google Chrome Releases - Early Stable Update for Desktop (2026-05-29)
  3. Chromium Security Page
  4. CISA Known Exploited Vulnerabilities Catalog
  5. Google Chrome security advisory AV26-544 (Canadian Centre for Cyber Security)
  6. CVE Record
  7. NVD entry
  8. FIRST EPSS API documentation
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.