In writeToParcel of WindowInfo

CVE-2026-0007 is an Android framework elevation-of-privilege issue in WindowInfo.cpp affecting Android 14, 15, and 16 per Google’s March 2026 bulletin. The public description frames it as a tapjacking or overlay problem that could trick a user into accepting a permission, while the linked AOSP fix truncates WindowInfo.name during parcelling as a mitigation for a one-way Binder call overflow; either way, the bug sits in local framework/UI plumbing, not a remotely reachable service.

Google’s 8.6 HIGH score is technically defensible in a lab because the post-exploit impact on one handset can be large, but it overrates enterprise urgency. Real attackers need code running on the device first, the reachable population is limited to Android 14–16 endpoints, there is no KEV listing or verified in-the-wild use, EPSS is effectively zero, and CISA’s ADP view lowers the vector to 7.8 with unchanged scope and marks exploitation none and automatable no.

Why this verdict

• Local attacker position required: AV:L means the attacker already needs code execution on the handset, which is a major downward adjustment from vendor-style severity.
• Reachable population is narrow: only Android 14/15/16 are listed, and many enterprise fleets further reduce reachability with managed app stores, allowlisting, and sideloading restrictions.
• No exploitation pressure: no KEV listing, no validated in-the-wild campaign evidence, and EPSS is near-zero, so there is no current threat-intel amplifier forcing an elevated patch priority.

Why not higher?

This is not remotely reachable and it is not a pre-auth compromise vector. To matter, the adversary must first plant or run an app on the device, then successfully navigate framework-specific exploit conditions on a mobile platform that already hardens overlay abuse.

Why not lower?

Once the attacker is on the device, the potential impact is still meaningful because a privilege lift on Android can expose enterprise app data, user content, and security-sensitive permissions. It is also a framework bug in a widely deployed mobile OS, so it deserves scheduled remediation rather than backlog oblivion.

1. Enforce managed app allowlisting — Restrict installs to Managed Google Play or your approved enterprise catalog so the attacker cannot easily satisfy the on-device code execution prerequisite. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but this should already be a standing control across the fleet.
2. Block sideloading and ADB for users — Disable unknown sources, developer options, and routine ADB access on production endpoints to cut off the most common delivery paths for local Android exploits. With no mitigation SLA for MEDIUM, treat this as policy hygiene to maintain during the remediation window.
3. Tighten overlay and accessibility abuse controls — Audit and minimize apps allowed to use overlay-like capabilities, accessibility services, or unusual UI automation patterns, because those are the natural companion controls for tapjacking-style abuse. Maintain this during the 365-day remediation window and prioritize higher-risk user groups first.
4. Use mobile threat defense telemetry — Enable detections for trojanized apps, suspicious permission changes, repeated framework crashes, and anomalous overlay behavior so you catch the prerequisite malware stage before this CVE matters. There is no mitigation SLA here, but this is the best compensating detection layer while patch adoption catches up.

Run this from an auditor workstation with adb installed against a connected Android device, or from your EMM/MDM remote shell if it exposes the same getprop values. Invoke it as ./check-cve-2026-0007.sh <adb-serial>; it needs access to adb, but no root on the device.

#!/usr/bin/env bash
# check-cve-2026-0007.sh
# Verify likely exposure to CVE-2026-0007 on an Android device via ADB.
# Usage: ./check-cve-2026-0007.sh <adb-serial>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u

if [ $# -ne 1 ]; then
  echo "Usage: $0 <adb-serial>"
  exit 3
fi

SERIAL="$1"
ADB_BIN="${ADB_BIN:-adb}"

if ! command -v "$ADB_BIN" >/dev/null 2>&1; then
  echo "UNKNOWN: adb not found in PATH"
  exit 2
fi

adb_cmd() {
  "$ADB_BIN" -s "$SERIAL" "$@"
}

if ! adb_cmd get-state >/dev/null 2>&1; then
  echo "UNKNOWN: device $SERIAL not reachable via adb"
  exit 2
fi

ANDROID_VER="$(adb_cmd shell getprop ro.build.version.release 2>/dev/null | tr -d '\r')"
SDK="$(adb_cmd shell getprop ro.build.version.sdk 2>/dev/null | tr -d '\r')"
PATCH="$(adb_cmd shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')"
FINGERPRINT="$(adb_cmd shell getprop ro.build.fingerprint 2>/dev/null | tr -d '\r')"

if [ -z "$PATCH" ] || [ -z "$SDK" ]; then
  echo "UNKNOWN: unable to read required Android properties"
  exit 2
fi

# Android version mapping:
# Android 14 -> SDK 34
# Android 15 -> SDK 35
# Android 16 -> SDK 36
case "$SDK" in
  34|35|36)
    AFFECTED_MAJOR="yes"
    ;;
  *)
    AFFECTED_MAJOR="no"
    ;;
esac

# Compare patch strings lexicographically because format is YYYY-MM-DD.
if [ "$AFFECTED_MAJOR" = "no" ]; then
  echo "PATCHED: device is not in the known affected major versions (sdk=$SDK, android=$ANDROID_VER, patch=$PATCH)"
  echo "Fingerprint: $FINGERPRINT"
  exit 0
fi

if [[ "$PATCH" < "2026-03-01" ]]; then
  echo "VULNERABLE: Android $ANDROID_VER (sdk=$SDK) with security patch $PATCH is older than 2026-03-01"
  echo "Fingerprint: $FINGERPRINT"
  exit 1
fi

if [[ "$PATCH" >= "2026-03-01" ]]; then
  echo "PATCHED: Android $ANDROID_VER (sdk=$SDK) with security patch $PATCH meets the bulletin floor for CVE-2026-0007"
  echo "Fingerprint: $FINGERPRINT"
  echo "Note: OEM backports can vary; verify vendor OTA contents if this is a heavily customized build."
  exit 0
fi

echo "UNKNOWN: unable to determine status"
exit 2

Sources

1. Android Security Bulletin—March 2026
2. NVD CVE-2026-0007
3. OSV entry for CVE-2026-0007
4. AOSP fix commit 8ec74c568b5881901cad0f1147fdc607702101e0
5. AOSP diff for the fix
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. OpenCVE record exposing CNA and CISA-ADP metadata