Android USB Service CVE-2026-28645

Requires physical access to the device plus a USB connection while the device is in a strong-authentication-required state (the condition handled by onStrongAuthRequiredChanged in UsbService.java, e.g. a locked device after boot or lockdown where USB data should be restricted). The logic error causes USB data to be enabled when it should stay disabled, with no authentication and no user interaction. The decisive limiting factor is the physical-access/USB-tether requirement (AV:P): the flaw cannot be triggered remotely or over the network and cannot be automated at scale, which confines realistic exploitation to device-theft, evil-maid, or forensic-extraction scenarios against Android 15, 16, 16-qpr2, and 17.

This is a moderate-severity (CVSS 6.8) local/physical privilege-escalation issue in the Android USB service, and the multiple decision signals are consistent in pointing to a non-urgent but legitimate fix. The CVSS vector (AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) establishes that exploitation requires PHYSICAL access to the device but then needs no privileges or user interaction and yields total confidentiality, integrity and availability impact on the device. SSVC reinforces this: Exploitation 'none' (no observed or public exploitation), Automatable 'no' (physical access cannot be scripted at scale), but Technical Impact 'total' - matching the C:H/I:H/A:H. The vuln.today priority of 'this_month' aligns with a high-impact-but-physically-gated flaw. There is no CISA KEV listing and no EPSS score was supplied; absence of EPSS/KEV here reflects a physically-gated bug that mass-exploitation probability models would rate low, not a data gap that hides active exploitation. No POC or exploit reference is present in the input. The one tension worth stating explicitly: the CVSS claims C:H/I:H/A:H 'total' impact, yet the described effect is specifically the unauthorized enabling of USB data on a device in a strong-auth-required state - the high ratings are best read as the data-exfiltration/device-access potential once USB data is enabled on a locked device, not independently verified per-impact in the sources. Overall this is a real priority to patch via the normal monthly cycle, not an emergency, because the physical-access requirement sharply limits realistic attackers (e.g., device theft, border/evil-maid, forensic extraction scenarios).

An attacker with brief physical possession of a locked Android device (for example a stolen, seized, or temporarily unattended phone that is in a strong-authentication-required state) connects it to a computer over USB. Because of the logic error in handling the strong-auth-required state change, USB data is enabled without authentication, allowing the attacker to interact with the device's data over USB despite the lock. No user interaction is required and attack complexity is low once physical access is achieved; no public exploit code was identified in the provided data.