← Back to Feed CACHED · 2026-10-09 02:25:11 · CACHE_KEY CVE-2025-48595
CVE-2025-48595 · CWE-190 · Disclosed 2026-06-01

Android Framework Integer Overflow Local Privilege Escalation

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

A smuggled lockpick that only works once someone lets you through the front door

CVE-2025-48595 is an integer overflow (CWE-190) in the Android Framework — the core API and services layer sitting between applications and the Linux kernel. When arithmetic operations on integer values skip bounds checks in multiple Framework code paths, an attacker who already has local code execution (typically via a malicious app) can corrupt buffer-size calculations, overwrite adjacent memory, and escalate to system-level privileges. No additional execution privileges and no user interaction are required for the elevation step itself. The bug spans Android 14, 15, 16, and 16-QPR2 — effectively every supported Android version in circulation. Google patched it in the June 2026 Android Security Bulletin at patch levels 2026-06-01 and 2026-06-05.

Google rated this HIGH at CVSS 8.4, and that label is *directionally correct* but slightly generous for enterprise risk. The CVSS vector (AV:L/AC:L/PR:N/UI:N) accurately models the local privilege-escalation step in isolation, but it doesn't account for the prerequisite: initial code execution on the device, which almost always means tricking a user into installing a malicious app or chaining a separate remote-code-execution bug. Google confirmed "limited, targeted exploitation" consistent with commercial spyware campaigns aimed at journalists, executives, and government officials — not commodity malware sweeping corporate fleets. That two-stage chain, the absence of a public PoC, and the per-device blast radius (no domain or fleet cascade) justify a modest downward adjustment to 7.5 while keeping the verdict firmly in HIGH territory, especially given KEV listing.

"KEV-listed Android EoP zero-day demands immediate MDM-enforced patching across your mobile fleet."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Initial access via malicious application

The attacker delivers a trojanized or purpose-built Android application to the target device. In observed campaigns, this has been achieved through spear-phishing links, watering-hole sites, or side-loaded APKs. The app may appear legitimate and pass basic Play Store review, or it may target devices with sideloading enabled. Once installed, the app gains a normal unprivileged execution context within the Android sandbox.
Conditions required:
  • Target device running Android 14, 15, 16, or 16-QPR2 with patch level before 2026-06-01
  • User installs or is tricked into installing a malicious application
  • OR a separate remote-code-execution vulnerability delivers the payload
Where this breaks in practice:
  • Google Play Protect actively scans for known malicious patterns and blocks sideloaded threats
  • Enterprise MDM policies can disable installation from unknown sources
  • User must take an affirmative action (install) or a secondary RCE must exist
Detection/coverage: Mobile Threat Defense (MTD) solutions such as Lookout, Zimperium, or Microsoft Defender for Endpoint on Android can flag suspicious APKs at install time.
STEP 02

Trigger integer overflow in Android Framework

From the unprivileged app context, the attacker invokes Framework API calls that pass crafted integer values into vulnerable code paths. The integer overflow causes buffer-size calculations to wrap around, resulting in an undersized allocation. Subsequent writes exceed the allocation boundary, enabling controlled heap corruption. Multiple Framework locations are affected, giving the attacker several independent trigger paths.
Conditions required:
  • Code execution within any Android app sandbox
  • Vulnerable Framework code path reachable from unprivileged context
Where this breaks in practice:
  • ASLR and stack canaries on modern Android raise exploitation complexity
  • SELinux (enforcing mode) constrains what even a corrupted process can access
  • No public PoC or exploit code exists — crafting a reliable exploit requires significant reverse-engineering effort
Detection/coverage: Runtime integrity monitors and SELinux audit logs may flag anomalous system-call patterns. Standard Android logging does not reliably surface this.
STEP 03

Escalate to system-level privileges

