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

Use after free in Chromoting in Google Chrome prior to 149

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

This is a booby-trapped side door, not a fire through the whole browser

CVE-2026-10893 is a use-after-free in Chrome's Chromoting code path. Google shipped the fix in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/Mac in the June 2, 2026 stable release, with early-stable bits landing May 29, 2026. In plain English: if an attacker can feed malformed Chromoting traffic into a vulnerable client, they may be able to turn memory corruption into code execution.

The vendor's Critical label reflects the bug class and possible impact, but for enterprise prioritization that overstates the average fleet risk. This is not a generic browse-to-own renderer bug affecting every employee who opens a tab; it is gated by Chromoting reachability and usage, which sharply narrows the exposed population. That keeps it in HIGH, not CRITICAL, for most 10,000-host environments.

"ASSESSED AT HIGH: real RCE class bug, but the attack surface is Chromoting, not every Chrome session."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach a live Chromoting client

The attacker first needs a victim endpoint running vulnerable Chrome and using the Chromoting feature set. In practice that means a Chrome Remote Desktop or related remoting workflow where the victim connects to an attacker-controlled peer, or the attacker can otherwise influence remoting traffic.
Conditions required:
  • Target is on Chrome earlier than 149.0.7827.53/54
  • Chromoting is installed, enabled, or actively used
  • Attacker can get traffic or content into that remoting path
Where this breaks in practice:
  • Most enterprise Chrome users never touch Chromoting
  • This is not broadly internet-reachable like a server daemon
  • User action or an existing remoting relationship is likely required
Detection/coverage: Asset scanners can find vulnerable Chrome versions, but they usually cannot prove real reachability to the Chromoting code path.
STEP 02

Deliver malformed remoting data

A custom malicious Chromoting endpoint, relay abuse, or traffic-manipulation setup would send crafted protocol data intended to exercise the freed object. The weaponized tool here is effectively a custom malicious Chromoting peer/proxy, not an off-the-shelf public exploit kit.
Conditions required:
  • Attacker controls the remote side or can tamper with remoting traffic
  • Victim session reaches the vulnerable parser/state machine
Where this breaks in practice:
  • No public PoC was found
  • Restricted Chromium issue details raise attacker development cost
  • Modern TLS/session protections may limit on-path opportunities
Detection/coverage: Network IDS coverage is likely weak unless you already decode and baseline Chromoting traffic patterns.
STEP 03

Trigger the use-after-free

The malformed input causes a freed object to be referenced again, creating memory corruption. Turning that into controlled execution is plausible because this is a classic browser memory-safety primitive, but it still requires exploit engineering and reliability work.
Conditions required:
  • Precise malformed input reaches the vulnerable object lifecycle
  • Target build and platform behave as expected for the exploit
Where this breaks in practice:
  • UAF exploitation reliability varies by platform and allocator behavior
  • Chrome hardening raises the bar for stable code execution
Detection/coverage: Crash telemetry, browser minidumps, and EDR child-process anomalies are your best signals; signature-based detection is poor.
STEP 04

Land code execution and follow-on access

If exploitation succeeds, the attacker gains code execution in the Chrome context associated with the vulnerable component and can pivot into credential theft, session theft, or a second-stage payload. Depending on exact process boundaries, a full host takeover may still require an additional sandbox escape or local privilege step.
Conditions required:
  • Exploit achieves instruction control instead of a crash
  • Any required sandbox-bypass or post-exec chain is available
Where this breaks in practice:
  • Exact post-exploitation blast radius is unclear because bug details remain restricted
  • EDR often catches the noisy second stage even if it misses the initial memory bug
Detection/coverage: EDR should catch suspicious payload staging, LOLBin abuse, or anomalous browser child processes better than it catches the memory corruption itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found, and not listed in CISA KEV as of June 5, 2026.
Public PoC availabilityNo public proof-of-concept located. The Chromium issue for this CVE resolves to a restricted bug URL, which increases attacker development friction.
EPSS0.00038 from your supplied intel; that is an *extremely low* short-term exploitation probability signal.
KEV statusNo. There is no CISA KEV entry for CVE-2026-10893.
Vendor severity / scoreGoogle lists the bug as Critical in the Chrome 149 stable notes, but publishes no CVSS score.
CVSS vector interpretationNo official vector exists. Inference only: the likely shape is roughly AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H *if* attacker-controlled Chromoting traffic is sufficient to trigger the flaw.
Affected versionsVulnerable before the fixed Chrome 149 builds. Vendor release notes show 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/Mac as the patched line.
Fixed versionsPatch floor is 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac). Early-stable bits shipped on 2026-05-29; broad stable notes published on 2026-06-02.
Scanning / exposure realityThis is a client-side browser bug, not a listening service. Shodan/Censys/FOFA-style exposure counts are mostly irrelevant; what matters is fleet versioning plus Chromoting usage.
Reporting source / disclosure timingGoogle says it was reported by Google on 2026-05-14 and publicly listed in the Chrome stable notes on 2026-06-02. Your supplied 2026-06-04 date likely reflects downstream indexing rather than first vendor disclosure.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.2/10)

