Am I vulnerable?
CVE-2025-48595 is an integer overflow in the Android Framework that lets a local, unprivileged app escalate to code execution in a privileged context. It affects Android 14, 15, 16, and 16-qpr2, and Google fixed it in the 2026-06-01 security patch level (June 2026 Android Security Bulletin). Google states there are indications it "may be under limited, targeted exploitation," and CISA added it to the Known Exploited Vulnerabilities catalog on 2026-06-02.
This is a local flaw (NVD AV:L), not a remote one. It does not compromise a device over the network by itself. Its value to an attacker is as the escalation stage of a chain: something first runs code on the device (a malicious app, or a remote browser or messaging exploit), and then this bug turns that foothold into system-level control with no user interaction and no special permissions required.
Affected versions
| Product |
Vulnerable |
Fixed in |
| Android Framework |
Android 14, 15, 16, 16-qpr2 below the 2026-06-01 patch level |
2026-06-01 security patch level (or later) |
Diagnostic checks (read-only)
The single question that matters is: is the device's security patch level 2026-06-01 or later?
- On the device: Settings, then About phone, then Android version, then read "Android security update." A date of 2026-06-01 or later is patched; anything earlier is vulnerable.
- Over ADB (managed or developer devices):
adb shell getprop ro.build.version.security_patch returns the patch level as YYYY-MM-DD. Compare against 2026-06-01.
- Across a fleet: pull the security patch level from your MDM/EMM inventory (Intune, Workspace ONE, Jamf, Google endpoint management) and list every device below 2026-06-01.
- OEM patch lag: the fix exists upstream at the 2026-06-01 level, but availability depends on the manufacturer and carrier. A device on the June bulletin from one OEM may still be waiting on another, so verify by the reported patch-level date, not by the calendar.
Vulnerability
Google's bulletin describes it tersely: "In multiple locations, there is a possible way to achieve code execution due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation." NVD scores it CVSS 8.4 HIGH (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), and Google rates it High severity.
Mechanically, an integer overflow in a Framework code path causes a size or index calculation to wrap, which leads to an undersized allocation or an out-of-bounds access, which in turn corrupts memory the attacker can steer toward controlled code execution. Because the vulnerable code runs in the Android Framework (the privileged system layer above apps), successful exploitation crosses the app-to-system boundary. The PR:N and UI:N parts of the vector are what make it dangerous in practice: the triggering app needs no granted permissions and the victim does not have to tap anything.
Two things separate this from the hundreds of Framework EoP bugs Google patches each year. First, the confirmed in-the-wild exploitation: Google rarely flags "limited, targeted exploitation," and when it does, the bug is almost always part of a real attack chain rather than a theoretical finding. Second, the CISA KEV listing (added 2026-06-02) makes it a compliance item for U.S. federal agencies and a strong prioritization signal for everyone else. Note that this is popularity and confirmed exploitation driving urgency, not an EPSS spike; EPSS has stayed low precisely because this is targeted, not mass-scale.
Threat model
Who would exploit this: the "limited, targeted exploitation" language and the local-EoP shape fit the mercenary-spyware and targeted-intrusion pattern, where a well-resourced operator chains a remote entry bug with a local escalation to fully compromise a specific person's phone. This is not commodity malware territory, and we do not attribute it to any named actor absent primary sourcing. What is documented is the exploitation itself (Google's note and the KEV listing), not who is behind it.
What they gain: escalation from an unprivileged app context to the Framework's privileged context, which on a phone means the keys to the device: microphone and camera access, location, messages and call content, stored files, and credentials, plus the persistence and stealth that make targeted spyware effective.
Attack chain: initial code execution on the device (a malicious or trojanized app, or a remote exploit in a browser or messaging app) provides the unprivileged foothold, then CVE-2025-48595 escalates that foothold to system-level control with no user interaction. From there the operator installs surveillance tooling and persistence.
Blast radius: a single device, but completely. For an individual this is total loss of privacy on their primary personal device. For an organization, a compromised phone belonging to a high-value target exposes corporate mail, MFA prompts and authenticator apps, VPN and SSO sessions, and anything else that device can reach.
Mitigation
Patch
Update affected devices to the 2026-06-01 security patch level or later. This is the only real fix, since the vulnerability is in the Framework itself.
| Product |
Fixed level |
Notes |
| Android Framework |
2026-06-01 security patch level |
Ships in the June 2026 Android Security Bulletin; OEM rollout timing varies |
Compensating controls
Because the fix depends on OEM rollout, reduce exposure while updates propagate:
- Enforce a minimum patch level in MDM/EMM. Set a compliance policy requiring 2026-06-01 or later, and block or quarantine non-compliant devices from corporate resources (conditional access).
- Shrink the local attack surface. Keep Google Play Protect enabled, block sideloading and third-party app stores via policy, and remove unused apps. The bug needs local code execution first, so fewer untrusted apps means fewer footholds.
- Prioritize high-risk users. Because exploitation is targeted, update executives, journalists, and other likely targets first, and consider Android's Advanced Protection Program for them.
- Deploy Mobile Threat Defense on managed devices to flag anomalous app and device behavior that may indicate an active chain.
Detection
Be honest about what applies here: an on-device Android privilege escalation is not something you catch with network Sigma rules or host YARA signatures. There is no server log line and no dropped-file artifact on your infrastructure. The practical detections are fleet and device oriented.
Patch-level compliance (the primary detection). Query your MDM/EMM for ro.build.version.security_patch (or the equivalent inventory field) across all Android devices and alert on anything below 2026-06-01. That list is your exposure, and closing it is both the detection and the fix.
# Per device, over ADB (managed/dev devices):
adb shell getprop ro.build.version.security_patch
# Vulnerable if the returned YYYY-MM-DD is earlier than 2026-06-01.
Mobile Threat Defense (MTD) telemetry. On managed fleets, MTD agents (and Google Play Protect on the device) are the realistic sensors for post-exploitation behavior: unexpected privilege use, anomalous processes, or known-malicious apps. Treat an MTD alert on a below-patch device as high priority.
Play Integrity / attestation. For your own apps and for conditional access, device-integrity attestation can gate access from devices that fail integrity checks, limiting what a compromised phone can reach.
What does not apply: perimeter IDS, web-server Sigma, and file-based YARA. Do not spend effort writing those for this CVE. The effort belongs in fleet patch-level compliance and MTD coverage.
References