In Modem

CVE-2026-0114 is a Pixel modem out-of-bounds write that Google classifies as RCE. The vendor description says exploitation needs no privileges and no user interaction, but the affected population is supported Google Pixel devices that had security patch level earlier than 2026-03-05; this is not a general Android server-side bug and the fix ships in Pixel's March 2026 security update.

The vendor's 9.8/CRITICAL score reflects the technical impact if the modem path is reached, not the real enterprise exposure. In practice this sits behind a cellular/baseband attack surface, often requiring a stronger attacker position, specialized telecom exploitation capability, or rogue network conditions rather than ordinary internet reachability. That makes the raw CVSS too hot for patch-priority decisions, even though the underlying bug class is serious.

Why this verdict

• Downgrade for attacker position: vendor CVSS treats this like broad network reachability, but the real path is cellular/baseband access, which sharply narrows who can hit it and how.
• Downgrade for exposure population: this is supported Pixel only and fixed by 2026-03-05 SPL; it is not a generic Android or enterprise server issue.
• Downgrade for threat evidence: no KEV, no public exploitation evidence, no public PoC, and a very low EPSS (0.00238) all argue against emergency-at-scale behavior.
• Keep it high, not medium: if an actor can reach the bug, it is a no-user-interaction RCE in a handset component that can carry MFA, corp email, VPN certs, and executive comms.

Why not higher?

There is no public sign of broad exploitation, no public exploit chain, and no evidence this is being mass-scanned or weaponized by commodity operators. The attack surface is also not directly internet-addressable in the way a pre-auth VPN, firewall, or web console bug would be.

Why not lower?

This is still remote, no-click memory corruption with RCE potential on a managed endpoint class that matters for executives, admins, and travel staff. If your fleet includes Pixels, the consequence of a capable attacker landing this is real enough that it should not be relegated to pure backlog hygiene.

1. Force Pixel patch compliance — Use Android Enterprise / MDM to identify all managed Pixel devices and require security patch level 2026-03-05 or later. For a HIGH verdict, deploy this control within 30 days if you cannot immediately confirm full patch coverage.
2. Disable 2G where the business can tolerate it — Google explicitly documents that 2G downgrade paths enable false-base-station risk; disabling 2G removes one common lower-trust cellular path. Apply this to managed Pixels, especially high-risk users, within 30 days where roaming and coverage requirements allow.
3. Enable mobile network security features — On Android 16-capable devices, turn on the Mobile network security notifications so users and admins get visibility into unencrypted network use and frequent identifier disclosure. This is an exposure-reduction and detection aid to deploy within 30 days.
4. Quarantine unsupported legacy Pixels from sensitive access — Older devices outside Google's security-support window should not hold high-value corporate identities if you cannot bring them to a fixed build. Move them out of privileged app access and certificate-backed auth flows within 30 days.

Run this on an auditor workstation with adb installed and a managed Pixel connected over USB debugging or approved ADB transport. Invoke it as ./check-cve-2026-0114.sh <device-serial>; no root is required, but you do need ADB access to query device properties.

#!/usr/bin/env bash
# check-cve-2026-0114.sh
# Determine whether a connected Google Pixel is vulnerable to CVE-2026-0114
# based on manufacturer/model and Android security patch level.
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / ERROR

set -euo pipefail

REQUIRED_SPL="2026-03-05"
SERIAL="${1:-}"

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

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

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

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

MANUFACTURER="$(getprop ro.product.manufacturer | xargs)"
BRAND="$(getprop ro.product.brand | xargs)"
MODEL="$(getprop ro.product.model | xargs)"
DEVICE="$(getprop ro.product.device | xargs)"
SPL="$(getprop ro.build.version.security_patch | xargs)"

if [[ -z "$MODEL" || -z "$SPL" ]]; then
  echo "UNKNOWN: could not read required properties"
  exit 2
fi

# Best-effort Pixel identification
IS_GOOGLE=0
if [[ "$MANUFACTURER" =~ [Gg]oogle ]] || [[ "$BRAND" =~ [Gg]oogle ]] || [[ "$MODEL" =~ Pixel ]] || [[ "$DEVICE" =~ ^(oriole|raven|bluejay|panther|cheetah|felix|lynx|husky|shiba|akita|comet|tokay|caiman|komodo) ]]; then
  IS_GOOGLE=1
fi

if [[ "$IS_GOOGLE" -ne 1 ]]; then
  echo "UNKNOWN: device does not appear to be a supported Google Pixel"
  echo "MODEL=$MODEL MANUFACTURER=$MANUFACTURER BRAND=$BRAND DEVICE=$DEVICE SPL=$SPL"
  exit 2
fi

# Basic date validation
if [[ ! "$SPL" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
  echo "UNKNOWN: unexpected security patch level format: $SPL"
  exit 2
fi

# Lexicographic compare works for YYYY-MM-DD
if [[ "$SPL" < "$REQUIRED_SPL" ]]; then
  echo "VULNERABLE: $MODEL SPL=$SPL is earlier than required $REQUIRED_SPL"
  exit 1
else
  echo "PATCHED: $MODEL SPL=$SPL meets or exceeds $REQUIRED_SPL"
  exit 0
fi

Sources

1. NVD CVE-2026-0114
2. Google Pixel Update Bulletin — March 2026
3. Android Security Bulletin — March 2026
4. Android cellular security: Disable 2G
5. Android cellular security: Mobile network security
6. Google Pixel update support schedule
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API documentation