Android Kernel EUVD-2026-79015

Exploitation requires the attacker to already have low-privileged code execution on the target device - concretely, a malicious or trojanized Android application installed in the normal app sandbox, or an equivalent local context such as an ADB shell - which is exactly what the PR:L metric in CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H denotes. No further privilege, elevation, or additional execution permission is needed once that foothold exists, and no user interaction is required after installation to trigger the vulnerable code path, per the description. The interface is the Android kernel through "multiple locations" that perform improper input validation; the supplied data does not enumerate which specific drivers, ioctl handlers, or subsystems are reachable, so defenders cannot yet confirm whether the vulnerable path is exposed to the ordinary untrusted app sandbox or only to a shell/ADB-level context - this must be verified against the September 2026 Pixel bulletin. Limiting factors: the attack is strictly local (AV:L), so it cannot be triggered over the network or by a remote unauthenticated party, and the attacker must first defeat the install-time controls that normally gate app delivery, such as Play Protect scanning and unknown-source restrictions. Platform applicability is limited to affected Android builds predating the bulletin's patch level; devices on a newer security patch level are not exploitable. Scope is unchanged (S:U), so the impact is confined to the compromised device rather than pivoting to adjacent systems.

The CVSS vector is internally consistent and moderately severe: local attack vector with low complexity and low privileges (AV:L/AC:L/PR:L), no user interaction, and full confidentiality, integrity, and availability impact. What keeps this out of the automatic-emergency tier is the PR:L requirement - the attacker must first get code running on the device, typically via a malicious or trojanized app, which raises the bar above a pure remote-exploitation bug. Against that, the blast radius is enormous: a single successful escalation converts a sandboxed app into full device control, so even a mid-sized municipal IT team in rybnik managing a fleet of field devices should treat this as urgent once the bulletin's firmware images are validated on their hardware. Several signals are missing rather than negative and should not be read as reassurance: no EPSS score was supplied, there is no CISA KEV entry, and there is no confirmed public proof-of-concept, so this is best characterized as a high-value target for exploit developers rather than a confirmed widespread campaign. Absence of KEV and POC data here reflects a lack of reporting, not a demonstrated lack of interest - Android kernel LPEs are routinely converted into commercial and criminal exploit chains. Confirm with the vendor whether the flaw is reachable from the untrusted app sandbox or only from an already-elevated context (e.g. an ADB shell or shell user), since that distinction materially changes the practical risk profile.

An attacker convinces a user to install a seemingly benign application, or distributes one through a third-party store, and the app - running with ordinary sandbox privileges - sends crafted input to the vulnerable kernel interface to trigger the missing validation checks. Because the flaw requires no additional execution privileges and no user interaction beyond the initial installation, the app then obtains kernel-level code execution, escapes its sandbox, and can read credentials, harvest messages and photos, or install persistent malware. No public exploit code was identified at time of analysis, but the local, low-complexity nature of the bug makes independent weaponization straightforward for a competent attacker.