Insufficient validation of untrusted input in Chrome for iOS in Google Chrome on iOS prior to 150

CVE-2026-14137 is an *insufficient input validation* bug in Google Chrome for iOS versions prior to 150.0.7871.47. A remote attacker who controls a page the user visits can craft input that Chrome's iOS UI/parsing layer mishandles, resulting in a low-integrity and low-availability impact — think spoofed UI element, address-bar confusion, or a limited state corruption — without leaking data (C:N). No sandbox escape, no code execution, no credential theft on its own.

The vendor MEDIUM (4.2) rating is honest and, if anything, generous. Chrome on iOS is a WKWebView wrapper: Apple's WebKit does the heavy lifting for rendering, so most Chromium-class RCE surface simply doesn't apply. The vector — AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L — bakes in high attack complexity, required user interaction, and no scope change. In an enterprise fleet with iOS MDM and auto-updating Chrome from the App Store, this belongs in backlog hygiene, not weekend paging.

Why this verdict

• No confidentiality impact (C:N): the bug cannot exfiltrate cookies, credentials, session tokens, or DOM contents on its own — it fails the first test of a browser bug that matters.
• High attack complexity + user interaction: AC:H/UI:R means reliable weaponization is unlikely; commodity exploit kits will not bother.
• Platform containment: iOS app sandbox and WKWebView process isolation cap fallout at the Chrome app itself. No pivot to Keychain, Mail, or corporate MDM payloads.
• Role multiplier: Chrome for iOS is a *user endpoint browser*, not a hypervisor, IdP, CA, backup server, or kernel-mode agent. There is no realistic high-value-role deployment where this bug ends in fleet compromise — the affected component is definitionally client-side.
• Distribution channel is automatic: the App Store push-update model means the vulnerable population burns down without any admin action on ~95% of devices within days.
• Not KEV, no PoC, no campaign activity as of the disclosure date.

Why not higher?

MEDIUM would require some plausible chain to data disclosure or session hijack, but C:N and scope-unchanged foreclose both. A tab crash or UI spoof does not clear the bar for MEDIUM in a fleet-management context where thousands of higher-value patches compete for the same window.

Why not lower?

IGNORE would be wrong because there is a real code path with a real fix — inventory and eventual patching are still required for audit, PCI, and regulatory hygiene. Also, chained with a future WebKit or social-engineering bug, I:L on the browser UI could contribute to phishing believability.

1. Force Chrome for iOS auto-update via MDM — In Intune/Jamf/Kandji/Workspace ONE, enable *Automatic App Updates* and mark Chrome as a managed app. This is backlog-hygiene work — no mitigation SLA applies at LOW; fold it into the next scheduled MDM policy review.
2. Inventory vulnerable Chrome iOS builds — Query MDM for com.google.chrome.ios bundle version and flag anything below 150.0.7871.47. Report to asset owners; drive to remediation inside the noisgate 365-day window.
3. Web filtering baseline check — Confirm your SWG (Zscaler, Netskope, Umbrella, Menlo) is applying category-based blocks for newly-registered domains and malvertising networks — this raises the cost of the delivery step for every browser CVE, not just this one.
4. User awareness: prefer Safari or ensure Chrome is current — For high-risk personas (executives, finance), a one-line note in the next monthly comms is sufficient. Do not run a dedicated campaign for a LOW CVE.

Run this on your MDM admin workstation or a CI runner with API credentials for your mobile fleet. Example invocation: ./check_chrome_ios.sh 150.0.7871.47. Requires network access to your MDM API and a token with read permission on the app inventory endpoint. This script is a template — swap the MDM_QUERY block for your platform (Intune Graph, Jamf Classic API, Kandji, or Workspace ONE).

#!/usr/bin/env bash
# noisgate: CVE-2026-14137 Chrome for iOS version check
# Usage: ./check_chrome_ios.sh <fixed_version>
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -euo pipefail

FIXED_VERSION="${1:-150.0.7871.47}"
BUNDLE_ID="com.google.chrome.ios"

# --- version compare: returns 0 if $1 >= $2 ---
ver_ge() {
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

# --- MDM_QUERY: replace with your platform's API call ---
# Expected output: one line per device: <device_id>,<installed_version>
MDM_QUERY() {
  # Example placeholder — replace with real API call
  # curl -s -H "Authorization: Bearer $TOKEN" \
  #   "https://graph.microsoft.com/v1.0/deviceAppManagement/..." \
  #   | jq -r '.value[] | [.deviceId, .version] | @csv'
  echo "SAMPLE-DEVICE-01,150.0.7871.47"
  echo "SAMPLE-DEVICE-02,149.0.7800.10"
}

vuln=0; patched=0; unknown=0
while IFS=, read -r device version; do
  version="${version//\"/}"
  if [ -z "$version" ] || [ "$version" = "null" ]; then
    echo "UNKNOWN $device (no version reported)"
    unknown=$((unknown+1))
    continue
  fi
  if ver_ge "$version" "$FIXED_VERSION"; then
    echo "PATCHED  $device $version"
    patched=$((patched+1))
  else
    echo "VULNERABLE $device $version"
    vuln=$((vuln+1))
  fi
done < <(MDM_QUERY)

echo
echo "Summary: VULNERABLE=$vuln PATCHED=$patched UNKNOWN=$unknown"

if [ "$vuln" -gt 0 ]; then
  echo "RESULT: VULNERABLE"
  exit 1
elif [ "$unknown" -gt 0 ] && [ "$patched" -eq 0 ]; then
  echo "RESULT: UNKNOWN"
  exit 2
else
  echo "RESULT: PATCHED"
  exit 0
fi

Sources

1. Chrome Releases blog (April 2026 archive; iOS updates published on the same channel)
2. Chrome CVE listing — OpenCVE
3. NVD CVE record lookup
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS lookup
6. Chrome for iOS release notes (App Store)
7. Google Chrome VRP program
8. CWE-20: Improper Input Validation