The decisive factor is reachability: this bug sits behind the Chromoting feature path, not the normal web browsing path used by every Chrome user. That sharply reduces exposed population even though the underlying bug class is capable of remote code execution.

HIGH Affected/fixed version ranges and vendor disclosure dates
MEDIUM Attack-path reachability and real-world exploit preconditions
LOW Exact exploit mechanics and final process/sandbox impact because issue details remain restricted

Why this verdict

  • Reachability discount: start from a vendor-style Critical mindset because UAF + possible RCE in Chrome is serious, then cut it down because this is Chromoting-reachable, not every-tab reachable.
  • User/session gating: the attacker likely needs the victim to actually use Chrome Remote Desktop / Chromoting or to accept a remoting relationship, which implies a smaller exposed slice of the fleet and likely some user participation.
  • Weak threat signal: no KEV listing, no public PoC, and the supplied EPSS 0.00038 all argue against emergency-everywhere behavior.

Why not higher?

This does not look like a blanket browse-to-RCE against the general web surface. The practical prerequisites stack up: Chromoting must be present, reachable, and used in a way the attacker can influence, and that compounds downward pressure on severity.

Why not lower?

It is still a memory-safety RCE-class bug in Chrome, not a cosmetic or low-impact logic flaw. If your environment uses Chrome Remote Desktop for help desk, admin access, contractors, or remote support, the vulnerable subset deserves focused attention because successful exploitation could still end in code execution on a user endpoint.

05 · Compensating Control

What to do — in priority order.

  1. Disable unused Chromoting — If Chrome Remote Desktop or related remoting workflows are not business-critical, turn them off by policy or remove the extension/service on managed endpoints. For a HIGH verdict, deploy this compensating control within 30 days on the subset that does not need remoting.
  2. Restrict remoting traffic — Limit Chromoting use to approved support workflows, managed identities, and approved egress paths so random endpoints cannot start or receive ad hoc remoting sessions. Apply these controls within 30 days for fleets that must keep the feature enabled.
  3. Prioritize remoting-enabled hosts — Tag endpoints with Chrome Remote Desktop/Chromoting installed or recently executed and move them to the front of your browser patch wave. This narrows the real risk faster than treating all Chrome endpoints as equally exposed, and it should be operationalized within 30 days.
  4. Alert on browser crash clusters — Watch for repeated chrome crashes, remoting-related process starts, and suspicious browser child processes on machines that use support remoting. This will not prevent exploitation, but it gives you a chance to catch failed attempts and noisy second stages within 30 days.
What doesn't work
  • A WAF does not help; the vulnerable surface is a client-side Chromoting code path, not your web app.
  • External attack-surface management will miss the real problem because there is no public listening service to fingerprint on most endpoints.
  • Blocking generic inbound internet traffic alone is not enough if the attack rides over approved remoting workflows or attacker-controlled support sessions.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint itself, or push it through your EDR/live-response framework. Invoke it as python3 check_cve_2026_10893.py on macOS/Linux or py -3 check_cve_2026_10893.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe" on Windows; standard user rights are usually enough because it only reads version metadata and executes --version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_10893.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import argparse
import os
import platform
import re
import shutil
import subprocess
import sys
from typing import List, Optional, Tuple

PATCH_FLOOR = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_ver(text: str) -> Optional[Tuple[int, int, int, int]]:
    m = VERSION_RE.search(text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def ver_to_str(ver: Tuple[int, int, int, int]) -> str:
    return '.'.join(str(x) for x in ver)


def run_version_cmd(path: str) -> Optional[Tuple[int, int, int, int]]:
    try:
        cp = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=8)
        out = (cp.stdout or '') + ' ' + (cp.stderr or '')
        return parse_ver(out)
    except Exception:
        return None


def read_macos_plist(app_path: str) -> Optional[Tuple[int, int, int, int]]:
    plist = os.path.join(app_path, 'Contents', 'Info.plist') if app_path.endswith('.app') else None
    if not plist or not os.path.exists(plist):
        return None
    try:
        cp = subprocess.run(['defaults', 'read', plist, 'CFBundleShortVersionString'], capture_output=True, text=True, timeout=8)
        if cp.returncode == 0:
            return parse_ver(cp.stdout)
    except Exception:
        pass
    return None


def windows_candidates() -> List[str]:
    cands = []
    envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
    suffixes = [
        r'Google\Chrome\Application\chrome.exe',
        r'Chromium\Application\chrome.exe',
        r'Microsoft\Edge\Application\msedge.exe'
    ]
    for base in envs:
        if not base:
            continue
        for s in suffixes:
            p = os.path.join(base, *s.split('\\'))
            if os.path.exists(p):
                cands.append(p)
    return cands


def macos_candidates() -> List[str]:
    return [
        '/Applications/Google Chrome.app',
        '/Applications/Chromium.app',
        '/Applications/Microsoft Edge.app'
    ]


def linux_candidates() -> List[str]:
    names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'microsoft-edge', 'microsoft-edge-stable']
    found = []
    for n in names:
        p = shutil.which(n)
        if p:
            found.append(p)
    return found


def detect_candidates(user_path: Optional[str]) -> List[str]:
    if user_path:
        return [user_path]
    system = platform.system().lower()
    if 'windows' in system:
        return windows_candidates()
    if 'darwin' in system:
        return macos_candidates()
    return linux_candidates()


def get_version(path: str) -> Optional[Tuple[int, int, int, int]]:
    if platform.system().lower() == 'darwin' and path.endswith('.app'):
        v = read_macos_plist(path)
        if v:
            return v
        path = os.path.join(path, 'Contents', 'MacOS', 'Google Chrome')
        if not os.path.exists(path):
            path = os.path.join(os.path.dirname(path), 'Chromium')
        if not os.path.exists(path):
            path = os.path.join(os.path.dirname(path), 'Microsoft Edge')
    return run_version_cmd(path)


def main() -> int:
    ap = argparse.ArgumentParser(description='Check local browser version against CVE-2026-10893 patch floor')
    ap.add_argument('--path', help='Exact browser binary or .app path to inspect')
    args = ap.parse_args()

    candidates = detect_candidates(args.path)
    if not candidates:
        print('UNKNOWN: no supported Chrome/Chromium/Edge executable found')
        return 2

    checked = []
    vulnerable = []
    patched = []

    for c in candidates:
        v = get_version(c)
        if v is None:
            checked.append(f'{c}=unknown')
            continue
        checked.append(f'{c}={ver_to_str(v)}')
        if v < PATCH_FLOOR:
            vulnerable.append((c, v))
        else:
            patched.append((c, v))

    if vulnerable:
        details = '; '.join(f'{p} -> {ver_to_str(v)}' for p, v in vulnerable)
        print(f'VULNERABLE: {details} (patch floor {ver_to_str(PATCH_FLOOR)})')
        return 1

    if patched:
        details = '; '.join(f'{p} -> {ver_to_str(v)}' for p, v in patched)
        print(f'PATCHED: {details} (patch floor {ver_to_str(PATCH_FLOOR)})')
        return 0

    print('UNKNOWN: unable to determine version from candidates: ' + '; '.join(checked))
    return 2


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

If you remember one thing.

TL;DR
Monday morning, do two queries: which endpoints are below 149.0.7827.53/54, and which of those actually use Chrome Remote Desktop / Chromoting. For this HIGH assessment, the noisgate mitigation SLA is ≤30 days to disable or tightly restrict Chromoting on endpoints that do not need it, and the noisgate remediation SLA is ≤180 days to move remaining systems to the fixed build; in practice, remoting-enabled hosts should go first, while the rest can ride your normal browser auto-update cadence.

Sources

  1. Google Chrome stable 149 release notes
  2. Google Chrome early-stable 149.0.7827.53/.54 rollout
  3. Chrome Releases 2026 archive
  4. Chromium security overview
  5. Chromoting build instructions
  6. Chromium issue tracker entry for CVE-2026-10893
  7. CISA Known Exploited Vulnerabilities Catalog
  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.