Inappropriate implementation in Payments in Google Chrome on Android prior to 149

CVE-2026-11019 is an Android-only Chrome Payments flaw affecting versions before 149.0.7827.53. If an attacker has already compromised the renderer process, a crafted HTML page can abuse the Payments implementation to spoof the domain shown to the user during a payment-related flow.

Chromium labels it Medium, and that is technically reasonable in isolation, but for enterprise patch triage it behaves closer to LOW. The decisive friction is the prerequisite: this is not initial access and not standalone remote exploitation; it is a post-renderer-compromise phishing/UI-deception primitive with per-user blast radius.

Why this verdict

• Major downward pressure: requires renderer compromise first — this is not unauthenticated remote code execution and not even standalone browser-to-user compromise; it assumes the attacker already cleared a hard earlier stage.
• Second downward pressure: impact is spoofing, not takeover — the end state is domain deception in a payment flow, which can enable phishing or fraudulent approval, but does not itself give sandbox escape, persistence, or arbitrary code execution.
• Third downward pressure: narrow reachable population — Android-only, Payments-specific path, and no external service exposure means the reachable set is much smaller than a generic Chrome memory-corruption bug.
• No threat-amplifier evidence — no KEV entry, no public exploitation evidence, and a very low provided EPSS all argue against emergency treatment.

Why not higher?

To justify MEDIUM or HIGH in an enterprise queue, this would need either a broader reachable population or a more dangerous end state. It has neither: exploitation depends on a prior renderer compromise and yields a phishing/UI-spoofing primitive rather than device compromise.

Why not lower?

This is still a real security defect in a widely deployed browser and it touches payment trust cues, which users rely on for high-consequence decisions. If an attacker already has renderer control, this flaw can materially improve fraud success, so it is not something to ignore outright.

1. Enforce Chrome auto-update on managed Android — Use your MDM/EMM to require current Chrome builds and surface devices below 149.0.7827.53. For a LOW noisgate verdict there is no mitigation SLA; treat this as backlog hygiene and fold it into normal mobile app update enforcement.
2. Prefer native payment apps for sensitive workflows — Where business process allows, move payment-sensitive actions out of browser flows and into vetted native apps or managed web wrappers. That reduces dependence on browser trust cues; for LOW, schedule as backlog hygiene rather than interrupt-driven work.
3. Restrict risky browsing on corporate Android profiles — Use managed configurations, safe browsing policy, and app protection controls to limit exposure to untrusted content on work profiles. This does not fix the bug, but it makes the required precursor compromise harder; again, no mitigation SLA applies at this severity.
4. Monitor version drift in mobile inventory — Build a report for devices running Chrome below 149.0.7827.53 and tie it to your normal mobile compliance process. This CVE is best handled through inventory discipline, not emergency response.

Run this on an auditor workstation that has adb installed and USB/network access to a managed Android device. Invoke it as bash verify_cve_2026_11019.sh <device-serial>; it needs no root on the phone, only permission to query package metadata over ADB.

#!/usr/bin/env bash
# verify_cve_2026_11019.sh
# Checks whether Google Chrome on an attached Android device is older than 149.0.7827.53
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_VERSION="149.0.7827.53"
PKG="com.android.chrome"
SERIAL="${1:-}"

adb_cmd() {
  if [ -n "$SERIAL" ]; then
    adb -s "$SERIAL" "$@"
  else
    adb "$@"
  fi
}

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

if ! command -v adb >/dev/null 2>&1; then
  echo "UNKNOWN"
  exit 2
fi

if ! adb_cmd get-state >/dev/null 2>&1; then
  echo "UNKNOWN"
  exit 2
fi

VERSION=$(adb_cmd shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}')

if [ -z "$VERSION" ]; then
  VERSION=$(adb_cmd shell cmd package list packages -f "$PKG" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=\([^ ]*\).*/\1/p' | head -n1)
fi

if [ -z "$VERSION" ]; then
  INSTALLED=$(adb_cmd shell pm list packages "$PKG" 2>/dev/null | tr -d '\r')
  if [ -z "$INSTALLED" ]; then
    echo "UNKNOWN"
    exit 2
  fi
  echo "UNKNOWN"
  exit 2
fi

# Normalize any accidental suffixes
VERSION=$(printf '%s' "$VERSION" | sed 's/[^0-9.].*$//')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN"
  exit 2
fi

if version_lt "$VERSION" "$TARGET_VERSION"; then
  echo "VULNERABLE"
  exit 1
fi

echo "PATCHED"
exit 0

Sources

1. Google Chrome stable channel update for Desktop 149
2. Chromium issue 497344640
3. NVD record for CVE-2026-11019
4. OpenCVE record for CVE-2026-11019
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API documentation
7. Chrome for Android 149 early stable update lineage