In getComponentName of MediaButtonReceiverHolder

CVE-2025-48615 is an Android Framework flaw in MediaButtonReceiverHolder.java where getComponentName() could accept overlong component-name properties and end up with a persistence desynchronization tied to resource exhaustion. Google’s patch adds a MAX_COMPONENT_NAME_LENGTH check before building the ComponentName, which tells you the exploit path depends on feeding abnormally long package/class values into media button receiver state. NVD lists Android 13, 14, 15, and 16 as affected; Google later republished the fix in the June 2026 bulletin for updated AOSP versions 14, 15, 16, and 16-qpr2 after pulling the December 2025 entry because the original fix was incomplete.

The vendor’s HIGH/7.8 score is technically defensible in a sandbox-escape vacuum, but it overstates enterprise urgency. This is AV:L/PR:L: the attacker already needs code running on the device with low privileges, which usually means a malicious app, sideload, or prior foothold. No KEV listing, essentially floor-level EPSS, no public exploit traction, and no network exposure push this down to a fleet-management MEDIUM unless your mobile estate allows broad app installation or you treat Android local EoP chains as part of an active mobile threat model.

Why this verdict

• Local attacker only: vendor 7.8 assumes high impact after compromise, but AV:L/PR:L means the attacker already has code running on the endpoint. For enterprise triage, that is a major downward adjustment because it is not an initial-access bug.
• Reachable population is narrow: the chain requires an affected Android build plus app execution plus a niche media-session code path. Managed Play, blocked sideloading, and app allowlisting materially reduce how many fleet devices can even reach step one.
• Threat telemetry is cold: no KEV, no credible public PoC surfaced, and EPSS 0.00006 is effectively nil. That does not make the bug fake, but it does make the vendor HIGH feel inflated for Monday-morning patch ordering.
• Patch history cuts both ways: Google removed the December 17, 2025 bulletin entry because the original fix was incomplete, then reissued the issue in June 2026. That raises confidence the bug matters, but it does not erase the local-only friction.

Why not higher?

There is no remote reachability, no unauthenticated attack path, and no evidence of active exploitation. A 10,000-device enterprise should reserve HIGH/CRITICAL for vulnerabilities that create broad reachable population or urgent threat pressure; this one does neither.

Why not lower?

This is still a real local privilege-escalation class flaw in the Android Framework, not a cosmetic bug. If an attacker does land a malicious app on a vulnerable device, local EoP bugs are exactly what they chain next, so it should not be relegated to backlog hygiene.

1. Block sideloading — Use MDM/EMM policy to disable unknown-source installs and restrict developer options where possible. This attacks the biggest real-world prerequisite — local attacker code on the device — and for a MEDIUM verdict there is no mitigation SLA, so apply it as standard hardening while you work the 365-day remediation window.
2. Enforce app allowlisting — Require Managed Google Play or an approved enterprise catalog so only vetted packages can run on corporate-owned devices. This meaningfully reduces the fraction of devices that can host the malicious app needed to start the chain; with MEDIUM, there is no mitigation SLA, but it is still the best control if patch uptake lags.
3. Prioritize high-risk mobile cohorts — Pull forward devices used by executives, admins, field staff, and users with broad app-install latitude, especially BYOD or lightly managed Android fleets. Even without a mitigation SLA, those cohorts deserve earlier remediation because local EoP chains matter more when app trust is weaker.
4. Audit Android patch compliance — Use MDM or adb-based spot checks to find devices below security patch level 2026-06-05. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but inventory first so the remediation plan is real rather than aspirational.

Run this on an auditor workstation with adb installed, not on the device itself. Invoke it as ./check-cve-2025-48615.sh for the only attached device or ./check-cve-2025-48615.sh SERIAL for a specific handset; it needs USB debugging or authorized adb over network, but no root.

#!/usr/bin/env bash
# check-cve-2025-48615.sh
# Determine likely exposure to CVE-2025-48615 on an Android device via adb.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

SERIAL="${1:-}"
ADB=(adb)
if [ -n "$SERIAL" ]; then
  ADB+=( -s "$SERIAL" )
fi

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

getprop_safe() {
  local key="$1"
  "${ADB[@]}" shell getprop "$key" 2>/dev/null | tr -d '\r'
}

if ! command -v adb >/dev/null 2>&1; then
  fail_unknown "adb not found in PATH"
fi

STATE=$("${ADB[@]}" get-state 2>/dev/null || true)
if [ "$STATE" != "device" ]; then
  fail_unknown "no authorized adb device detected"
fi

RELEASE=$(getprop_safe ro.build.version.release)
PATCH=$(getprop_safe ro.build.version.security_patch)
BUILDID=$(getprop_safe ro.build.id)
SDK=$(getprop_safe ro.build.version.sdk)

if [ -z "$RELEASE" ] || [ -z "$PATCH" ]; then
  fail_unknown "could not read Android release or security patch level"
fi

# Normalize release to major version where possible (e.g., 14, 15, 16)
MAJOR="${RELEASE%%.*}"
case "$MAJOR" in
  13|14|15|16)
    ;;
  *)
    echo "PATCHED: Android release=$RELEASE build=$BUILDID sdk=$SDK patch=$PATCH (not in known affected major-version set)"
    exit 0
    ;;
esac

# Compare YYYY-MM-DD patch strings numerically.
PATCH_NUM=$(echo "$PATCH" | tr -d '-')
FIX_NUM="20260605"

if ! echo "$PATCH_NUM" | grep -Eq '^[0-9]{8}$'; then
  fail_unknown "unexpected security patch format: $PATCH"
fi

if [ "$PATCH_NUM" -ge "$FIX_NUM" ]; then
  echo "PATCHED: Android release=$RELEASE build=$BUILDID sdk=$SDK patch=$PATCH (>= 2026-06-05)"
  exit 0
fi

echo "VULNERABLE: Android release=$RELEASE build=$BUILDID sdk=$SDK patch=$PATCH (< 2026-06-05)"
exit 1

Sources

1. NVD entry for CVE-2025-48615
2. Android Security Bulletin — December 2025
3. Android Security Bulletin — June 2026
4. AOSP patch diff for CVE-2025-48615
5. MediaButtonReceiverHolder.java code path
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS project