Android Bootloader EUVD-2026-79149

Exploitation requires the attacker to already possess System execution privileges on the Android device (PR:H) and local access (AV:L) - this is explicitly stated in the description ('local escalation of privilege with System execution privileges needed'). No user interaction is required (UI:N). The specific prerequisite is a foothold running as the Android System user/component that can reach the affected Bootloader interface lacking the permission check. This is NOT remotely or unprivileged-app exploitable; the high-privilege precondition is the primary limiting factor and confines exploitation to post-compromise privilege-boundary escalation on affected Pixel/Android firmware.

This is a moderate-severity local privilege escalation in the Android Bootloader driven by a missing permission check (CWE-269). The vendor CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H = 6.7) is internally consistent with the description: the attack is local (AV:L) and, critically, requires PR:H because the description explicitly states 'System execution privileges needed.' This means the attacker must ALREADY hold System-level privileges before exploiting the flaw, which sharply limits real-world risk - it is a privilege-boundary bypass from System toward bootloader/higher trust, not an unprivileged-app-to-root primitive. EPSS is very low at 0.12% (2nd percentile), there is no CISA KEV listing, and no public exploit was identified, so exploitation status is 'no public exploit identified at time of analysis.' All three signals (low EPSS, no KEV, no POC) agree that this is not a widespread or near-term exploitation priority. The C:H/I:H/A:H impact rating is generous boilerplate typical of Android bulletin entries; given the attacker already possesses System privileges, the marginal confidentiality/integrity/availability gain is defensible only if the bootloader bypass yields control below the OS trust boundary. No SSVC decision data was provided. Net: a real but low-priority defense-in-depth kernel/bootloader hardening fix, not a high-real-risk issue despite the C/I/A:H metrics.

An attacker who has already achieved code execution with Android System privileges (e.g., via a prior compromise of a privileged system component) invokes the affected bootloader interface, which fails to perform a required permission check. This lets the attacker perform a bootloader operation that should be gated, escalating trust beyond the OS boundary. No user interaction is required, but the high starting privilege prerequisite makes this a chained post-compromise step rather than an initial-access vector; no public exploit code was identified.