Google Android EUVD-2026-115411

Exploitation requires PHYSICAL access to the affected Android device (CVSS AV:P) - remote or network-based exploitation is not possible per the vector. No authentication or prior privileges are required (PR:N) and no user interaction is needed (UI:N), so once an attacker has physical possession/contact, the permission bypass can be triggered directly. The description does not name a specific feature, protocol, or configuration setting that must be enabled ('in multiple locations' / 'logic error in the code'), so no non-default configuration is identified as a prerequisite; the trigger mechanism is not described in the available sources. The decisive limiting factor is the physical-access requirement, which confines realistic risk to lost/stolen/seized/unattended-device (evil-maid-style) situations rather than remote or at-scale attacks. Affected builds are Android 14, 15, 16, 16-qpr2, and 17.

This is a moderate-severity Android privilege-escalation flaw (CVSS 6.8) whose real-world risk is tightly bounded by its attack vector. The CVSS vector CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H specifies a PHYSICAL attack vector (AV:P), meaning the attacker must have physical possession of or direct hardware contact with the device; despite PR:N and UI:N (no prior privileges or user interaction needed), the physical requirement is the dominant limiting factor and is why the base score lands at 6.8 rather than critical, even though the C/I/A impacts are all High. The exploitation signals are consistent and point to low urgency: EPSS is 0.13% (3rd percentile), the vulnerability is NOT in CISA KEV, and no public exploit or PoC reference appears in the provided sources - so there is no public exploit identified at time of analysis. The vuln.today decision label is 'this_month', indicating a routine-but-not-emergency patch cadence rather than act_now/emergency. The one point of friction worth flagging: the CWE is CWE-693 (Protection Mechanism Failure), and the description attributes the issue to a 'logic error' causing a 'permission bypass,' yet the CVSS codes PR:N and UI:N - the physical vector, not a remote/logical path, is what constrains this. There is no conflict between signals here: low EPSS, no KEV, and no PoC all align with a genuine but low-probability, physical-access-dependent issue rather than a widely exploitable remote bug.

An attacker with physical access to an unlocked or lockscreen-exposed Android device (e.g., a lost, stolen, seized, or momentarily unattended handset) triggers the logic error in the permission-check code to bypass a protection boundary, escalating to higher privileges without needing any pre-existing credentials or user interaction. No public exploit code is available, so an attacker would need to develop their own against the affected Android builds. The physical-access requirement makes this an opportunistic or targeted device-compromise scenario (e.g., evil-maid, border/device-seizure, or lost-device recovery) rather than a scalable remote attack.