The heap corruption is leveraged to hijack control flow or overwrite critical kernel/system data structures, granting the attacker SYSTEM or root-equivalent privileges. At this point the attacker breaks out of the Android app sandbox entirely. On devices without additional hardening (e.g., Samsung Knox, Google Tensor Titan M2 attestation), this grants full device compromise.
Conditions required:
  • Successful exploitation of the integer overflow in Step 2
  • Device not running hardware-backed integrity attestation that blocks privilege escalation
Where this breaks in practice:
  • Hardware-backed keystores (Titan M2, Samsung Knox) can limit post-exploitation lateral value
  • MTE (Memory Tagging Extension) on Pixel 8+ and newer ARM chips may crash the exploit before completion
Detection/coverage: Google Play Protect's on-device ML model can detect behavioral indicators of privilege escalation. SafetyNet/Play Integrity API attestation will flag a compromised device.
STEP 04

Post-exploitation: data exfiltration and persistence

With system privileges, the attacker accesses private messages, email, credentials cached by corporate apps, camera/microphone, and location data. In spyware campaigns, a persistent implant is installed that survives app restarts. Corporate data accessible through MDM-managed work profiles, VPN credentials, and OAuth tokens become available for exfiltration or lateral movement into enterprise cloud services.
Conditions required:
  • Successful privilege escalation in Step 3
  • Corporate data present on the device (email, VPN, SSO tokens)
Where this breaks in practice:
  • Enterprise conditional-access policies can revoke tokens if device compliance drops
  • MDM-enforced work profile isolation limits what data is reachable even with root in some configurations
  • Corporate apps using certificate pinning and hardware-backed keys resist credential extraction
Detection/coverage: MDM compliance checks will detect a device falling below the required security patch level. Cloud CASB/IdP logs can detect anomalous access patterns from compromised device tokens.
03 · Compensating Control

1
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Push June 2026 security patch via MDM immediately — Enforce security patch level 2026-06-05 or later across all managed Android devices using your MDM platform (Intune, Workspace ONE, JAMF, etc.). This is the definitive fix. Because CVE-2025-48595 is KEV-listed with active exploitation, the noisgate mitigation SLA is overridden — deploy within hours, not days. Create a compliance policy that flags any device below 2026-06-05 as non-compliant and triggers automated remediation (forced update or access revocation).
2
HIGH 7.5→MEDIUM 5.5
SEVERITY REDUCED
Enforce conditional access to block unpatched devices — Configure your IdP (Azure AD/Entra ID, Okta, Google Workspace) conditional-access policies to require Android security patch level 2026-06-05 or later for access to corporate resources (email, SSO apps, VPN). Unpatched devices should be quarantined to a remediation portal. This doesn't fix the vulnerability but eliminates the value of post-exploitation credential theft. Deploy within hours alongside the patch push.
3
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Disable sideloading via MDM policy — Push an MDM policy that disables "Install from unknown sources" on all managed Android devices. This eliminates the most common initial-access vector for targeted spyware delivery. Combined with Google Play Protect enforcement, this significantly raises the bar for delivering the malicious app needed to trigger the EoP chain. Deploy within 3 days per the noisgate mitigation SLA override for KEV-listed vulnerabilities.
4
HIGH 7.5→HIGH 6.5
Enable Google Play Protect and MTD on all managed devices — Ensure Google Play Protect is enabled and not overridden on all managed Android devices. For higher-assurance environments, deploy a Mobile Threat Defense (MTD) agent such as Lookout, Zimperium, or Microsoft Defender for Endpoint. MTD provides behavioral detection of privilege-escalation attempts and malicious app patterns that Play Protect may miss. This adds a detection layer at the initial-access and exploitation stages.
5
HIGH 7.5→HIGH 6.0
Revoke and rotate OAuth/SSO tokens for high-risk users — For executives, legal, finance, and other high-profile users who match the targeted-exploitation profile, force token revocation and re-authentication from compliant devices only. This limits the blast radius of any device that may have been compromised before the patch was applied. Combine with IdP session anomaly monitoring.
What doesn't work
  • Network segmentation / VLAN isolation — This is a local privilege-escalation vulnerability on a mobile device. Network controls don't prevent on-device exploitation or data access. The attack and its impact are entirely local to the handset.
  • Traditional EDR agents — Desktop/server EDR platforms (CrowdStrike Falcon, SentinelOne, Carbon Black) do not run on Android. Only purpose-built MTD agents provide equivalent detection on mobile. Don't assume your EDR covers your mobile fleet.
  • VPN enforcement — Forcing VPN on managed Android devices protects network traffic in transit but does nothing to prevent local privilege escalation. A compromised device with root access can read data before it enters the VPN tunnel.
  • App-level containerization alone — Work-profile containerization (Android Enterprise) provides *some* isolation, but a system-level compromise via this EoP can cross container boundaries. Do not rely on work profiles as the sole compensating control.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusActively exploited. Google confirmed "limited, targeted exploitation" in the June 2026 bulletin. CISA added CVE-2025-48595 to the KEV catalog on 2026-06-02. Exploitation pattern is consistent with commercial spyware vendors targeting journalists, executives, and government officials.
Proof-of-conceptNo public PoC available. No repositories found on GitHub named after CVE-2025-48595. No entries on pocindex.io, ExploitDB, Nuclei templates, or Metasploit modules as of 2026-10-09. Exploitation appears limited to sophisticated threat actors with proprietary tooling.
EPSS score0.01714 (1.71%) — approximately 91st–93rd percentile. This places it well above the median CVE but below mass-exploited vulnerabilities. The score reflects the local attack vector and absence of public exploit code offsetting the confirmed exploitation signal.
KEV statusListed. Added 2026-06-02 by CISA. BOD 22-01 required federal agencies to remediate by the deadline (typically 2–3 weeks from listing). The KEV listing alongside CVE-2022-0492 (Linux cgroups) in the same batch underscores CISA's focus on mobile/OS-level threats.
CVSS vectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 8.4 HIGH. Local vector with low complexity, no privileges, no user interaction, unchanged scope, full CIA impact. The UI:N rating is technically correct for the EoP step but masks the practical requirement for initial app installation.
Affected versionsAndroid 14, 15, 16, and 16-QPR2. All patch levels prior to 2026-06-01 are vulnerable. This covers virtually every actively supported Android device in enterprise fleets.
Fixed versionsSecurity patch level 2026-06-01 (Framework fix) or 2026-06-05 (full bulletin including kernel and vendor components). Google Pixel devices received OTA on 2026-06-02. Samsung, OnePlus, and other OEMs vary by region and carrier — typical lag is 2–8 weeks. GrapheneOS included the fix promptly.
Scanning/exposureNot applicable for Shodan/Censys/GreyNoise — this is a local mobile vulnerability, not a network-exposed service. Enterprise exposure is measured by MDM patch-level compliance dashboards. Organizations without MDM visibility over Android devices have zero telemetry into their exposure.
Disclosure date2026-06-01 — disclosed in the Android Security Bulletin. Google notified OEM partners at least one month prior to public disclosure.
Reporting researcherNot disclosed. Google has not attributed discovery to any named researcher, Google TAG, or external organization. The deliberate withholding of attribution during active exploitation is consistent with sensitive intelligence equities or ongoing law-enforcement coordination.

Sources.

  1. Google Android June 2026 Security Bulletin
  2. CISA KEV Catalog — CVE-2025-48595 Added June 2, 2026
  3. Help Net Security — Google fixes actively exploited Android vulnerability
  4. Mishcon de Reya — Android Framework under fire from latest zero-day
  5. Cyber Insider — Android June 2026 update patches actively exploited zero-day
  6. Threat-Modeling.com — Android Framework Zero-Day Actively Exploited
  7. SentinelOne Vulnerability Database — CVE-2025-48595
  8. The Hacker News — Google June 2026 Android Update Patches 124 Flaws
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.5/10)

