In dumpBitmapsProto of ActivityManagerService

CVE-2026-0047 is a missing permission check in dumpBitmapsProto inside Android's ActivityManagerService. In plain English: a locally running app may be able to ask the framework for bitmap-related data it should not get, leading to access to private information without prompting the user. Public records reviewed tie the affected population to Android 16-qpr2, with NVD enrichment specifically listing qpr2_beta_1 through qpr2_beta_3 CPEs and CVE.org listing the affected version as 16-qpr2.

Google's bulletin labels the issue Critical in the Framework section, and the CVSS vector in NVD/CISA-ADP is 8.4 / High, but both overstate enterprise urgency for most fleets. This is local-only, requires the attacker to already land a malicious app on the handset, appears limited to a narrow Android branch, has no KEV listing, and carries a near-floor EPSS. For a 10,000-device program, that is a containment problem on a subset of endpoints, not a fleet-wide emergency.

Why this verdict

• Down from vendor baseline: local-only means post-delivery. AV:L with PR:N still requires attacker code running on the handset, which in enterprise reality means you already lost app-control on that endpoint.
• Down again: affected population looks narrow. CVE.org says 16-qpr2, and NVD enrichment points specifically to qpr2_beta_1/2/3, which is a much smaller slice than 'Android' writ large.
• Down again: blast radius is one device at a time. There is no network reachability, no wormability, and no obvious tenant- or fleet-wide pivot from the flaw alone.
• Down again: threat telemetry is cold. No KEV, no public exploitation evidence, and an EPSS near zero all argue against emergency handling.
• Still not LOW: the bypass is real and permissionless once the app is present. An unprivileged app should not be able to reach private framework dump output, and no user click is needed after installation.

Why not higher?

This does not give unauthenticated remote access, and it does not help an attacker get onto the phone in the first place. The need for a malicious app plus the likely narrow 16-qpr2 exposure slice compounds the friction enough that an enterprise should not treat this like a critical patch-now event.

Why not lower?

I am not putting this in LOW because the vulnerable boundary is a framework permission check, and exploitation from an installed app appears to require no extra privileges and no user interaction. If you do have affected devices and looser app-governance, the bug can still expose sensitive on-device data in a way defenders should not ignore.

1. Enforce app allowlisting — Require managed Google Play or equivalent allowlisting so unknown APKs cannot land on affected devices. This directly cuts off the exploit's biggest prerequisite; for a MEDIUM verdict there is no noisgate mitigation SLA, so use this as an operational hardening step while you work the normal remediation window.
2. Block sideloading on managed devices — Disable or tightly restrict user sideloading, ADB installs, and externally hosted private APK distribution where business-possible. That shrinks the realistic exploit population because the bug is only reachable after app placement; again, no noisgate mitigation SLA applies for MEDIUM.
3. Hunt for Android 16-qpr2 devices — Query UEM/MDM inventory for build fingerprints, OS release, and security patch level to identify whether you even own the affected branch. This is the fastest way to turn a noisy Android CVE into a scoped device list instead of a fleet-wide scramble.
4. Turn on mobile threat telemetry — Use Play Protect, MTD, and UEM app-install telemetry to flag unapproved apps and suspicious outbound behavior from newly installed packages. These controls do not fix the bug, but they materially raise friction for the malicious-app prerequisite during the 365-day remediation window.

Run this on an auditor workstation with adb installed and USB/network debugging access to the target Android device. Invoke it as ./check-cve-2026-0047.sh <device-serial> or without an argument if only one device is attached; it needs no root, only normal adb shell getprop access.

#!/usr/bin/env bash
# check-cve-2026-0047.sh
# Purpose: Heuristically assess exposure to CVE-2026-0047 on an Android device via adb.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE/ADB ERROR

set -euo pipefail

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

need_cmd() {
  command -v "$1" >/dev/null 2>&1 || {
    echo "UNKNOWN - required command '$1' not found"
    exit 3
  }
}

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

need_cmd adb

if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN - adb device not reachable"
  exit 3
fi

release="$(getprop_safe ro.build.version.release)"
security_patch="$(getprop_safe ro.build.version.security_patch)"
fingerprint="$(getprop_safe ro.build.fingerprint)"
incremental="$(getprop_safe ro.build.version.incremental)"
product="$(getprop_safe ro.product.device)"
model="$(getprop_safe ro.product.model)"

# Normalize a little
release_lc="$(printf '%s' "$release" | tr '[:upper:]' '[:lower:]')"
fingerprint_lc="$(printf '%s' "$fingerprint" | tr '[:upper:]' '[:lower:]')"
incremental_lc="$(printf '%s' "$incremental" | tr '[:upper:]' '[:lower:]')"

# Helper: compare ISO dates lexicographically (works for YYYY-MM-DD)
is_ge_date() {
  local a="$1"
  local b="$2"
  [[ "$a" > "$b" || "$a" == "$b" ]]
}

# Determine whether device appears to be on the affected Android 16-qpr2 branch.
is_android16=0
if [[ "$release_lc" == "16" || "$release_lc" == "android 16" ]]; then
  is_android16=1
fi

is_qpr2_hint=0
if [[ "$fingerprint_lc" == *"qpr2"* || "$incremental_lc" == *"qpr2"* || "$fingerprint_lc" == *"beta"* ]]; then
  is_qpr2_hint=1
fi

# Decision logic:
# - If SPL is 2026-03-01 or later, Android bulletin says framework issues are addressed.
# - Pixel bulletin says 2026-03-05 or later covers all March 2026 Android bulletin issues on Google devices.
# - Because public metadata narrows exposure to Android 16-qpr2, anything outside that branch is UNKNOWN/PATCHED depending on confidence.

if [[ -z "$security_patch" ]]; then
  echo "UNKNOWN - could not read security patch level (device: $model / $product)"
  exit 2
fi

if is_ge_date "$security_patch" "2026-03-05"; then
  echo "PATCHED - security patch level $security_patch is at or above 2026-03-05 (device: $model / $product)"
  exit 0
fi

if [[ $is_android16 -eq 1 && $is_qpr2_hint -eq 1 ]]; then
  if is_ge_date "$security_patch" "2026-03-01"; then
    echo "PATCHED - Android 16 qpr2-like build with security patch $security_patch, which is at or above 2026-03-01"
    exit 0
  else
    echo "VULNERABLE - Android 16 qpr2-like build with security patch $security_patch below 2026-03-01"
    exit 1
  fi
fi

if [[ $is_android16 -eq 1 && $is_qpr2_hint -eq 0 ]]; then
  echo "UNKNOWN - Android 16 detected but qpr2 branch not confirmed; fingerprint='$fingerprint' patch='$security_patch'"
  exit 2
fi

echo "UNKNOWN - device does not clearly match public affected-version data (release='$release', patch='$security_patch', fingerprint='$fingerprint')"
exit 2

Sources

1. Android Security Bulletin — March 2026
2. NVD CVE-2026-0047
3. CVE.org record for CVE-2026-0047
4. Pixel Update Bulletin — March 2026
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS Data and Statistics
7. Android Application Sandbox
8. Access to Managed Google Play