In hasImage of Notification

CVE-2026-0025 is an Android Framework information-disclosure bug in Notification.java's hasImage() handling, disclosed on 2026-03-02. Google lists affected AOSP versions as Android 14, 15, 16, and 16-qpr2 in the 2026-03-01 patch level. From the AOSP fix, the issue appears tied to overly permissive parsing of EXTRA_MESSAGES / messaging-style notification content, where unexpected parcelable content could cross permission boundaries during notification processing and expose data across Android users or profiles.

Google's HIGH 8.4 score is technically defensible in a lab because the bug can yield high-impact local compromise on a device with no user interaction once malicious code is running. In enterprise reality, though, the decisive friction is attacker position: this starts with local code execution on the handset, which usually means a malicious app is already installed or an adversary already has code running on-device. That makes it a post-initial-access mobile containment failure, not an internet-scale patch emergency.

Why this verdict

• Downgrade for attacker position: AV:L on Android means the adversary needs code execution on the handset first, usually via a malicious app or another prior compromise.
• Downgrade for exposure population: this is not internet-reachable and not meaningfully scannable; only devices already carrying attacker code are in play.
• Downgrade for blast radius: even successful exploitation is generally bounded to one device and its local users/profiles rather than enabling estate-wide lateral movement.
• Downgrade for threat intel: no KEV listing, no public exploitation evidence, and the supplied EPSS of 0.00004 all point away from urgent mass exploitation risk.
• Keep at MEDIUM, not LOW: enterprise Android work-profile and cross-user boundaries matter; if your mobile controls fail, this can still expose sensitive corporate data on affected devices.

Why not higher?

There is no remote entry point here. The chain starts after an attacker already has code running locally, which is a major compounding friction and a strong signal that the vendor CVSS overstates operational urgency for most enterprise fleets. The lack of KEV status, lack of active exploitation evidence, and non-scannable nature all push it down.

Why not lower?

This is still a real platform security boundary failure inside Android Framework, not a cosmetic bug. On BYOD, COPE, or work-profile-heavy fleets, cross-user or cross-profile disclosure can directly impact enterprise data if a malicious app slips onto the device.

1. Block sideloading — Enforce managed app installation only through Android Enterprise / Play EMM APIs, and disable unknown sources wherever the device policy model allows it. For a MEDIUM verdict there is no mitigation SLA; if this is not already standard policy, fold it into the next mobile policy cycle while you patch within the 365-day remediation window.
2. Require Play Protect and MTD — Keep Google Play Protect enabled and pair it with Mobile Threat Defense or EDR-on-mobile where available so malicious-app delivery gets caught before this CVE matters. There is no mitigation SLA for MEDIUM, but this is the most practical risk reducer because it attacks the prerequisite rather than the bug.
3. Restrict profile notification exposure — Use MDM policies to minimize lock-screen and cross-profile notification content where business-tolerable, especially on BYOD and COPE devices carrying sensitive work data. There is no mitigation SLA for MEDIUM; implement during normal policy tuning if your mobile fleet uses work profiles heavily.
4. Inventory vulnerable patch levels — Use MDM or adb-based checks to identify devices on Android 14/15/16/16-qpr2 with a security patch level earlier than 2026-03-01. This is the operational control that turns the bulletin into an actionable target list ahead of normal remediation.

Run this on an auditor workstation with adb installed, not on the phone itself. Invoke it as ./check-cve-2026-0025.sh SERIAL or ./check-cve-2026-0025.sh for the single attached device; it needs no root, only adb access to read system properties.

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

set -u

SERIAL="${1:-}"
ADB_BIN="${ADB_BIN:-adb}"
REQUIRED_PATCH="2026-03-01"

adb_cmd() {
  if [ -n "$SERIAL" ]; then
    "$ADB_BIN" -s "$SERIAL" "$@"
  else
    "$ADB_BIN" "$@"
  fi
}

fail_unknown() {
  echo "UNKNOWN"
  exit 2
}

# Ensure adb is present
command -v "$ADB_BIN" >/dev/null 2>&1 || fail_unknown

# Ensure device connectivity
STATE="$(adb_cmd get-state 2>/dev/null || true)"
[ "$STATE" = "device" ] || fail_unknown

# Read Android release and security patch level
RELEASE="$(adb_cmd shell getprop ro.build.version.release 2>/dev/null | tr -d '\r')"
PATCH="$(adb_cmd shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')"
CODENAME="$(adb_cmd shell getprop ro.build.version.release_or_codename 2>/dev/null | tr -d '\r')"

[ -n "$PATCH" ] || fail_unknown

# Extract numeric major version from release/codename
MAJOR="$(printf '%s\n%s\n' "$RELEASE" "$CODENAME" | grep -Eo '^[0-9]+' | head -n1 || true)"
[ -n "$MAJOR" ] || fail_unknown

# Affected Android versions per advisory: 14, 15, 16, 16-qpr2
case "$MAJOR" in
  14|15|16)
    ;;
  *)
    echo "PATCHED"
    exit 0
    ;;
esac

# Patch level is ISO-like YYYY-MM-DD, so lexical compare is valid.
if [[ "$PATCH" < "$REQUIRED_PATCH" ]]; then
  echo "VULNERABLE"
  exit 1
else
  echo "PATCHED"
  exit 0
fi

Sources

1. Android Security Bulletin—March 2026
2. NVD entry for CVE-2026-0025
3. OpenCVE mirror of CVE CNA record
4. AOSP fix commit 014dea279c49d532bc4fbbdebbc024133967b6a8
5. AOSP diff for the fix
6. CISA Known Exploited Vulnerabilities Catalog
7. Android Help: Check & update your Android version
8. FIRST EPSS overview