In multiple places

CVE-2026-0122 is an out-of-bounds write in Google Android memory-handling code that can end in code execution. Public detail is thin: NVD describes it generically, while Google's March 2026 Pixel bulletin places it in the *Baseband* bucket and says devices at security patch level 2026-03-05 or later contain the fix. That means the realistic affected population is not "everything with Android," but the subset of managed Android/Pixel devices that had not yet taken the March 2026 update.

The vendor-style base score of 8.4 captures worst-case impact on a single device, but it overstates enterprise patch urgency. The biggest real-world friction is attacker position: the published CVSS vector is AV:L, which means this is not a broad internet-reachable server bug. Add *no KEV listing*, *very low EPSS*, no public exploit chain, and a narrow mobile-device blast radius, and this belongs in a normal mobile remediation lane rather than the top of a 10,000-host emergency queue.

Why this verdict

• Start at 8.4, then cut for attacker position: AV:L is the biggest reality check. Requiring local reach or equivalent specialized access means this is already *post-initial-access* or niche radio targeting, not opportunistic internet exploitation.
• Cut again for exposed population: this is a mobile-device issue, not a server or edge-control-plane issue. In a 10,000-host estate, only the managed Android/Pixel subset is even in scope.
• Cut again for threat evidence: no KEV, EPSS 0.00035, and no public PoC means there is little sign that the broader attacker ecosystem is spending calories here right now.
• Do not cut to LOW: if exploited successfully, memory corruption in a handset/baseband context can still produce full compromise of a business device and the identity/data tied to it.

Why not higher?

A higher bucket would require either broad reachability, strong active-exploitation evidence, or both. This case has neither: the published vector is local, the advisory detail is sparse, there is no KEV listing, and no public exploit chain is driving emergency pressure.

Why not lower?

This is still an out-of-bounds write with potential code execution, not a cosmetic bug. Even a narrow handset exploit can be high-impact for executives, admins, and anyone using the device for MFA, mail, chat, or conditional-access-backed enterprise apps.

1. Enforce minimum Android patch level — Use UEM/MDM compliance policy to require Android security patch level 2026-03-05 or later on managed devices. Because this is a MEDIUM verdict there is no mitigation SLA; use the control as routine fleet hygiene while you complete remediation inside the 365-day window.
2. Restrict high-risk mobile app sources — Reduce the chance of the AV:L prerequisite by tightening sideloading, unknown-source installs, and developer-mode exceptions on corporate devices. This directly attacks the most important friction point: getting code onto the phone in the first place.
3. Prioritize high-value users first — Move executives, admins, and frequent travelers to the front of the mobile patch queue because a single handset compromise carries outsized identity and data value. There is no formal mitigation SLA for MEDIUM, but these users deserve an accelerated internal target.
4. Require conditional access on mobile — If a handset is compromised, conditional access, device compliance, and app-level protections can reduce how useful that compromise becomes. Keep this in place continuously; it lowers business impact even when it cannot stop the vulnerability itself.

Run this on the target Android device through adb shell or your mobile management remote shell. Example: adb push check_cve_2026_0122.sh /data/local/tmp/ && adb shell sh /data/local/tmp/check_cve_2026_0122.sh; no root is required, but the device must allow shell access.

#!/system/bin/sh
# check_cve_2026_0122.sh
# Purpose: Approximate exposure to CVE-2026-0122 by checking Android security patch level.
# Logic: Google's March 2026 bulletins state that 2026-03-05 or later addresses the relevant fixes.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

REQ_PATCH="2026-03-05"
PATCH_LEVEL="$(getprop ro.build.version.security_patch 2>/dev/null)"
MANUFACTURER="$(getprop ro.product.manufacturer 2>/dev/null)"
MODEL="$(getprop ro.product.model 2>/dev/null)"
ANDROID_VER="$(getprop ro.build.version.release 2>/dev/null)"

if [ -z "$PATCH_LEVEL" ]; then
  echo "UNKNOWN - security patch level not available via ro.build.version.security_patch"
  exit 2
fi

# Basic sanity check for YYYY-MM-DD
case "$PATCH_LEVEL" in
  ????-??-??) ;;
  *)
    echo "UNKNOWN - unexpected patch level format: $PATCH_LEVEL"
    exit 2
    ;;
esac

# Lexical compare works for YYYY-MM-DD strings
if [ "$PATCH_LEVEL" \< "$REQ_PATCH" ]; then
  echo "VULNERABLE - patch level $PATCH_LEVEL is older than required $REQ_PATCH (manufacturer='$MANUFACTURER' model='$MODEL' android='$ANDROID_VER')"
  exit 1
fi

if [ "$PATCH_LEVEL" \>= "$REQ_PATCH" ] 2>/dev/null; then
  :
fi

echo "PATCHED - patch level $PATCH_LEVEL meets or exceeds $REQ_PATCH (manufacturer='$MANUFACTURER' model='$MODEL' android='$ANDROID_VER')"
exit 0

Sources

1. NVD CVE-2026-0122
2. Android Security Bulletin—March 2026
3. Pixel Update Bulletin—March 2026
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS documentation
6. FIRST EPSS data documentation
7. OpenCVE record for CVE-2026-0122