Out of bounds read in Extensions in Google Chrome on Linux prior to 149

CVE-2026-11143 is an out-of-bounds read in Chrome Extensions on Linux only, affecting Google Chrome versions prior to 149.0.7827.53. The attacker does not get a one-click web exploit here; they first have to convince a user to install a malicious extension, then use that crafted extension to read potentially sensitive data from the browser process memory.

Google labeled it MEDIUM 6.5, and technically that is defensible in a vacuum because the confidentiality impact is real. In enterprise reality, though, the exploit chain is heavily throttled by preconditions: Linux-only scope, user interaction, extension-install social engineering, and no evidence of in-the-wild abuse or internet-scale exposure. That combination pushes this down into backlog-hygiene territory.

Why this verdict

• Down from vendor 6.5 because attacker position is worse than CVSS suggests: this is not an unauthenticated remote web hit; it requires getting attacker-controlled extension code installed by the user first.
• Down again for population reach: the vulnerable population is limited to Linux Chrome endpoints, and only the subset where extension governance is weak enough to permit malicious installs.
• Down again for real-world signal: no KEV listing, no active exploitation evidence, no public PoC found, and no internet-exposed service to mass-scan or mass-exploit.

Why not higher?

A higher rating would need an amplifier such as active exploitation, a one-click browser trigger, broad cross-platform exposure, or a direct path to code execution or sandbox escape. None of those are present in the reviewed evidence. The chain starts with a social-engineering win plus extension install, which is already a prior-control failure.

Why not lower?

It is not IGNORE because the confidentiality impact is legitimate: the bug can expose process memory, and malicious extensions are a real enterprise abuse path. If you allow broad extension installation on Linux workstations, this becomes more than theoretical, just not urgent enough to outrank remotely reachable or exploited bugs.

1. Enforce an extension allowlist — Restrict Chrome extensions to approved IDs through enterprise policy so the exploit chain dies at the installation step. For a LOW verdict there is no SLA; treat this as backlog hygiene and implement during normal browser-policy maintenance.
2. Block developer-mode and sideloading paths — If your Linux fleet permits unpacked or sideloaded extensions, close that gap so social engineering has fewer viable routes. For a LOW verdict there is no SLA; fold this into your standard workstation hardening cycle.
3. Alert on new extension installs — Use Chrome enterprise reporting, EDR, or local telemetry to surface extension additions, especially on Linux admin and engineering workstations. For a LOW verdict there is no SLA; implement as part of routine detection engineering.
4. Prioritize high-value Linux users — Focus review on developers, admins, and browser-heavy privileged users because their session memory is more likely to contain valuable tokens or internal app data. For a LOW verdict there is no SLA; target these cohorts in your next browser hygiene pass.

Run this on the target Linux host or through your fleet management agent. Invoke it as bash check-chrome-cve-2026-11143.sh with no special privileges required; it checks common Google Chrome Linux binaries and prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check-chrome-cve-2026-11143.sh
# Purpose: Determine whether Google Chrome on Linux is vulnerable to CVE-2026-11143
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

FIXED_VERSION="149.0.7827.53"
CANDIDATES=(
  "/usr/bin/google-chrome"
  "/usr/bin/google-chrome-stable"
  "/opt/google/chrome/google-chrome"
)

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

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

FOUND_BIN=""
FOUND_VER=""

for bin in "${CANDIDATES[@]}"; do
  if [ -x "$bin" ]; then
    ver="$(extract_version "$bin")" || continue
    FOUND_BIN="$bin"
    FOUND_VER="$ver"
    break
  fi
done

if [ -z "$FOUND_BIN" ] || [ -z "$FOUND_VER" ]; then
  echo "UNKNOWN: Google Chrome for Linux not found in expected locations"
  exit 2
fi

if version_lt "$FOUND_VER" "$FIXED_VERSION"; then
  echo "VULNERABLE: $FOUND_BIN version $FOUND_VER is older than fixed version $FIXED_VERSION"
  exit 1
else
  echo "PATCHED: $FOUND_BIN version $FOUND_VER is at or newer than fixed version $FIXED_VERSION"
  exit 0
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop
2. Chromium issue referenced by Google for CVE-2026-11143
3. Vulnerability-Lookup entry aggregating CVE record and CISA ADP enrichment
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS API documentation
6. SecurityWeek coverage of Chrome 149 fixes
7. Canadian Centre for Cyber Security advisory for Chrome 149