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

CVE-2026-11071 is a use-after-free in Chrome's Base code on Linux affecting Google Chrome before 149.0.7827.53. The vendor wording matters here: this bug is not described as a clean unauthenticated one-shot browser RCE; it requires an attacker who has already compromised the renderer process. From that phrasing, the practical role of this bug is post-renderer exploitation inside a chained browser attack, likely to extend control beyond the renderer sandbox or otherwise upgrade impact. That last part is an *inference from the vendor description pattern*, because the underlying Chromium issue remains restricted.

Google's HIGH 8.8 label is defensible if you score the bug in isolation with browser-style assumptions, but it overstates defender urgency for enterprise patch triage. The renderer-compromise prerequisite is major friction: it implies the attacker already landed a separate browser exploit stage first, and the bug is Linux-only, which cuts the reachable population again in mixed fleets. No KEV listing, no public exploitation evidence, and a very low EPSS all push this down from 'drop everything' into 'important chain component, but not your Monday morning panic patch' territory.

Why this verdict

• Major prerequisite drag: the attacker must already have renderer compromise, which implies a prior exploit stage and kills the 'single-CVE remote compromise' narrative.
• Population reduction: this is Linux-only Chrome, so in a typical enterprise the reachable population is far smaller than all-desktop Chrome counts.
• No active exploitation signal: no KEV, no public exploitation evidence found, and very low EPSS all argue against emergency handling.
• Security stack should break the chain earlier: secure web gateway, URL filtering, browser isolation, and EDR have chances to stop the initial renderer exploit before this CVE ever becomes reachable.
• Impact is still real on the right hosts: Linux developer/admin workstations can carry privileged sessions, SSH material, cloud creds, and source access, so this is not backlog junk.

Why not higher?

Because this bug is not the front door. Requiring prior renderer compromise turns it into a chained exploit stage, and every added prerequisite compounds downward pressure on severity. Add Linux-only targeting and the reachable enterprise population shrinks again.

Why not lower?

Because post-renderer browser bugs are exactly the kind of primitives advanced operators chain when they care about escaping the sandbox. On sensitive Linux workstations, a successful chain can still lead to credential theft, session hijack, or code execution in a high-value user context.

1. Enforce Chrome auto-update on Linux — Make sure managed Linux endpoints actually receive Chrome stable updates and are not pinned or broken in package management. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still clean up stragglers in your next normal endpoint cycle rather than let them drift.
2. Harden high-risk browsing tiers — Apply stricter browsing policy to developer, admin, and privileged Linux workstations: reduce unmanaged extensions, block risky categories, and prefer browser isolation for high-risk users. This lowers the chance the prerequisite renderer exploit lands in the first place; for MEDIUM, there is no separate mitigation deadline under noisgate.
3. Watch browser-to-child-process behavior — Tune EDR to alert when google-chrome or chrome spawns unusual shells, downloaders, or interpreters, or accesses credential-heavy locations unexpectedly. This matters because if CVE-2026-11071 is ever used, it is likely in a broader post-renderer chain where process ancestry becomes one of the few useful signals.
4. Prioritize privileged Linux users — If you cannot verify patch state everywhere immediately, audit Linux endpoints used by admins, developers, and cloud operators first. Those users hold the sessions and secrets that make a browser chain worth cashing out.

Run this on the target Linux endpoint or through your fleet agent as root or a regular user with execute access to the Chrome binary. Example: bash check_chrome_cve_2026_11071.sh or bash check_chrome_cve_2026_11071.sh /usr/bin/google-chrome-stable. It checks installed Google Chrome binaries and reports VULNERABLE, PATCHED, or UNKNOWN against the fixed version 149.0.7827.53.

#!/usr/bin/env bash
# check_chrome_cve_2026_11071.sh
# Determine whether Google Chrome on Linux is vulnerable to CVE-2026-11071
# Affected: Google Chrome on Linux < 149.0.7827.53
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / not enough data

set -u

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

candidates=(
  "/usr/bin/google-chrome-stable"
  "/usr/bin/google-chrome"
  "/opt/google/chrome/google-chrome"
  "/snap/bin/chromium"
)

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

get_version() {
  local bin="$1"
  local out ver
  if ! out="$($bin --version 2>/dev/null)"; then
    return 1
  fi
  ver="$(printf '%s' "$out" | grep -Eo '[0-9]+(\.[0-9]+){3}' | head -n1)"
  [ -n "$ver" ] || return 1
  printf '%s' "$ver"
  return 0
}

check_one() {
  local bin="$1"
  local ver
  ver="$(get_version "$bin")" || return 2

  printf 'BINARY=%s\n' "$bin"
  printf 'VERSION=%s\n' "$ver"
  printf 'FIXED_VERSION=%s\n' "$FIXED_VERSION"

  if version_lt "$ver" "$FIXED_VERSION"; then
    echo "VULNERABLE"
    return 1
  else
    echo "PATCHED"
    return 0
  fi
}

# If a specific binary was supplied, check only that.
if [ -n "$TARGET_BIN" ]; then
  if [ ! -x "$TARGET_BIN" ]; then
    echo "UNKNOWN"
    echo "Reason: specified binary is not executable: $TARGET_BIN"
    exit 2
  fi
  check_one "$TARGET_BIN"
  exit $?
fi

found_any=0
unknown_any=0
for bin in "${candidates[@]}"; do
  if [ -x "$bin" ]; then
    found_any=1
    check_one "$bin"
    rc=$?
    case "$rc" in
      0) exit 0 ;;
      1) exit 1 ;;
      2) unknown_any=1 ;;
    esac
  fi
done

# Fallback: try PATH lookups
for name in google-chrome-stable google-chrome; do
  if command -v "$name" >/dev/null 2>&1; then
    found_any=1
    bin="$(command -v "$name")"
    check_one "$bin"
    rc=$?
    case "$rc" in
      0) exit 0 ;;
      1) exit 1 ;;
      2) unknown_any=1 ;;
    esac
  fi
done

if [ "$found_any" -eq 0 ]; then
  echo "UNKNOWN"
  echo "Reason: no Google Chrome binary found in standard locations or PATH"
  exit 2
fi

if [ "$unknown_any" -eq 1 ]; then
  echo "UNKNOWN"
  echo "Reason: Chrome binary found but version could not be parsed"
  exit 2
fi

echo "UNKNOWN"
exit 2

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
2. Google Chrome Releases - June 2026 archive
3. Chromium issue 499227659
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS model documentation
6. Google Chrome Help - Update Google Chrome
7. SecurityWeek - Chrome 149 patches 429 vulnerabilities