CVE-2026-106195: Chrome Remote Desktop (Chromoting) Authorization Bypass on macOS — Detection and Remediation Guide

NVD has published CVE-2026-106195, a CVSS 9.1 (CRITICAL) vulnerability affecting the Chromoting component of Google Chrome on macOS — the code that powers Chrome Remote Desktop. The flaw is an incorrect authorization condition that allows a remote attacker to bypass system access restrictions via crafted network traffic. Every Chrome installation on macOS prior to version 155.0.8059.39 is exposed.

Two details in this disclosure deserve your attention as defenders. First, the vulnerability is remotely exploitable over the network without user interaction, which is what drives the NVD score to 9.1. Second, Chromium's internal security severity rating is listed as Low — a significant divergence from NVD's critical rating that you should not let lull you into complacency. NVD scores reflect the worst-case impact of an authorization bypass on a remote access component; if an attacker can circumvent macOS access restrictions through Chromoting, the blast radius includes unauthorized remote session establishment, access to the logged-in user's desktop, and whatever that user can reach. Authorization flaws in remote access tooling are precisely the class of weakness that gets weaponized quietly and exploited at scale once technical details emerge.

Chrome Remote Desktop is also a frequent shadow-IT artifact: users install it for convenience, IT never approves it, and your EDR inventory never flags it because it arrives signed by Google. That combination — network-exploitable, authorization-related, and commonly unmanaged — makes this a patch-and-hunt priority this week, not a backlog item.

Technical Analysis

Affected Products and Versions

