CVE-2026-11114 · Chrome macOS Device Trust Use-After-Free Sandbox Escape

01 · The Real Story

This is a second-story window that only opens if someone already kicked down the front door

CVE-2026-11114 is a use-after-free in Chrome's Device Trust component on macOS only, present in all Chrome versions prior to 149.0.7827.53 (stable release June 4, 2026). Device Trust is the enterprise connector that feeds device-posture signals (OS version, firewall state, serial number) to identity providers like Okta, Duo, and Zscaler. The UAF triggers during handling of trust attestation objects and allows an attacker to escape Chrome's sandbox — but only if the renderer process is already compromised. That means an attacker needs a separate, independent exploit (typically a V8 or Blink RCE) just to reach the starting line of this bug. CWE-416 / CWE-825.

The NVD-assigned CVSS 3.1 score of 9.6 CRITICAL dramatically overstates real-world risk. The vector sets PR:N (no privileges required), which is technically true for delivering the page, but intellectually dishonest — the advisory itself says the attacker must have *"compromised the renderer process"* first. Chromium's own security team rated this bug Medium, reflecting its role as the second link in a chain, not a standalone weapon. The S:C (Scope Changed) metric is doing almost all the scoring work here, and while sandbox escapes *are* serious outcomes, a 9.6 for a Mac-only, enterprise-feature-only, second-stage bug with no PoC and 0.23% EPSS is a textbook case of CVSS inflation.

"Sandbox escape on Mac Chrome requires a prior renderer RCE — two exploits, one endpoint."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver crafted page to macOS Chrome user

The attacker hosts or injects a malicious HTML page and lures a macOS Chrome user into visiting it. This requires social engineering (phishing link, watering hole, malvertising) and the victim must be running Chrome on macOS — not Windows, Linux, or ChromeOS. Standard browser delivery mechanics apply.

Conditions required:

Victim uses Chrome on macOS
Victim clicks a link or visits a compromised site

Where this breaks in practice:

macOS represents ~16-22% of enterprise endpoints, narrowing the target population immediately
Email gateways, URL filters, and Safe Browsing will block known malicious domains

Detection/coverage: Google Safe Browsing, enterprise URL filtering (Zscaler, Palo Prisma Access), email gateway link scanning

STEP 02

Achieve renderer process compromise (separate exploit required)

Before CVE-2026-11114 becomes reachable, the attacker must execute code inside Chrome's sandboxed renderer process. This requires an independent memory-corruption or type-confusion vulnerability in V8, Blink, Skia, or another renderer-accessible component. Reliable renderer exploits are rare, technically demanding, and worth $100K–$250K+ on the exploit market. No public PoC or known campaign pairs a renderer RCE with this specific sandbox escape.

Conditions required:

A separate renderer RCE vulnerability (e.g., V8 type confusion, Blink UAF)
Exploit must be reliable enough to avoid crashing the renderer before reaching step 3

Where this breaks in practice:

Renderer RCEs are patched rapidly by Chrome's aggressive update cycle (auto-update every ~2 weeks)
V8 mitigations (sandbox, CFI, MTE on supported hardware) raise the bar significantly
This prerequisite alone prices out all commodity attackers — this is nation-state or top-tier broker territory

Detection/coverage: Chrome's CrashPad telemetry flags renderer crashes; EDR solutions (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) detect anomalous renderer child-process behavior

STEP 03

Trigger Device Trust UAF for sandbox escape

With renderer code execution, the attacker crafts memory operations targeting the Device Trust attestation objects. The use-after-free allows the attacker to reclaim freed memory with controlled content and hijack execution flow to escape Chrome's sandbox. Critically, the Device Trust component must be active — this requires Chrome Enterprise with Device Trust connectors configured and a managed browser profile. Consumer Chrome installations do not load this code path.

Conditions required:

Chrome Enterprise managed browser with Device Trust connectors enabled
Successful renderer compromise from step 2
macOS target (Device Trust attestation path is platform-specific)

Where this breaks in practice:

Device Trust connectors require explicit admin configuration — most Chrome installs (consumer + unmanaged enterprise) never load this component
ASLR, pointer authentication (PAC on Apple Silicon), and macOS hardened runtime complicate UAF exploitation
Chrome's MiraclePtr / BackupRefPtr mitigations for UAF bugs may apply depending on the specific pointer involved

Detection/coverage: macOS XProtect, Gatekeeper, and TCC prompts for post-sandbox actions; EDR agents detect sandbox escape indicators (unexpected mach port access, XPC abuse)

STEP 04

Gain code execution outside sandbox on macOS

Successful sandbox escape gives the attacker code execution with the privileges of the Chrome browser process (user-level on macOS). From here, standard macOS post-exploitation applies: keychain access, file system access, persistence via LaunchAgents, and lateral movement. The blast radius is one macOS endpoint — there is no inherent path to fleet-wide or domain-wide compromise from this single-host foothold.

Conditions required:

Successful completion of steps 1-3
macOS user-level privileges (not root unless paired with a local privilege escalation)

Where this breaks in practice:

macOS TCC (Transparency, Consent, Control) blocks access to sensitive directories (Desktop, Documents, Downloads, Camera, Microphone) without user consent
EDR on macOS detects post-exploitation behaviors (persistence, credential access, lateral movement)
Apple Silicon PAC and SSV (Signed System Volume) limit kernel-level escalation paths

Detection/coverage: EDR behavioral detection, macOS Unified Logging (subsystem: com.apple.sandbox), CrowdStrike Falcon / Jamf Protect sandbox escape detections

03 · Compensating Control

MEDIUM 5.0→IGNORE 0.0

SEVERITY REDUCED

Verify Chrome auto-update delivered 149.0.7827.53+ — Chrome's auto-update mechanism should have delivered this patch within 72 hours of the June 4, 2026 release. Use Chrome Enterprise reporting (via Google Admin Console or CBCM) to audit fleet-wide version compliance on macOS. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window, but given Chrome's auto-update, most environments are already patched. Confirm rather than deploy.

MEDIUM 5.0→IGNORE 0.0

SEVERITY REDUCED

Enforce Chrome Enterprise update policies — Set TargetVersionPrefix and RelaunchNotification policies via MDM (Jamf, Kandji, Mosyle) to force Chrome restarts within 48 hours of updates. This breaks the attack path at the root by eliminating the vulnerable code. Deploy within the 365-day noisgate remediation window.

MEDIUM 5.0→LOW 3.0

SEVERITY REDUCED

Deploy EDR with sandbox escape detection on macOS fleet — CrowdStrike Falcon, SentinelOne, or Microsoft Defender for Endpoint on macOS detect post-sandbox-escape behaviors (anomalous mach port acquisition, unexpected XPC connections, LaunchAgent persistence). This doesn't prevent the escape but catches it at step 4, limiting dwell time. Reduces blast radius of a successful chain from persistent compromise to detected-and-contained.

MEDIUM 5.0→IGNORE 0.0

SEVERITY REDUCED

Audit Device Trust connector enrollment scope — Review which Chrome profiles have Device Trust connectors active. If the feature is not required for your Zero Trust architecture, disable the connector policy (CloudManagementEnrollmentToken + Device Trust settings in Google Admin Console). Removing Device Trust from Chrome eliminates the vulnerable code path entirely, even on unpatched versions.

What doesn't work

Network-level controls (WAF, IDS/IPS signatures): This is a client-side browser vulnerability triggered by visiting a page. There is no server-side indicator or network signature to block. WAF rules are irrelevant.
Disabling JavaScript: While this might prevent some renderer exploitation vectors, it's impractical for enterprise use and doesn't specifically address the Device Trust UAF, which could be triggered through non-JS renderer code paths.
macOS Gatekeeper / notarization: These controls prevent unsigned app installation but do not affect in-browser exploitation. The sandbox escape occurs within Chrome's process architecture, not via app installation.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not listed in CISA KEV. Google's advisory does not flag active exploitation. No campaigns attributed.
Proof-of-concept availability	No public PoC found. Checked pocindex.io (no entry), GitHub (no repos named CVE-2026-11114), ExploitDB, and nuclei templates — all negative. The Chromium issue tracker entry (#501360342) is likely access-restricted. The two-stage prerequisite makes PoC development non-trivial.
EPSS score	0.00234 (0.23%) — 14th percentile. Indicates exploitation probability well below the median CVE. Consistent with a bug that requires a chained renderer RCE to reach.
CISA KEV status	Not listed. No federal remediation deadline imposed.
CVSS vector interpretation	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` → 9.6. The `S:C` (Scope Changed) and `PR:N` metrics inflate the score. `PR:N` ignores the renderer-compromise prerequisite acknowledged in the advisory text. Chromium's own severity: Medium.
Affected versions	All Google Chrome on macOS versions prior to `149.0.7827.53`. Windows, Linux, ChromeOS, and Android are not affected. The Device Trust code path is macOS-specific.
Fixed version	`149.0.7827.53` (stable channel, June 4, 2026). Chrome auto-update delivers this within 24-72 hours for managed and unmanaged browsers. Distro packages (e.g., Homebrew `google-chrome`) track upstream.
Scanning / exposure data	Not applicable for GreyNoise/Shodan/Censys — this is a client-side browser vulnerability, not a server-side exposure. No network scan signature exists.
Disclosure date	June 4, 2026 — disclosed with the Chrome 149 stable release. Part of a massive 429-vulnerability batch.
Reporting researcher	Not publicly attributed. Chromium bug #501360342 is access-restricted. Google discovered 371 of the 429 Chrome 149 bugs internally; total external bounties were ~$209K across the batch.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.0/10)

Why this verdict

Renderer compromise prerequisite: The advisory explicitly states the attacker must have *"compromised the renderer process"* before this bug is reachable. This is a full separate exploit — typically a V8 or Blink RCE — that prices out all actors below nation-state or top-tier exploit-broker level. CVSS ignores chaining prerequisites; real risk does not.
Chromium's own assessment is Medium: Google's security team — the people who built the sandbox, wrote the code, and understand the attack surface better than anyone — rated this Medium. Their severity system accounts for prerequisites and architectural context that CVSS does not. This is the strongest signal available.
macOS-only, enterprise-feature-only attack surface: The vulnerability exists only in Chrome on macOS, and only when Device Trust connectors are configured (Chrome Enterprise managed browser with an IdP integration). Consumer Chrome, Windows Chrome, Linux Chrome, and ChromeOS are unaffected. This narrows the reachable population to a small fraction of Chrome's 3B+ install base.
No PoC, no ITW, bottom-quartile EPSS: Zero public exploit code, zero observed campaigns, EPSS at the 14th percentile. Every empirical signal says this bug is not being weaponized and is unlikely to be.
Role multiplier: Chrome is an endpoint browser, not a server-side high-value-role component. (a) *Low-value role:* developer Mac — chain succeeds if both exploits land, blast radius is one workstation. (b) *Typical role:* corporate Mac with managed Chrome — same single-host blast radius. (c) *High-value role consideration:* Device Trust feeds posture signals to IdPs (Okta, Duo), but compromising it on one endpoint does not compromise the IdP itself, forge trust signals fleet-wide, or enable domain takeover. The blast radius remains single host. Chrome is not a canonical high-value-role component (not a DC, hypervisor, CA, PAM, CI/CD, backup, or network edge appliance). The high-value floor does not apply.

Why not higher?

A sandbox escape *is* a serious capability — it converts sandboxed code execution into full user-level access on the host. If this bug were reachable without a prior renderer compromise, or if a reliable PoC existed, or if it affected all platforms, HIGH would be warranted. But every escalation path requires two independent, high-value exploits chained together, which is an extremely high bar that limits real-world risk.

Why not lower?

Despite the heavy friction, a working sandbox escape on macOS Chrome still has real value to sophisticated attackers building full chains. Chromium rated it Medium (not Low), and the UAF primitive — once triggered — provides a powerful exploitation primitive. Dismissing it entirely would undercount the risk to high-value targets (executives, engineers with source code access) running managed Chrome on Macs in environments where Device Trust is configured.

06 · Verification

Crowdsourced verification payload.

Run on each macOS endpoint where Chrome is installed, or push via your MDM (Jamf, Kandji, Mosyle) as a script payload. No special privileges required — runs as the current user. Example: bash check_cve_2026_11114.sh

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# check_cve_2026_11114.sh
# Checks if Google Chrome on macOS is vulnerable to CVE-2026-11114
# (Device Trust UAF sandbox escape, fixed in 149.0.7827.53)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

FIXED_MAJOR=149
FIXED_MINOR=0
FIXED_BUILD=7827
FIXED_PATCH=53

CHROME_PATH="/Applications/Google Chrome.app/Contents/Info.plist"

if [[ "$(uname -s)" != "Darwin" ]]; then
  echo "NOT APPLICABLE — this CVE affects macOS only."
  echo "UNKNOWN"
  exit 2
fi

if [[ ! -f "$CHROME_PATH" ]]; then
  echo "Google Chrome not found at $CHROME_PATH"
  echo "UNKNOWN"
  exit 2
fi

VERSION=$(/usr/libexec/PlistBuddy -c "Print :KSVersion" "$CHROME_PATH" 2>/dev/null)
if [[ -z "$VERSION" ]]; then
  VERSION=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "$CHROME_PATH" 2>/dev/null)
fi

if [[ -z "$VERSION" ]]; then
  echo "Could not determine Chrome version."
  echo "UNKNOWN"
  exit 2
fi

echo "Installed Chrome version: $VERSION"

IFS='.' read -r V_MAJOR V_MINOR V_BUILD V_PATCH <<< "$VERSION"

V_MAJOR=${V_MAJOR:-0}
V_MINOR=${V_MINOR:-0}
V_BUILD=${V_BUILD:-0}
V_PATCH=${V_PATCH:-0}

if (( V_MAJOR > FIXED_MAJOR )); then
  echo "PATCHED — version $VERSION >= 149.0.7827.53"
  exit 0
elif (( V_MAJOR == FIXED_MAJOR )); then
  if (( V_MINOR > FIXED_MINOR )); then
    echo "PATCHED"
    exit 0
  elif (( V_MINOR == FIXED_MINOR )); then
    if (( V_BUILD > FIXED_BUILD )); then
      echo "PATCHED"
      exit 0
    elif (( V_BUILD == FIXED_BUILD )); then
      if (( V_PATCH >= FIXED_PATCH )); then
        echo "PATCHED — version $VERSION >= 149.0.7827.53"
        exit 0
      fi
    fi
  fi
fi

echo "VULNERABLE — version $VERSION < 149.0.7827.53 (CVE-2026-11114)"
exit 1