Four confirmed-exploited vulnerabilities span the two layers that make up almost every Android device sold today: three in the Android Framework itself, and one in the Qualcomm chipsets that power a large share of the Android hardware base. Together they describe a mobile stack where privilege escalation is achievable from both the software layer Google controls and the silicon layer its OEM partners depend on.
| CVE | CVSS | Component | Added to KEV |
|---|---|---|---|
| CVE-2025-48595 | 8.4 | Android Framework (integer overflow) | 2 Jun 2026 |
| CVE-2025-48572 | 7.8 | Android Framework (permission bypass) | 2 Dec 2025 |
| CVE-2025-48633 | 5.5 | Android Framework (Device Owner logic error) | 2 Dec 2025 |
| CVE-2026-21385 | 7.8 | Qualcomm Multiple Chipsets (memory corruption) | 3 Mar 2026 |
Why local privilege escalation is Android's dominant exploited-bug pattern
None of these four vulnerabilities requires user interaction, and none is a remote network attack. CVE-2025-48595 is an integer overflow in Framework code that leads to code execution "in multiple locations" per Google's own advisory language, requiring no additional execution privileges. CVE-2025-48572 lets an app launch activities from the background by bypassing a permissions check, again in multiple locations. CVE-2026-21385 is memory corruption in Qualcomm's memory-allocation alignment handling — silicon-level, not Android-version-specific, meaning it follows the chipset across whichever OEM skin or Android release sits on top of it. This is the recurring shape of confirmed Android exploitation: a foothold app, already installed through some other means, using one of these bugs to escalate from limited app-sandbox privileges to broader system access. The value to an attacker isn't initial access — it's turning a toehold into full device control.
CVE-2025-48633 is the outlier worth reading closely. Its NVD description is unusually specific: a logic error in hasAccountsOnAnyUser of DevicePolicyManagerService.java creates "a possible way to add a Device Owner after provisioning." Device Owner is Android's highest management privilege tier, normally set only during initial device provisioning specifically so that a compromised or malicious actor can't retroactively claim it later and gain persistent, privileged control over the entire device — including the ability to silently install apps, wipe the device, or monitor activity in ways an ordinary app can never do. A logic flaw that lets Device Owner status be added after that window closes undermines the entire security assumption enterprises rely on when they use mobile device management to control a fleet of Android hardware.
Why the chipset layer deserves separate tracking from the OS layer
Qualcomm's CVE-2026-21385 sits underneath the Android Framework, in a silicon and driver layer that Google's monthly security bulletin bundles in but does not itself control the patch timeline for. Qualcomm ships the fix to OEMs, and each OEM then has to build, test, and push a device-specific update — a supply chain with more hops and more variable latency than a pure Google Framework patch. That's why this cluster tracks Qualcomm memory corruption as a distinct risk category from Framework bugs, even though both land in the same monthly Android security bulletin and both were confirmed exploited within roughly the same quarter: the responsible-party chain, and therefore the realistic timeline to a device actually receiving the fix, differs meaningfully between the two.
What to check this week
Confirm your mobile device management platform enforces the latest Android security patch level, not just an OS version number — a device can be on a current Android release while still missing the specific monthly Framework patch that closes these bugs.
Audit which devices in your fleet have Device Owner provisioning enabled, and verify none show unexplained changes to that status outside your organization's normal provisioning workflow, given CVE-2025-48633's specific mechanism.
Cross-reference device chipset models against Qualcomm's affected list for CVE-2026-21385 — this is a silicon-level bug that persists across Android version upgrades on the same hardware.
Treat any BYOD or unmanaged Android device with elevated suspicion if it cannot demonstrate current patch status, since these are exactly the local-privilege bugs that convert an already-compromised app into full device control.
A closing note on the OEM patch gap
Android's patch ecosystem has always had a structural lag between Google's monthly bulletin and an individual OEM's device-specific rollout, and a chipset-level bug like CVE-2026-21385 sits at the far end of that lag — Qualcomm ships a fix to OEMs, who then have to validate and push it per device model. Any fleet audit of these four CVEs needs to check actual patch receipt per device, not just "is a fix theoretically available."
A final consideration on enterprise mobility programs
Organizations running formal enterprise mobility or BYOD programs should treat CVE-2025-48633's Device Owner logic flaw as a prompt to re-verify their entire provisioning workflow end to end, not just patch the specific bug — a management-tier privilege escalation bug is exactly the kind of finding that warrants confirming the broader control still behaves as designed.
How Safeguard helps
Safeguard's continuous inventory extends visibility to mobile and embedded hardware alongside traditional infrastructure, tracking Android Framework patch levels and underlying chipset exposure together so that a fleet's actual patch posture — not just its nominal OS version — is what drives remediation priority.