How the Vulnerability Works (Defender's View)

The weakness class is incorrect authorization (CWE-863) inside Chromoting. Chromoting implements the host-side and client-side logic for Chrome Remote Desktop: it brokers connections through Google's infrastructure, performs pairing and PIN-based authentication, and enforces which system-level actions a remote session may perform on the Mac.

An incorrect authorization flaw in this pathway means the enforcement logic that decides "is this remote peer allowed to do this on this host?" can be circumvented with crafted network traffic. From a defensive standpoint, the exploitation model is:

1. Target has Chrome (with Chromoting components) on macOS below 155.0.8059.39. Chrome Remote Desktop may be fully configured, or the Chromoting code paths may be reachable as part of Chrome's bundled components.
2. Attacker sends malformed/crafted traffic to the Chromoting service pathway, abusing the missing or incorrect authorization check.
3. System access restrictions are bypassed — the attacker gains capability the authorization layer was supposed to deny, potentially including interaction with the host session or restricted system functions.

Because the attack vector is network-based and requires no victim interaction, any Mac with an exposed or reachable Chromoting component is a candidate target. The practical exposure is highest on hosts where Chrome Remote Desktop is installed and enabled as a host (the remoting_host process and associated LaunchDaemons), but the component ships with Chrome itself, so version hygiene matters fleet-wide regardless of whether CRD is actively used.

Exploitation Status

At the time of writing:

• No public proof-of-concept exploit has been confirmed.
• No confirmed in-the-wild exploitation has been reported.
• Not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
• Chromium tagged the issue as Low severity, which sometimes indicates mitigating factors (e.g., requires Chrome Remote Desktop to be specifically configured, or limited preconditions). NVD's 9.1 reflects the theoretical worst case.

Treat this as a window of opportunity: patch before technical analysis of the fix diff produces working exploitation logic. Authorization bypasses in remote access components have historically moved from disclosure to active abuse quickly.

Detection & Response

Detection for this CVE centers on three observable behaviors: (1) presence of vulnerable Chrome versions on macOS endpoints, (2) execution and network activity of the Chromoting host process (remoting_host, Chrome Remote Desktop app bundles), and (3) anomalous child processes or actions spawned by the remote access component, which would indicate the authorization bypass being exercised post-connection.

Sigma Rules

These rules assume macOS process creation telemetry (e.g., via Endpoint Security Framework agents, osquery, or Defender for Endpoint on Mac) normalized into Sigma format. The first targets suspicious child processes of the Chromoting host — a strong signal of post-exploitation abuse. The second targets installation/execution of Chrome Remote Desktop where it is not sanctioned, which is both a shadow-IT detection and the exposure surface for this CVE.

---
title: Suspicious Child Process of Chrome Remote Desktop Host on macOS
id: 8f2b6c41-3a9d-4e7b-b5c2-1d9e0f4a7c31
status: experimental
description: Detects shell, scripting, or system utility processes spawned by the Chrome Remote Desktop host process (remoting_host) on macOS, which may indicate abuse of the CVE-2026-106195 authorization bypass or general remote access tool misuse.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-106195
  - https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1219
logsource:
  category: process_creation
  product: macos
detection:
  selection_parent:
    ParentImage|endswith:
      - '/remoting_host'
      - '/Chromoting Host'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/zsh'
      - '/sh'
      - '/osascript'
      - '/python'
      - '/python3'
      - '/curl'
      - '/wget'
      - '/launchctl'
      - '/dscl'
      - '/security'
      - '/sqlite3'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate remote administration sessions where an admin opens a terminal through Chrome Remote Desktop
level: high
---
title: Chrome Remote Desktop Host Installed or Executed on macOS
id: 2c7a9e15-6b4f-4d38-a1e9-8f3c5b2d9047
status: experimental
description: Detects execution of the Chrome Remote Desktop host binary or registration of its LaunchDaemon on macOS. Chrome Remote Desktop is a common shadow-IT remote access tool and is the exposure surface for CVE-2026-106195. Alert where CRD is not an approved remote access solution.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-106195
  - https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1219
logsource:
  category: process_creation
  product: macos
detection:
  selection_image:
    Image|contains:
      - '/Chrome Remote Desktop Host.app/'
      - 'remoting_host'
  selection_cli:
    CommandLine|contains:
      - 'org.chromium.chromoting'
      - 'remoting_me2me_host'
  condition: 1 of selection_*
falsepositives:
  - Environments where Chrome Remote Desktop is an approved and managed remote support tool - maintain an allowlist of sanctioned hosts
level: medium

KQL (Microsoft Sentinel / Defender)

The first query hunts for Chromoting host execution and suspicious descendants on macOS endpoints via Defender for Endpoint telemetry. The second identifies devices still running vulnerable Chrome builds using Defender Vulnerability Management, giving you a live patch-compliance target list.

// Hunt 1: Chromoting host execution and suspicious child processes on macOS
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "remoting_host"
    or ProcessCommandLine has_any ("org.chromium.chromoting", "remoting_me2me_host", "Chrome Remote Desktop Host.app")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
| join kind=leftouter (
    DeviceProcessEvents
    | where TimeGenerated > ago(7d)
    | where FileName in~ ("bash", "zsh", "sh", "osascript", "python3", "python", "curl", "wget", "launchctl", "security")
    | where InitiatingProcessFileName =~ "remoting_host" or InitiatingProcessCommandLine has "chromoting"
    | project SuspiciousChildTime = TimeGenerated, DeviceName, ChildProc = FileName, ChildCmdLine = ProcessCommandLine
) on DeviceName
| summarize CRDActivity = count(), SuspiciousChildren = countif(isnotempty(ChildProc)),
            ChildProcessList = make_set(strcat(ChildProc, " :: ", ChildCmdLine)) by DeviceName, AccountName
| order by SuspiciousChildren desc;

// Hunt 2: Identify macOS devices with vulnerable Chrome versions (below 155.0.8059.39)
DeviceInfo
| where OSPlatform has "macOS"
| join kind=inner (
    DeviceTvmSoftwareInventory
    | where SoftwareName has "chrome"
    | extend VersionParts = split(SoftwareVersion, ".")
    | extend Major = toint(VersionParts[0])
    | extend Build = toint(VersionParts[2])
    | extend Patch = toint(VersionParts[3])
    | where Major < 155 or (Major == 155 and Build < 8059) or (Major == 155 and Build == 8059 and Patch < 39)
) on DeviceId
| summarize VulnerableChromeVersions = make_set(SoftwareVersion) by DeviceName, OSPlatform, OSVersion
| order by DeviceName asc;

Velociraptor VQL

Use this hunt across your macOS fleet to enumerate Chromoting host processes, their network listeners, and the installed Chrome Remote Desktop application state. This answers two questions fast: who is running CRD, and is it holding connections it shouldn't be?

-- Hunt for Chrome Remote Desktop (Chromoting) host processes and their network connections on macOS
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Exe =~ 'remoting_host|Chrome Remote Desktop Host'
   OR CommandLine =~ 'chromoting|remoting_me2me_host'

-- Correlate with active network connections from the Chromoting process
SELECT Pid, Name, Status, Family, Type, LocalIP, LocalPort, RemoteIP, RemotePort
FROM netstat()
WHERE Name =~ 'remoting'

-- Check for installed Chrome Remote Desktop bundles and LaunchDaemons
SELECT FullPath, Size, Mtime
FROM glob(globs=['/Applications/Chrome Remote Desktop Host.app/Contents/Info.plist',
                 '/Library/LaunchDaemons/org.chromium.chromoting*.plist',
                 '/Library/PrivilegedHelperTools/org.chromium.chromoting*'])

Remediation / Verification Script (Bash)

Run this on macOS endpoints (or deploy via your MDM — Jamf, Kandji, Intune) to verify the Chrome version, detect Chrome Remote Desktop presence, and flag hosts requiring remediation. It does not auto-remediate CRD removal without an explicit flag, since CRD may be sanctioned in some environments.

#!/bin/bash
# CVE-2026-106195 - Chrome/Chromoting on macOS verification and remediation script
# Security Arsenal - vulnerability-management

REQUIRED_VERSION="155.0.8059.39"
CHROME_APP="/Applications/Google Chrome.app"
CRD_APP="/Applications/Chrome Remote Desktop Host.app"
REMOVE_CRD=0   # set to 1 to uninstall Chrome Remote Desktop Host if found

ver_ge() { [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" = "$2" ]; }

# 1) Check installed Chrome version
if [ -d "$CHROME_APP" ]; then
  INSTALLED=$(/usr/bin/defaults read "$CHROME_APP/Contents/Info.plist" CFBundleShortVersionString 2>/dev/null)
  echo "[INFO] Chrome installed version: $INSTALLED"
  if ver_ge "$INSTALLED" "$REQUIRED_VERSION"; then
    echo "[PASS] Chrome is patched against CVE-2026-106195 (>= $REQUIRED_VERSION)"
  else
    echo "[FAIL] Chrome is VULNERABLE - update to $REQUIRED_VERSION or later immediately"
    echo "[ACTION] Triggering Chrome update check via Keystone (GoogleSoftwareUpdate)..."
    /usr/bin/open -a "$CHROME_APP" --args --check-for-update-interval=0 2>/dev/null
    KSADMIN=$(/usr/bin/find /Library/Google/GoogleSoftwareUpdate -name ksadmin 2>/dev/null | head -n1)
    if [ -n "$KSADMIN" ]; then
      "$KSADMIN" --update com.google.Chrome --verbose
    else
      echo "[WARN] Keystone updater not found - push the updated Chrome pkg via MDM"
    fi
  fi
else
  echo "[INFO] Chrome not installed at $CHROME_APP"
fi

# 2) Detect Chrome Remote Desktop Host presence (exposure surface)
if [ -d "$CRD_APP" ]; then
  echo "[ALERT] Chrome Remote Desktop Host installed - verify this is authorized remote access software"
  /usr/bin/pgrep -fl remoting_host && echo "[ALERT] remoting_host process is RUNNING"
  if [ "$REMOVE_CRD" -eq 1 ]; then
    echo "[ACTION] Stopping and removing Chrome Remote Desktop Host..."
    /usr/bin/sudo /bin/launchctl bootout system /Library/LaunchDaemons/org.chromium.chromoting.plist 2>/dev/null
    /usr/bin/sudo /bin/rm -rf "$CRD_APP" \
      /Library/LaunchDaemons/org.chromium.chromoting.plist \
      /Library/PrivilegedHelperTools/org.chromium.chromoting.me2me_host 2>/dev/null
    echo "[DONE] Chrome Remote Desktop Host removed"
  fi
else
  echo "[PASS] Chrome Remote Desktop Host not installed"
fi

# 3) Report any active chromoting launch daemons
/bin/launchctl print system 2>/dev/null | /usr/bin/grep -i chromoting && \
  echo "[ALERT] Active chromoting service registered in launchd" || \
  echo "[PASS] No active chromoting launchd service"

Remediation

1. Patch Chrome on all macOS endpoints to 155.0.8059.39 or later immediately. Chrome auto-updates, but auto-update is not a control — verify via MDM software inventory or Defender TVM that every Mac has actually converged. Devices that haven't checked in, have update policies disabled, or are pinned to older builds are your residual risk.
2. Inventory and govern Chrome Remote Desktop. Query your fleet for the CRD Host app bundle and org.chromium.chromoting LaunchDaemons. If CRD is not an approved remote access tool, remove it and add the Sigma/KQL detections above to catch reinstallation. If it is approved, document it, scope it to named users, and monitor it like any other remote access pathway.
3. Restrict remote access tooling by policy. Use MDM configuration profiles to block unauthorized remote access applications, and enforce application allowlisting where feasible. Shadow remote access tools are a top-tier initial access and persistence vector — this CVE is a reminder of why.
4. Network-layer mitigation (interim). For Macs that cannot be patched immediately: where CRD is unauthorized, uninstall the host component; where Chrome itself can't be updated yet, note that the Chromoting pathway brokers connections through Google infrastructure, so egress filtering of *.googleapis.com remoting endpoints is generally impractical — prioritize patching over network workarounds for this one.
5. Monitor the CISA KEV catalog for addition of CVE-2026-106195. If it lands in KEV, federal remediation deadlines (typically 3 weeks for standard additions) and your own SLA-driven emergency change process apply.
6. Review remote session logs for any Macs that had CRD enabled and were running vulnerable Chrome versions. Unexpected sessions, unfamiliar paired clients, or host logins at odd hours warrant a closer forensic look — authorization bypass flaws leave their fingerprints in session establishment, not in crash logs.

Vendor references: NVD — CVE-2026-106195 and the Chrome Releases blog for the stable channel update containing the fix.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub