In multiple locations

CVE-2026-0006 is a heap-based buffer overflow in Android's Media Codecs path, tied to the APV decoder (libopenapv) used by the Media Codecs Mainline component. Google lists it in the System section of the March 2026 Android bulletin and maps it to Android 16; the same bulletin also says it is included in Google Play system updates under Media Codecs. The AOSP fix for bug 423894847 upgrades external/libopenapv to v0.2.0.0, so the practical affected range is Android 16 devices before the 2026-03-01 security patch level / pre-fix Media Codecs module, with upstream libopenapv builds before that upgrade considered suspect.

The vendor's 9.8/CRITICAL score is technically understandable because the bug is modeled as unauthenticated, no-click, network-deliverable RCE. In the field, though, this is not an internet-facing server bug and not a whole-fleet Android bug: it needs the right Android generation, the APV-capable codec path, and a delivery channel that causes preview or indexing of a crafted media file. That keeps it serious for mobile fleets, but it does not deserve the same operational urgency as a broadly exposed edge appliance or mass-scannable server RCE.

Why this verdict

• Start at 9.8 because the vendor model is the worst-case one: unauthenticated, no-click, remote-triggered code execution with high impact.
• Narrowed population: -1.0 because Google maps this to Android 16 and the Media Codecs/APV path. That is a much smaller exposed population than the CVSS label implies in a vacuum.
• Delivery and trigger friction: -0.5 because the attacker still has to land a crafted media file into a preview/indexing workflow that actually invokes the vulnerable decoder; secure mail/chat controls and the rarity of APV media cut reachable victims.
• Public PoC prevents a deeper downgrade: -0.2 only because exploitation is not purely theoretical anymore. Once a target is confirmed vulnerable, attacker development cost is materially lower.

Why not higher?

I am not calling this CRITICAL operationally because there is no authoritative active-exploitation signal in the sources reviewed, no KEV listing, and no evidence of broad internet-scale reach. This is a dangerous endpoint bug, but the exposed population is too narrow to justify the same bucket as a wormable edge device RCE.

Why not lower?

I am not dropping it to MEDIUM because the core path is still no-auth, no-click RCE on a managed endpoint class, and public reproduction exists. If your mobile fleet includes exposed Android 16 devices, a single malicious file can become a device-compromise event without the user doing anything obviously wrong.

1. Inventory Android 16 exposure — Use MDM to identify all devices on Android 16 and collect both the Android security patch level and Google Play system update state. Do this first and complete it within 30 days so you can separate truly exposed devices from the rest of the mobile fleet.
2. Block risky media delivery paths — Temporarily block or quarantine uncommon video/container formats and externally sourced media attachments in email, chat, and managed content channels where business impact is acceptable. For a HIGH verdict, put this control in place within 30 days on the cohorts you cannot patch immediately.
3. Restrict unmanaged file handling — Use MDM/app protection policy to limit open-in flows, sideloaded apps, and unmanaged download paths that feed media into local preview/indexing. This reduces the odds that a crafted file ever reaches the vulnerable decoder and should be enforced within 30 days for exposed device groups.
4. Hunt media-service crashes — Collect crash telemetry from mobile threat defense, EMM, or support tooling and alert on repeated mediaswcodec / libcodec2_soft_apvdec / libopenapv failures after receiving media. Stand this up within 30 days as a compensating detection while the fleet is being remediated.

Run this on an auditor workstation with adb installed and USB/Wi-Fi debugging authorized to the Android device. Invoke it as ./check-cve-2026-0006.sh <device-serial> or just ./check-cve-2026-0006.sh for the only attached device; no root is required, but you do need permission to query device properties over adb.

#!/usr/bin/env bash
# check-cve-2026-0006.sh
# Verifies likely exposure to CVE-2026-0006 on an Android device over adb.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

set -euo pipefail

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

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

if ! command -v adb >/dev/null 2>&1; then
  fail_unknown "adb not found in PATH"
fi

STATE="$(${ADB[@]} get-state 2>/dev/null || true)"
if [[ "$STATE" != "device" ]]; then
  fail_unknown "no authorized adb device available"
fi

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

PATCH_LEVEL="$(getprop_safe ro.build.version.security_patch)"
RELEASE="$(getprop_safe ro.build.version.release)"
SDK="$(getprop_safe ro.build.version.sdk)"
PLAY_PATCH="$(getprop_safe ro.build.version.security_patch)"

if [[ -z "$PATCH_LEVEL" ]]; then
  fail_unknown "could not read security patch level"
fi

# Check whether the APV decoder appears present in the Media Codecs APEX.
HAS_APV_DECODER="no"
if ${ADB[@]} shell 'test -f /apex/com.android.media.swcodec/lib64/libcodec2_soft_apvdec.so || test -f /apex/com.android.media.swcodec/lib/libcodec2_soft_apvdec.so' >/dev/null 2>&1; then
  HAS_APV_DECODER="yes"
fi

# Basic date comparison works because patch levels are YYYY-MM-DD.
# Android bulletin says 2026-03-01 or later addresses this bulletin set.
THRESHOLD="2026-03-01"

# Heuristic rules:
# 1) If APV decoder is absent, device is likely not exposed to this specific codec path.
# 2) If patch level >= 2026-03-01, report PATCHED.
# 3) If APV decoder is present and patch level < 2026-03-01, report VULNERABLE.
# 4) Otherwise UNKNOWN.

echo "Device release: ${RELEASE:-unknown}"
echo "Device SDK: ${SDK:-unknown}"
echo "Security patch level: $PATCH_LEVEL"
echo "APV decoder present: $HAS_APV_DECODER"

if [[ "$HAS_APV_DECODER" == "no" ]]; then
  echo "PATCHED: APV decoder not present; this device does not appear to expose the vulnerable codec path"
  exit 0
fi

if [[ "$PATCH_LEVEL" > "$THRESHOLD" || "$PATCH_LEVEL" == "$THRESHOLD" ]]; then
  echo "PATCHED: security patch level is $PATCH_LEVEL (>= $THRESHOLD)"
  exit 0
fi

if [[ "$PATCH_LEVEL" < "$THRESHOLD" ]]; then
  echo "VULNERABLE: APV decoder present and security patch level $PATCH_LEVEL is older than $THRESHOLD"
  exit 1
fi

fail_unknown "unable to classify device"

Sources

1. Android Security Bulletin—March 2026
2. NVD entry for CVE-2026-0006
3. AOSP fix commit upgrading libopenapv to v0.2.0.0
4. OpenAPV upstream repository
5. Public patch analysis / reproduction repo
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview