AAT

CVE-2025-21615 is an information disclosure flaw in AAT (Another Activity Tracker) where Android builds before v1.26 let a malicious app on the *same device* read AAT data, including geolocation/GPX content. GitHub's advisory marks <= v1.25.2 as affected and v1.26 as patched; the fix notes point to an Android-side change limiting the exported file-sharing path.

The vendor's MEDIUM 5.5 is technically fair in CVSS terms, but operationally it's too loud for enterprise patch triage. This is AV:L + UI:R, requires a second malicious app to already land on the phone, hits a niche fitness app, and the blast radius is usually one user / one device / confidentiality only. For a team managing 10,000 hosts, that is backlog material unless you specifically manage Android devices with AAT installed.

Why this verdict

• Downgrade for attacker position: this is AV:L on Android and effectively requires a second malicious app on the same phone, so the attacker is already past the hardest part
• Downgrade for reachable population: AAT is a niche activity-tracker, not a mainstream enterprise platform, so most 10k-host fleets will have little to no installed base
• Keep it above IGNORE: the confidentiality impact is real because stored location history and GPX data can expose sensitive movement patterns

Why not higher?

There is no unauthenticated remote path, no server-side foothold, no tenant-wide blast radius, and no integrity/availability damage. Even successful exploitation usually compromises one user's stored activity data after the attacker has already landed code on that handset.

Why not lower?

This is still a genuine data-exposure flaw, not a theoretical hardening issue. If your org manages Android devices used for field work, executive protection, or sensitive travel, location leakage can matter even when the CVE is operationally narrow.

1. Inventory ch.bailu.aat — Use MDM, EMM, or app inventory to identify managed Android devices with AAT installed. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and use the inventory result to decide whether the CVE is even present in your fleet.
2. Block unapproved app installs — The exploit chain needs a second malicious app on the same device, so Managed Play allowlists, anti-sideload policy, and mobile threat defense directly attack the strongest prerequisite. For LOW, keep this in your standing mobile hardening program rather than spinning an emergency change.
3. Prefer work-profile / managed-device controls — Enterprise-managed Android modes reduce random app coexistence and make malicious local-app placement harder. That is a better risk reducer than treating this as a generic network vulnerability.
4. Update AAT where present — Where the app exists, move to v1.26 or later through your normal mobile app maintenance channel. For LOW, there is no special accelerated deadline; queue it as routine patch hygiene.

Run this from an auditor workstation with adb installed against a connected Android device or emulator. Example: ./check_aat_cve_2025_21615.sh emulator-5554 or ./check_aat_cve_2025_21615.sh R58M1234567; it needs ADB shell access but not root.

#!/usr/bin/env bash
# check_aat_cve_2025_21615.sh
# Verify whether Android package ch.bailu.aat is vulnerable to CVE-2025-21615.
# Vulnerable: AAT <= 1.25.2
# Patched:    AAT >= 1.26
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / not installed / unable to determine

set -euo pipefail

PKG="ch.bailu.aat"
DEVICE_ARG="${1:-}"
ADB=(adb)
if [[ -n "$DEVICE_ARG" ]]; then
  ADB+=( -s "$DEVICE_ARG" )
fi

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

version_ge() {
  # returns 0 if $1 >= $2
  local IFS=.
  local i
  local -a v1=($1) v2=($2)
  local len=${#v1[@]}
  if (( ${#v2[@]} > len )); then len=${#v2[@]}; fi
  for ((i=${#v1[@]}; i<len; i++)); do v1[i]=0; done
  for ((i=${#v2[@]}; i<len; i++)); do v2[i]=0; done
  for ((i=0; i<len; i++)); do
    local a=${v1[i]//[^0-9]/}
    local b=${v2[i]//[^0-9]/}
    a=${a:-0}
    b=${b:-0}
    if ((10#$a > 10#$b)); then return 0; fi
    if ((10#$a < 10#$b)); then return 1; fi
  done
  return 0
}

# Basic device reachability
"${ADB[@]}" get-state >/dev/null 2>&1 || fail_unknown "ADB device not reachable"

# Confirm package is installed
if ! "${ADB[@]}" shell pm path "$PKG" >/dev/null 2>&1; then
  fail_unknown "Package $PKG is not installed on target device"
fi

# Pull package metadata
DUMPSYS=$("${ADB[@]}" shell dumpsys package "$PKG" 2>/dev/null || true)
[[ -n "$DUMPSYS" ]] || fail_unknown "Unable to query package metadata"

VERSION_NAME=$(printf '%s\n' "$DUMPSYS" | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1 | tr -d '\r')
VERSION_CODE=$(printf '%s\n' "$DUMPSYS" | sed -n 's/.*versionCode=\([0-9][0-9]*\).*/\1/p' | head -n1 | tr -d '\r')

if [[ -z "$VERSION_NAME" && -z "$VERSION_CODE" ]]; then
  fail_unknown "Could not parse versionName/versionCode for $PKG"
fi

# Prefer versionName when present; fall back to versionCode.
if [[ -n "$VERSION_NAME" ]]; then
  if version_ge "$VERSION_NAME" "1.26"; then
    echo "PATCHED: $PKG versionName=$VERSION_NAME"
    exit 0
  else
    echo "VULNERABLE: $PKG versionName=$VERSION_NAME"
    exit 1
  fi
fi

# Fallback mapping from public release metadata: v1.26 corresponds to versionCode 40.
if [[ -n "$VERSION_CODE" ]]; then
  if (( VERSION_CODE >= 40 )); then
    echo "PATCHED: $PKG versionCode=$VERSION_CODE"
    exit 0
  else
    echo "VULNERABLE: $PKG versionCode=$VERSION_CODE"
    exit 1
  fi
fi

fail_unknown "Reached unexpected state"

Sources

1. NVD CVE-2025-21615
2. GitHub Security Advisory GHSA-pwpm-x58v-px5c
3. OSV record for CVE-2025-21615
4. AAT release v1.26
5. Fix commit 122fa650877f276e20eb958f77c2d4b06dc27b3b
6. AAT repository README
7. F-Droid package page for ch.bailu.aat
8. CISA Known Exploited Vulnerabilities catalog