Why this verdict

  • Initial access friction: The CVSS vector rates UI:N, but the practical attack chain requires delivering a malicious app to the target device first — either through social engineering (user must install), a watering-hole, or chaining a separate RCE. This prerequisite is a meaningful gate that the raw score doesn't capture, justifying a ~0.5-point deduction.
  • Exploitation exclusivity: No public PoC exists four months post-disclosure. Active exploitation is confirmed but described as "limited, targeted" — consistent with commercial spyware vendors (e.g., NSO Group, Intellexa lineage) or state-sponsored actors, not commodity crimeware. This limits the population of realistic attackers to well-funded adversaries with proprietary tooling.
  • Per-device blast radius: Compromising an Android device yields host-level impact — private data, credentials, camera/microphone access. It does *not* directly enable domain takeover, fleet compromise, or supply-chain pivot. Lateral movement into enterprise cloud services is possible via stolen OAuth tokens but requires additional steps and is detectable by IdP anomaly monitoring.
  • Role multiplier: Android devices occupy endpoint/mobile roles in the enterprise. They are not identity providers, domain controllers, hypervisors, backup systems, CI/CD infrastructure, or network edge appliances. Even executive phones, while high-value targets for espionage, produce host-level blast radius (one device's data), not fleet-level or domain-level compromise. No high-value infrastructure role floor applies. The verdict floor remains set by the KEV listing and confirmed exploitation, which anchors it at HIGH.
  • KEV and exploitation override: Despite friction-based downward pressure, the CISA KEV listing and confirmed in-the-wild exploitation prevent any downgrade below HIGH. Active weaponization by sophisticated threat actors targeting high-profile individuals means the residual risk is real and immediate, even if the attack surface is narrower than a network-exposed RCE.

Why not higher?

CRITICAL would require either a remotely exploitable attack vector without prerequisite access, fleet-scale or domain-scale blast radius, or the affected component occupying a canonical high-value infrastructure role (DC, hypervisor, network edge). CVE-2025-48595 requires local code execution as a prerequisite, produces per-device impact only, and affects mobile endpoints — not identity or infrastructure tier components. The "limited, targeted" exploitation descriptor further confirms this is not a mass-weaponized threat.

Why not lower?

MEDIUM or below would be inappropriate given confirmed active exploitation and CISA KEV listing. The attack chain, while requiring initial access, is low-complexity once the app is on-device (AC:L, PR:N, UI:N for the EoP), affects every supported Android version in circulation, and grants full system compromise including credential theft that can pivot into enterprise cloud resources. The absence of a public PoC is a temporal friction that could evaporate at any time.

06 · Verification

Crowdsourced verification payload.

Run this script on each Android device via adb shell from a connected workstation, or deploy it as a remote command through your MDM platform's script-execution feature. Requires adb access to the target device (USB debugging enabled or MDM agent with shell access). Example: adb shell sh /sdcard/check_cve_2025_48595.sh

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/system/bin/sh
# check_cve_2025_48595.sh
# Checks whether Android device is patched against CVE-2025-48595
# (Android Framework integer overflow, patched in 2026-06-01 SPL)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

PATCH_LEVEL=$(getprop ro.build.version.security_patch 2>/dev/null)

if [ -z "$PATCH_LEVEL" ]; then
  echo "UNKNOWN - Unable to read security patch level property"
  exit 2
fi

echo "Detected security patch level: $PATCH_LEVEL"

# Compare patch level date string (YYYY-MM-DD format)
# CVE-2025-48595 is fixed in security patch level 2026-06-01 or later
FIXED_DATE="2026-06-01"

if [ "$PATCH_LEVEL" \< "$FIXED_DATE" ]; then
  echo "VULNERABLE - Security patch level $PATCH_LEVEL is before $FIXED_DATE"
  echo "CVE-2025-48595 (Android Framework integer overflow EoP) is NOT patched"
  echo "Action: Update to security patch level 2026-06-05 or later immediately"
  exit 1
else
  echo "PATCHED - Security patch level $PATCH_LEVEL is at or after $FIXED_DATE"
  echo "CVE-2025-48595 is addressed in this patch level"
  exit 0
fi