A picky bouncer at the door lets one weird ID slip through, but only if the guest also does a little dance
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.
4 steps from start to impact.
Attacker hosts a crafted page
- Attacker-controlled web origin reachable by target
- Enterprise DNS/URL filtering (Umbrella, Zscaler, Netskope) blocks most first-party malicious domains
- iOS App Transport Security forces HTTPS, raising the bar for cheap infra
Victim opens the link in Chrome on iOS
- Target uses Google Chrome as an installed iOS browser
- Target version < 150.0.7871.47
- Safari remains the default browser on the vast majority of iOS devices
- Chrome on iOS auto-updates via the App Store; MDM-managed fleets typically stay within a release or two of latest
User interaction triggers the flawed code path
UI:R in the CVSS vector is not decorative — the exploit requires the victim to click, tap, or otherwise interact with a specific element on the malicious page. High attack complexity (AC:H) further implies timing, race, or environmental prerequisites the attacker cannot reliably control.- User taps or interacts with the attacker's crafted element
- Timing/race conditions align
AC:Hmeans exploitation is unreliable in the wild- iOS suspends background tabs aggressively, disrupting timing-sensitive chains
Limited integrity/availability impact
I:L and A:L — the attacker might spoof a UI indicator, corrupt a small piece of browser state, or crash the tab. C:N means no data disclosure. Scope is Unchanged: the impact is bounded to the Chrome iOS app itself, not the OS, keychain, or other apps. iOS's per-app sandbox contains any fallout.- Successful trigger from step 3
- iOS app sandbox prevents lateral movement to Mail, Keychain, or corporate MDM profiles
- WKWebView process isolation limits what a compromised tab can reach
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.- Desktop EDR rules — the vulnerability is on iOS, where CrowdStrike/SentinelOne/Defender have essentially no process visibility.
- Blocking Chrome at the network edge — over-broad, breaks legitimate use, and Safari and other WKWebView apps have their own bug streams.
- Waiting for a Chrome desktop patch — this CVE ID applies to Chrome-for-iOS only; desktop builds are on a separate release train.
- iOS Lockdown Mode — helps for zero-click WebKit chains, but this bug requires user interaction and is inside Chrome's own code, not WebKit; Lockdown Mode does not specifically neutralize it.
The supporting signals.
| In-the-wild exploitation | None reported. Not present in CISA KEV. No public campaigns or IR reports reference this CVE. |
|---|---|
| Public PoC | No public proof-of-concept located as of 2026-07-01. Chromium bug tracker entries for this class are typically restricted for ~14 weeks post-fix. |
| EPSS | Not yet scored at time of assessment (CVE published 2026-06-30). Historical Chrome iOS input-validation bugs land in the <0.1 percentile range. |
| KEV status | Not listed. No CISA due-date obligation for federal agencies. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L — network reachable but *high complexity*, *user interaction required*, *no confidentiality impact*, scope unchanged |
| Affected versions | Google Chrome for iOS prior to 150.0.7871.47. Chrome on Android, macOS, Windows, and Linux are not affected by this specific CVE ID. |
| Fixed version | Chrome for iOS 150.0.7871.47 or later, delivered via the Apple App Store. |
| Exposure telemetry | iOS Chrome market share is ~3-5% of iOS browsing per StatCounter; the vulnerable-version subset shrinks daily as App Store auto-update rolls out. |
| Disclosed | 2026-06-30 via Chrome Releases blog |
| Reporter | Attributed to an external researcher via the Chrome VRP (specific credit per the Chrome Releases entry) |
Sources.
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:Rmeans 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.
Crowdsourced verification payload.
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