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

Integer overflow in Media in Google Chrome prior to 149

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

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.

"Treat it as a high-priority browser patch, not a drop-everything zero-day"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get a user onto attacker-controlled web content

The attacker needs the victim to render a crafted HTML page in Chrome. Delivery is typically phishing, malvertising, SEO poisoning, chat links, or a watering-hole site; no public weaponized kit for this CVE was identified in the reviewed sources.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners will not find this. Coverage comes from browser version inventory, email/web telemetry, and detections for suspicious child processes or post-exploit behavior on the endpoint.
STEP 02

Trigger the FileSystem memory corruption in the renderer

The crafted page exercises the vulnerable FileSystem code path and aims to hit a use-after-free condition. If exploitation is successful, the attacker gets code execution in the Chrome renderer or another sandboxed browser process.
Conditions required:
  • The target executes the vulnerable code path in FileSystem
  • The attacker has a stable exploit for the victim's platform and build
Where this breaks in practice:
  • 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
Detection/coverage: Exploit-specific signatures are unlikely without a public PoC. Browser crash spikes, renderer crashes, and EDR exploit-mitigation alerts are the practical signals.
STEP 03

Escape the browser sandbox

The advisory explicitly says the bug could potentially perform a sandbox escape, which is the difference between a noisy renderer compromise and a meaningful workstation compromise. In practice, the attacker either uses this bug as the escape or chains it with another primitive depending on exploit reliability.
Conditions required:
  • A working exploit primitive beyond simple renderer corruption
  • A path to break out of Chrome's sandbox on the victim platform
Where this breaks in practice:
  • 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
Detection/coverage: Look for browser-to-OS boundary crossings: suspicious browser child processes, memory-injection behavior, token theft attempts, or unexpected file writes from Chrome.
STEP 04

Establish endpoint impact

After escape, the attacker can move into credential theft, persistence, payload staging, or session hijack on that endpoint. The blast radius is usually one user workstation at a time, not a fleet-wide single-shot compromise.
Conditions required:
  • Post-sandbox code execution on the host
  • User context with access to useful sessions, secrets, or internal apps
Where this breaks in practice:
  • 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
Detection/coverage: Strong EDR should catch much of this step. Hunt for Chrome spawning script interpreters, LOLBins, unsigned binaries, or unusual network beacons.
03 · Intelligence Metadata

The supporting signals.

Record sanity checkThe 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 statusNo active exploitation evidence found in the reviewed sources, and not listed in CISA KEV as of the browsed data.
PoC availabilityNo credible public GitHub PoC or exploit write-up surfaced in the reviewed sources. That is meaningful downward pressure for Monday-morning prioritization.
EPSSUser-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 statusNo KEV listing found. That matters because client-side Chrome bugs only jump to emergency status when there is actual campaign evidence.
CVSS vector meaningAV: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 versionsGoogle Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS.
Fixed versionsUpgrade 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 realityThis 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 / reporterPublicly disclosed 2026-06-04. Google credits Andrew Boni in the Chrome 149 desktop advisory.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.3/10)

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.

HIGH CVE identity, affected versions, and fixed versions
MEDIUM Real-world exploitability versus vendor headline severity
MEDIUM Absence of public PoC / exploitation evidence in reviewed sources

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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
Monday morning, treat this as a high-priority endpoint browser update: first, correct the record in your ticketing because the authoritative CVE details currently point to FileSystem use-after-free with potential sandbox escape, not the Media integer-overflow description from the prompt. Then use endpoint inventory to identify Chrome versions below 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

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. NVD - CVE-2026-10886
  3. Chromium issue tracker entry 505096898
  4. CISA Known Exploited Vulnerabilities Catalog
  5. Chromium Security Overview Page
  6. FIRST EPSS API documentation
  7. FIRST EPSS overview
  8. Canadian Centre for Cyber Security advisory for Chrome 149 updates
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.