Use after free in Ozone in Google Chrome prior to 149

CVE-2026-10902 is a CWE-416 use-after-free in Chromium's Ozone layer. Google fixed it in the Chrome 149 stable release published on 2026-06-02, with patched versions 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac; versions before those builds are affected. A remote attacker would deliver a crafted HTML page and rely on the victim to render attacker-controlled content in a vulnerable browser.

On paper this looks like classic browser RCE, but the vendor score overstates patch urgency for enterprise triage. The decisive downgrade is real-world friction: user interaction is required, the first-stage win lands inside Chrome's sandboxed multi-process architecture, and Ozone is documented as an Ozone-targeted platform layer for Linux/ChromeOS/Fuchsia. That makes this a serious, chainable client bug, not an automatic workstation-owning emergency.

Why this verdict

• Downgrade 1 — Ozone narrows the target pool: Chromium's Ozone docs indicate IS_OZONE targets Linux/ChromeOS/Fuchsia, which is materially smaller than the full Chrome desktop population implied by a generic browser CVSS.
• Downgrade 2 — user-driven delivery: The attacker still needs a victim to render a crafted page. That means web filtering, reputation controls, and user behavior all add real-world friction before the bug is ever touched.
• Downgrade 3 — sandboxed first-stage impact: Chrome's renderer/process isolation means the first successful memory-corruption stage is likely contained. Host-level compromise usually requires a second bug or boundary bypass.
• Downgrade 4 — weak threat signal: KEV is negative, EPSS is extremely low, and no public PoC surfaced. That does not make the bug harmless, but it argues strongly against emergency-tier prioritization.

Why not higher?

There is no credible public signal of active exploitation, and the path to meaningful enterprise damage is not one-step. The combination of UI:R, likely platform narrowing, and Chrome sandbox containment makes this a bad bug to patch in routine browser cadence—not a lights-on-fire fleet emergency.

Why not lower?

This is still a remote, no-auth, memory-corruption browser vulnerability delivered over ordinary web content. If you have a meaningful Linux/ChromeOS population, a determined attacker can target it at scale, and browser bugs remain valuable as first-stage footholds in multi-bug chains.

1. Enforce browser auto-update — Make sure managed Chrome/Chromium channels are actually pulling current builds and that pinned versions are justified. Because this is a MEDIUM verdict, there is no mitigation SLA; use this as routine hygiene while you move to the vendor-fixed build inside the 365-day remediation window.
2. Prefer isolation for risky browsing — Route high-risk user groups, untrusted browsing, and internet research roles through browser isolation or disposable VDI where available. This does not remove the bug, but it reduces the value of a first-stage renderer win while you remediate; again, no mitigation SLA applies at this severity.
3. Alert on Chrome crash spikes — Watch endpoint telemetry for unusual renderer crash loops, exploit mitigation events, and browser child-process anomalies on Linux/ChromeOS fleets. That gives you the best chance of spotting failed exploitation attempts even though version-based scanners cannot prove runtime abuse.

Run this on the target Linux or ChromeOS host whose browser you want to assess. Invoke it as bash check_cve_2026_10902.sh /usr/bin/google-chrome or just bash check_cve_2026_10902.sh; it needs only normal user rights as long as the browser binary is executable.

#!/usr/bin/env bash
# check_cve_2026_10902.sh
# Determine likely exposure to CVE-2026-10902 on Linux/ChromeOS Chrome-family browsers.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

FIXED_VERSION="149.0.7827.53"
TARGET="${1:-}"

candidates=(
  "$TARGET"
  "/usr/bin/google-chrome"
  "/usr/bin/google-chrome-stable"
  "/usr/bin/chromium"
  "/usr/bin/chromium-browser"
  "/opt/google/chrome/chrome"
)

find_browser() {
  local c
  for c in "${candidates[@]}"; do
    [ -n "$c" ] || continue
    if [ -x "$c" ]; then
      echo "$c"
      return 0
    fi
  done
  return 1
}

normalize_version() {
  # Keep only first numeric dotted quad-like string.
  echo "$1" | grep -Eo '[0-9]+(\.[0-9]+){2,3}' | head -n1
}

ver_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

BROWSER="$(find_browser)" || {
  echo "UNKNOWN - no Chrome/Chromium binary found in expected paths"
  exit 2
}

RAW_OUT="$($BROWSER --version 2>/dev/null || true)"
VERSION="$(normalize_version "$RAW_OUT")"

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - could not parse browser version from: $RAW_OUT"
  exit 2
fi

case "$(uname -s 2>/dev/null || echo unknown)" in
  Linux) : ;;
  *)
    echo "UNKNOWN - script logic is intended for Linux/ChromeOS style targets; detected $(uname -s 2>/dev/null || echo unknown)"
    exit 2
    ;;
esac

if ver_lt "$VERSION" "$FIXED_VERSION"; then
  echo "VULNERABLE - $BROWSER version $VERSION is older than fixed $FIXED_VERSION"
  exit 1
else
  echo "PATCHED - $BROWSER version $VERSION is at or above fixed $FIXED_VERSION"
  exit 0
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
2. Chromium Ozone Overview
3. Chromium Site Isolation design document
4. Chromium sandbox design documentation
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API documentation
7. GitHub repository search for CVE-2026-10902