There is a possible out of bounds write due to a missing bounds check

CVE-2026-0124 is an out-of-bounds write in the Pixel bootloader path that can yield local elevation of privilege on supported Google Pixel devices. The public record is thin because the bug reference is private, but the March 2026 Pixel bulletin places it in the Bootloader subcomponent and states devices at security patch level 2026-03-05 or later contain the fix; OSV tracks the affected range as Pixel-family specific:0 through fixed Pixel-family specific:2026-03-05.

The raw impact is ugly, but the vendor/NVD-style severity overstates enterprise urgency because the attacker must already be on the device with local low privileges. That means this is usually a second-stage post-compromise primitive for a malicious app, sideloaded payload, physical/ADB foothold, or another exploit chain—not an initial access bug you can hit across 10,000 hosts from the internet.

Why this verdict

• Downward pressure: AV:L + PR:L means the attacker already has a foothold on the phone. That implies prior compromise, malicious app execution, or physical/ADB access before this CVE matters.
• Downward pressure: affected population is narrower than generic Android. The vendor bulletin places it in the Pixel bulletin, Bootloader subcomponent, with a Pixel-specific patch level fix.
• Downward pressure: no KEV, no public exploitation, no public PoC. This does not look like a commodity spray-and-pray issue today.
• Upward pressure: successful LPE on mobile is strategically useful. Once an attacker is on the handset, elevating privileges can improve persistence, data access, and defense evasion on a high-value identity device.

Why not higher?

It is not higher because the chain starts after the attacker already executes code locally on the device. For enterprise prioritization, post-compromise local privilege escalations do not outrank remotely exploitable edge or server bugs unless there is clear active exploitation or a widely weaponized chain.

Why not lower?

It is not lower because mobile LPEs still matter on identity-bearing devices that hold tokens, MFA prompts, mail, and corporate data. A bootloader-side memory corruption bug can materially worsen the outcome of an existing mobile compromise, so this should not be dismissed as mere hygiene.

1. Block untrusted app paths — Enforce Play-only installs, disable sideloading where your MDM supports it, and tighten app allow-listing on managed Pixels. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but these controls cut off the most likely prerequisite: attacker code already running on-device.
2. Harden developer access — Disable or tightly control USB debugging, adb authorization, OEM unlock, and noncompliant developer settings on enterprise devices. Apply this during normal posture-hardening cycles; it reduces practical reach to bootloader-adjacent paths even though it is not a guaranteed fix.
3. Prioritize mobile threat telemetry — If you run MTD/EDR-for-mobile, alert on sideloaded apps, app reputation failures, suspicious accessibility abuse, and devices drifting below required patch posture. For MEDIUM, fold this into standard control maintenance ahead of the vendor patch deployment rather than treating it as emergency mitigation.
4. Constrain token value — Use conditional access, device compliance checks, short-lived tokens, and phishing-resistant MFA so a single compromised handset has less downstream blast radius. This is especially valuable because LPEs amplify whatever foothold the attacker already has.

Run this on an auditor workstation with adb installed and a single managed Pixel connected and authorized over USB or enterprise device bridge. Invoke it as ./check_cve_2026_0124.sh or SERIAL=<device-serial> ./check_cve_2026_0124.sh; no root is required, but the device must authorize adb shell access.

#!/usr/bin/env bash
# check_cve_2026_0124.sh
# Determine likely exposure to CVE-2026-0124 on a connected Android/Pixel device
# Logic: Pixel devices with security patch level earlier than 2026-03-05 are treated as VULNERABLE.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_PATCH="2026-03-05"
SERIAL_ARG="${SERIAL:-}"
ADB_BIN="${ADB_BIN:-adb}"

adb_cmd() {
  if [ -n "$SERIAL_ARG" ]; then
    "$ADB_BIN" -s "$SERIAL_ARG" "$@"
  else
    "$ADB_BIN" "$@"
  fi
}

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

command -v "$ADB_BIN" >/dev/null 2>&1 || fail_unknown "adb not found in PATH"

STATE="$(adb_cmd get-state 2>/dev/null || true)"
[ "$STATE" = "device" ] || fail_unknown "no authorized device connected (state=$STATE)"

getprop_trim() {
  adb_cmd shell getprop "$1" 2>/dev/null | tr -d '\r' | tail -n 1
}

PATCH_LEVEL="$(getprop_trim ro.build.version.security_patch)"
BRAND="$(getprop_trim ro.product.brand)"
MANUFACTURER="$(getprop_trim ro.product.manufacturer)"
MODEL="$(getprop_trim ro.product.model)"
FINGERPRINT="$(getprop_trim ro.build.fingerprint)"
BUILD_ID="$(getprop_trim ro.build.id)"

[ -n "$PATCH_LEVEL" ] || fail_unknown "could not read ro.build.version.security_patch"

# Basic sanity check for YYYY-MM-DD
if ! printf '%s' "$PATCH_LEVEL" | grep -Eq '^[0-9]{4}-[0-9]{2}-[0-9]{2}$'; then
  fail_unknown "unexpected patch level format: $PATCH_LEVEL"
fi

# Heuristic vendor check; if this is clearly not Google/Pixel, we can't assert applicability.
PIXEL_HINT="no"
printf '%s %s %s' "$BRAND" "$MANUFACTURER" "$FINGERPRINT" | grep -Eiq 'google|pixel' && PIXEL_HINT="yes"

if [ "$PIXEL_HINT" != "yes" ]; then
  echo "UNKNOWN: non-Pixel or unconfirmed Google device"
  echo "model=$MODEL brand=$BRAND manufacturer=$MANUFACTURER build_id=$BUILD_ID patch_level=$PATCH_LEVEL"
  exit 2
fi

# Lexicographic comparison is safe for YYYY-MM-DD strings.
if [[ "$PATCH_LEVEL" < "$TARGET_PATCH" ]]; then
  echo "VULNERABLE: Pixel device patch level is earlier than $TARGET_PATCH"
  echo "model=$MODEL brand=$BRAND manufacturer=$MANUFACTURER build_id=$BUILD_ID patch_level=$PATCH_LEVEL"
  exit 1
else
  echo "PATCHED: Pixel device patch level is $PATCH_LEVEL (>= $TARGET_PATCH)"
  echo "model=$MODEL brand=$BRAND manufacturer=$MANUFACTURER build_id=$BUILD_ID patch_level=$PATCH_LEVEL"
  exit 0
fi

Sources

1. NVD CVE-2026-0124
2. Pixel Update Bulletin — March 2026
3. Android Security Bulletin — March 2026
4. OSV entry PUB-A-308585798
5. OpenCVE CVE-2026-0124
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. FIRST EPSS API documentation