Use after free in GFX in Google Chrome on Linux prior to 149

CVE-2026-10891 is a use-after-free in Chrome's GFX stack on Linux. Based on the supplied vendor metadata, affected builds are Google Chrome on Linux prior to 149.0.7827.53, and exploitation would be driven by a crafted web page that exercises graphics code paths until freed memory is reused. In plain English: a user lands on attacker-controlled content, Chrome mishandles an object lifetime in graphics handling, and that can corrupt heap memory inside the browser.

Google's 8.8/HIGH baseline is technically understandable because memory corruption in a browser is never trivial to ignore. But for enterprise patch priority, that rating is too generous for the real world: this is Linux-only, still requires user interaction, has no KEV listing, carries a very low EPSS (0.00068), and—most importantly—a single Chrome renderer/GPU memory-corruption bug is not the same thing as reliable host takeover. In most modern Chrome deployments, the decisive friction is the sandbox boundary; without a second escape or a browser policy mistake, the blast radius is often limited to the browser process.

Why this verdict

• Downgrade for Linux-only scope: this is not an all-desktop Chrome emergency; it narrows to the Linux browser population.
• Downgrade for UI:R: the attacker still needs a user to open hostile content, which means every web/mail control in front of the browser gets a chance to break the chain.
• Downgrade for sandbox friction: a single Chrome GFX use-after-free usually buys a constrained browser foothold first, not guaranteed host compromise.
• Downgrade for low current threat signal: EPSS is very low, there is no KEV listing, and no public exploitation evidence or public PoC was found.
• Not downgraded further because memory corruption in a browser is still dangerous: if a user lands on the page and the exploit is reliable, confidentiality and session material inside the browser are still in play.

Why not higher?

It is not HIGH in patch-priority terms because the attack chain has multiple real frictions: Linux-only deployment, user interaction, and sandbox containment. The absence of KEV, public campaign evidence, and public exploit tooling removes the urgency signal you would need to justify pushing this into the same bucket as actively exploited edge-system bugs.

Why not lower?

It is not LOW because this is still remote client-side memory corruption in a mainstream browser. Enterprises routinely lose initial footholds through browser bugs, and a motivated attacker only needs one user on one vulnerable Linux workstation to make the issue operationally relevant.

1. Confirm update drift on Linux Chrome — Audit where Chrome auto-update is disabled, pinned, or delayed by package-management controls. For a MEDIUM verdict there is no mitigation SLA, so use this during normal operations and ensure the actual browser fix lands within the 365-day remediation window.
2. Constrain risky web paths for high-value Linux users — Apply stricter web filtering, isolate unknown sites, and consider browser isolation for developer/admin Linux workstations that routinely open untrusted content. There is no mitigation SLA for MEDIUM; use this as risk reduction where feasible while you patch inside the 365-day remediation window.
3. Watch browser crash and child-process telemetry — Alert on repeated Chrome renderer/GPU crashes, suspicious browser child processes, and browser-to-shell ancestry on Linux. This will not prevent exploitation, but it improves detection of exploit development and failed attempts while remediation is rolled out.
4. Review Beta/Dev channel usage — The supplied fixed build aligns with Chrome 149-era release material, and Linux fleets running Beta/Dev deserve extra attention because they may intersect earlier with vulnerable code paths. Fold those systems into your regular remediation plan; no mitigation SLA applies at this severity.

Run this on the target Linux host or via your fleet agent/SSH. Invoke it as bash check_chrome_cve_2026_10891.sh; it needs no root privileges unless your environment restricts execution or browser binaries are non-standard. It checks common Chrome binary names and compares the installed version to 149.0.7827.53.

#!/usr/bin/env bash
# check_chrome_cve_2026_10891.sh
# Detects whether Google Chrome on Linux is vulnerable to CVE-2026-10891
# Vulnerable if installed version is earlier than 149.0.7827.53
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

THRESHOLD="149.0.7827.53"
BIN=""
VERSION=""

candidates=(
  google-chrome
  google-chrome-stable
  google-chrome-beta
  google-chrome-unstable
)

for c in "${candidates[@]}"; do
  if command -v "$c" >/dev/null 2>&1; then
    BIN="$c"
    break
  fi
done

if [[ -z "$BIN" ]]; then
  echo "UNKNOWN: Google Chrome binary not found (checked: ${candidates[*]})"
  exit 2
fi

raw_version="$($BIN --version 2>/dev/null || true)"
VERSION="$(printf '%s' "$raw_version" | grep -Eo '[0-9]+(\.[0-9]+){3}' | head -n1)"

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN: Unable to parse version from '$raw_version'"
  exit 2
fi

verlt() {
  # returns 0 if $1 < $2
  local first="$1"
  local second="$2"
  [[ "$first" == "$second" ]] && return 1
  local lowest
  lowest=$(printf '%s\n%s\n' "$first" "$second" | sort -V | head -n1)
  [[ "$lowest" == "$first" ]]
}

if verlt "$VERSION" "$THRESHOLD"; then
  echo "VULNERABLE: $BIN version $VERSION is earlier than $THRESHOLD"
  exit 1
else
  echo "PATCHED: $BIN version $VERSION is at or above $THRESHOLD"
  exit 0
fi

Sources

1. Chrome Releases: Early Stable Update for Desktop
2. Chrome Releases: 2026 archive
3. Manage Chrome browser updates (Linux)
4. Chrome browser release channels
5. Update Google Chrome on desktop
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS model documentation
8. MITRE CWE-416: Use After Free