In oobconfig

CVE-2026-0118 is a logic error in oobconfig on Google Pixel devices that can bypass carrier restrictions. Google and OSV tie the fix to the March 2026 Pixel patch train, with the vulnerable window effectively being Pixel-family builds before security patch level 2026-03-05; Android’s broader March 2026 bulletin also references the issue, but the Pixel bulletin is the cleaner scoping signal for defenders.

The vendor's HIGH/8.4 baseline makes sense inside Android's own rating model, which explicitly scores impact assuming platform mitigations are absent or bypassed. In real enterprise operations, though, this is a *local*, post-delivery issue on a *device-specific* component with no evidence of mass exploitation, no public exploit chain, and a constrained business impact centered on carrier-policy bypass rather than broad tenant compromise or server-side takeover.

Why this verdict

• Down from 8.4 because it is AV:L: an attacker must already have code execution on the device, which is post-initial-access and a major real-world severity suppressor.
• Down again because the exposed population is narrow: this is tied to Pixel oobconfig, not a generic enterprise server, browser, or email gateway surface spread across your whole estate.
• Down again because the blast radius is usually one handset: bypassing carrier restrictions matters, but it is not the same operationally as remote code execution on a management plane or identity system.
• No upgrade pressure from threat intel: no KEV listing, no active exploitation evidence, and no public PoC located from accessible primary sources.
• Vendor score overstates enterprise urgency because Android's own severity guidance explicitly assumes mitigations are absent or bypassed; fleet defenders should not treat that as identical to real-world exploit prevalence.

Why not higher?

This is not remotely reachable, not wormable, and not sitting on a shared enterprise control plane. The first prerequisite alone — local code execution on the target handset — sharply limits both attacker population and fleet-wide urgency, and there is no current exploitation evidence to offset that friction.

Why not lower?

It still removes a protection mechanism with no privileges and no user interaction once local code is in place. On a managed mobile fleet, unprivileged app-level abuse against unpatched Pixels is credible enough that this should not be waved off as pure backlog noise.

1. Scope vulnerable Pixels — Use MDM/EMM inventory to identify Google Pixel devices with security patch levels earlier than 2026-03-05. For a MEDIUM verdict there is no mitigation SLA, but scoping should happen early so you can place the affected subset into the remediation queue within the 365-day window.
2. Restrict sideloading — Enforce Play-only installs, unknown-sources restrictions, and app allowlisting on corporate Android devices. This directly attacks the biggest prerequisite — local unprivileged code execution — and is the best compensating control while remediation is scheduled; for MEDIUM, there is no mitigation SLA, so apply as standard hardening rather than emergency change.
3. Enforce Play Protect and MTD — Keep Google Play Protect enabled and ensure any mobile threat defense agent remains healthy on managed Pixels. These controls won't fix the logic bug, but they reduce the probability that a malicious APK ever reaches the exploitation stage before the patch is deployed within the 365-day remediation window.
4. Prioritize carrier-sensitive populations — If you manage carrier-locked field devices, subsidized handsets, or regulated mobile populations where SIM/carrier policy matters, move those users to the front of the patch queue. Their business impact is higher even though the CVE remains only MEDIUM overall.

Run this on the target Android/Pixel device via adb shell sh /data/local/tmp/check-cve-2026-0118.sh after pushing it with adb push check-cve-2026-0118.sh /data/local/tmp/. It needs only standard shell access; root is not required. The script classifies Pixel devices with security patch levels earlier than 2026-03-05 as VULNERABLE, patch levels on or after that date as PATCHED, and non-Pixel/ambiguous cases as UNKNOWN.

#!/system/bin/sh
# check-cve-2026-0118.sh
# Purpose: Assess likely exposure to CVE-2026-0118 on Android/Pixel devices.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

PATCH_CUTOFF="2026-03-05"

getprop_safe() {
  /system/bin/getprop "$1" 2>/dev/null | tr -d '\r'
}

normalize_date() {
  # Convert YYYY-MM-DD to integer YYYYMMDD for comparison.
  echo "$1" | tr -d '-'
}

MANUFACTURER="$(getprop_safe ro.product.manufacturer)"
BRAND="$(getprop_safe ro.product.brand)"
MODEL="$(getprop_safe ro.product.model)"
DEVICE="$(getprop_safe ro.product.device)"
PATCH_LEVEL="$(getprop_safe ro.build.version.security_patch)"
FINGERPRINT="$(getprop_safe ro.build.fingerprint)"

IS_PIXEL=0
case "$(echo "$MANUFACTURER $BRAND $MODEL $DEVICE $FINGERPRINT" | tr '[:upper:]' '[:lower:]')" in
  *google*|*pixel*) IS_PIXEL=1 ;;
esac

if [ -z "$PATCH_LEVEL" ]; then
  echo "UNKNOWN: unable to read ro.build.version.security_patch"
  exit 2
fi

# Basic date format validation.
echo "$PATCH_LEVEL" | grep -Eq '^[0-9]{4}-[0-9]{2}-[0-9]{2}$'
if [ $? -ne 0 ]; then
  echo "UNKNOWN: patch level format not recognized: $PATCH_LEVEL"
  exit 2
fi

PATCH_INT="$(normalize_date "$PATCH_LEVEL")"
CUTOFF_INT="$(normalize_date "$PATCH_CUTOFF")"

if [ "$IS_PIXEL" -ne 1 ]; then
  echo "UNKNOWN: device does not clearly identify as Google Pixel"
  echo "manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL device=$DEVICE patch_level=$PATCH_LEVEL"
  exit 2
fi

if [ "$PATCH_INT" -lt "$CUTOFF_INT" ]; then
  echo "VULNERABLE: Google Pixel with security patch level $PATCH_LEVEL (< $PATCH_CUTOFF)"
  echo "manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL device=$DEVICE"
  exit 1
fi

if [ "$PATCH_INT" -ge "$CUTOFF_INT" ]; then
  echo "PATCHED: Google Pixel with security patch level $PATCH_LEVEL (>= $PATCH_CUTOFF)"
  echo "manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL device=$DEVICE"
  exit 0
fi

echo "UNKNOWN: unable to determine exposure"
exit 2

Sources

1. Android Security Bulletin — March 2026
2. Pixel Update Bulletin — March 2026
3. Android severity guidance
4. OSV record PUB-A-427469428 / CVE-2026-0118
5. OpenCVE record for CVE-2026-0118
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview