Android Settings EUVD-2026-73950

Exploitation requires local access to a device running Android 14, 15, 16, 16-qpr2, or 17 with at least low-privilege execution - meaning a malicious app installed by the user or a user session on the device. The vulnerable code path is in the Settings application's SettingsFragment.getItemList, which is accessible under the default configuration of all affected Android versions. No victim interaction is required beyond the attacker's own device access. Exploitation is bounded by the local attack vector: no remote or network-based exploitation path is indicated by the CVSS vector or description. Unauthenticated or pre-installation exploitation is not supported by available data.

The CVSS 3.1 score of 7.8 (High) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H reflects a realistic local privilege escalation with full confidentiality, integrity, and availability impact - consistent with gaining elevated system or root-equivalent access on the device. Real-world risk is substantially moderated by the local attack vector: exploitation requires a malicious app already installed on the device or physical access, ruling out remote mass exploitation. EPSS at 0.12% (2nd percentile) is very low, and SSVC classifies exploitation as 'none' and automatable as 'no', indicating no observed exploitation and no straightforward scripted attack chain. However, SSVC's 'total' technical impact rating underscores that a successful attack achieves full device compromise. The broad affected surface (Android 14-17 across potentially billions of devices) elevates aggregate risk even if per-device probability is low. There is no confirmed POC at time of analysis. Priority is moderate: patch during the next scheduled update cycle rather than treating this as an emergency, unless the threat model includes malicious installed applications.

A malicious application installed on an Android 14-17 device invokes the Settings app's SettingsFragment, where the getItemList method exposes a misleading UI path. The app leverages this insufficient UI to trigger a privileged operation without the required authorization gate, achieving local privilege escalation to a higher system permission level with full access to device data and functionality. No public POC was identified at time of analysis, so this scenario remains theoretical based on the vulnerability description.