In multiple functions

CVE-2026-0075 is a flaw in Android's ContactsProvider2.java component across Android 14, 15, 16, and 16-qpr2. A local application without the READ_CONTACTS permission can craft malformed SQL queries against the ContactsProvider content provider. When these queries trigger SQLite exceptions, the error messages leak database structure and content — a classic error-based SQL injection side channel. The AOSP patch (commit bb9f36b3) sanitizes these error strings for callers lacking READ_CONTACTS, eliminating the information disclosure vector.

Google's Android Security Bulletin rates this High (and some NVD sources cite CVSS 7.8), while the provided CVSS vector scores only 5.9. Both overstate the real-world risk for enterprise fleet managers. The attack is local only — a malicious app must already be installed on the target device. The blast radius is a single device's contact database, not credentials, tokens, or enterprise secrets. In a managed-device fleet with MDM app-allow-listing, the prerequisite of getting a rogue app onto the device is the hardest part of the chain, and the payoff is minimal compared to what social-engineering a READ_CONTACTS permission grant would yield.

Why this verdict

• Local-only attack vector with app-install prerequisite: The attacker must first get a malicious app onto a managed device — the hardest step in the chain for enterprise-managed Android fleets with MDM app-allow-listing and Play Protect enabled. This alone compresses the reachable population to near-zero in well-managed environments.
• Minimal data payoff: The side channel yields fragments of the contacts database. In enterprise context, contacts are low-sensitivity data compared to auth tokens, managed app data, or MDM configuration. The risk-to-effort ratio is extremely poor for an attacker.
• No privilege escalation beyond data leak: Despite Google labeling this EoP, the actual impact is information disclosure of contacts. There is no path to SYSTEM, no kernel compromise, no lateral movement to other devices or enterprise infrastructure.
• Role multiplier: Android devices occupy only endpoint roles (workstations equivalent). There is no high-value-role scenario (no DC, no hypervisor, no CI/CD, no PKI) where this vulnerability's blast radius could scale. The floor does not apply — contacts on a phone do not enable domain takeover, fleet compromise, or supply-chain pivot.
• Bottom-tier EPSS (0.00094): Statistical exploitation probability is negligible, consistent with the friction analysis.

Why not higher?

Upgrading to MEDIUM or above would require either a realistic path to fleet-scale compromise, exposure of high-value data (credentials, tokens), or evidence of active exploitation. None of these conditions exist. The local prerequisite with MDM friction and the contacts-only payoff make even MEDIUM an overstatement for enterprise environments.

Why not lower?

Dropping to IGNORE would be inappropriate because a working PoC does exist, the vulnerability affects a broad Android version range (14-16), and organizations with BYOD policies or weak MDM enforcement could see contact data leakage at scale across unmanaged personal devices. The flaw is real and exploitable — it is just low-impact.

1. Enforce MDM app-allow-listing on all managed Android devices — Block sideloading and restrict app installation to approved sources. This eliminates the prerequisite of getting a malicious app onto the device. No specific mitigation SLA applies at LOW severity — treat as backlog hygiene.
2. Verify Google Play Protect is enabled fleet-wide via MDM policy — Play Protect provides runtime scanning that can detect malicious apps attempting known exploitation patterns. Confirm enrollment via MDM compliance reporting.
3. Roll out June 2026 security patch level via MDM OTA policy — The definitive fix is security patch level 2026-06-01 or later. At LOW severity, this falls into backlog hygiene with no hard SLA deadline, but it should ship with your next routine Android patch cycle.
4. Audit BYOD contact-sharing policies — If your org syncs corporate directory contacts to personal devices, evaluate whether this side channel could leak the corporate directory on unmanaged BYOD devices. Consider restricting contact sync to managed devices only.

Run this on a workstation with adb connected to the target Android device. Requires USB debugging enabled or ADB over network. Usage: bash check_cve_2026_0075.sh — no root required on the device.

#!/usr/bin/env bash
# check_cve_2026_0075.sh
# Checks if an ADB-connected Android device is patched for CVE-2026-0075
# Requires: adb in PATH, device connected and authorized
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

PATCH_DATE="2026-06-01"

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

DEVICE_COUNT=$(adb devices | grep -c 'device$' || true)
if [ "$DEVICE_COUNT" -eq 0 ]; then
  echo "UNKNOWN — no ADB device connected"
  exit 2
fi

SPL=$(adb shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')

if [ -z "$SPL" ]; then
  echo "UNKNOWN — could not read security patch level"
  exit 2
fi

echo "Device security patch level: $SPL"
echo "Required patch level:        $PATCH_DATE"

if [[ "$SPL" > "$PATCH_DATE" ]] || [[ "$SPL" == "$PATCH_DATE" ]]; then
  echo "PATCHED — device is at or above $PATCH_DATE"
  exit 0
else
  echo "VULNERABLE — device patch level $SPL is below $PATCH_DATE"
  exit 1
fi

Sources

1. Android Security Bulletin — June 2026
2. AOSP Patch Commit (ContactsProvider2.java)
3. CVE-2026-0075 — THREATINT
4. KSEC Exploit Feed — SQL Injection in Google Android
5. CISA Known Exploited Vulnerabilities Catalog
6. NVD CVE Detail Database