In EfwApTransport::ProcessRxRing of efw_ap_transport

CVE-2026-0123 is a memory-corruption bug in EfwApTransport::ProcessRxRing (efw_ap_transport.cc) caused by a missing bounds check, allowing an out-of-bounds write. Google ties it to the Pixel bulletin under the AOC subcomponent, and Google's OSV record marks it as Pixel-family specific with the fix landing at Pixel security patch level 2026-03-05; practically, that means supported Pixel devices below 2026-03-05 are the exposed set, not the whole Android ecosystem.

In reality this lands below the scary-sounding memory-corruption headline. The attacker needs local code execution on the device first—typically a malicious app or a prior foothold—so this is post-initial-access privilege escalation, not an internet-reachable compromise path. Google itself labeled it *Moderate* in the Pixel bulletin, and that matches the real-world picture better than the later enrichment-style 8.4/High CVSS math: narrow device population, local-only reachability, no KEV listing, tiny EPSS, and no public exploit trail.

Why this verdict

• Start point: there is no vendor CVSS baseline to compare against, so this is a first-principles severity call rather than an upgrade or downgrade
• Primary friction — local attacker position: exploitation requires AV:L, which implies the attacker already has code execution on the device; that is post-initial-access, not initial compromise
• Reachable population is narrow: Google's own OSV data marks the issue as *Pixel-family specific*, so this is not a full Android-fleet problem
• Exposure is not internet-scale: no external service, no perimeter spray-and-pray path, and no Shodan/Censys-style surface means far lower mass-exploitation potential
• Exploit pressure is low: no KEV listing, no public exploitation evidence in reviewed sources, no public PoC found, and EPSS is effectively near-zero

Why not higher?

A higher bucket would require some combination of broad exposure, active exploitation, or a path that materially helps attackers get *onto* devices. This bug does none of that. It is dangerous only after a local foothold exists, and the affected population is narrowed further by the Pixel/AOC scope.

Why not lower?

It should not be pushed down to LOW because successful exploitation can still collapse an on-device privilege boundary with no extra privileges or user interaction once code is running locally. On managed mobile fleets, local EoP bugs still matter because they can convert a low-privilege malicious app into a more serious device compromise.

1. Query your MDM for Pixel patch laggards — Identify Google Pixel devices below security patch level 2026-03-05 and separate them from the broader Android population. There is no noisgate mitigation SLA for a MEDIUM here, so use this immediately for scoping and drive remediation inside the 365-day window rather than treating all Android devices as equally exposed.
2. Tighten app-install policy — This CVE needs local code execution first, so reducing untrusted app delivery is the best compensating control. Enforce managed Play, block sideloading where business permits, and require approved app catalogs on affected Pixel users; for this MEDIUM, that is risk reduction during the normal remediation cycle, not an emergency control.
3. Verify Play Protect and MTD coverage — Play Protect and mobile threat defense are the tools most likely to break the prerequisite malicious-app stage before this vulnerability matters. Confirm they are enabled and reporting on corporate Pixel devices while patch compliance works through the normal remediation window.
4. Prioritize high-risk user cohorts — If your fleet includes executives, admins, developers, journalists, or other higher-targeting-risk Pixel users, move those devices to the front of the patch queue first. Even for a MEDIUM, the most sensible sequencing is to patch the smallest number of highest-consequence devices earliest.

Run this on an auditor workstation with adb installed and USB debugging or enterprise ADB access to the target Pixel device. Invoke it as ./check_cve_2026_0123.sh <serial> or omit the serial if only one device is connected; no root is required, but you do need permission to use adb shell getprop on the device.

#!/usr/bin/env bash
# check_cve_2026_0123.sh
# Determine likely exposure to CVE-2026-0123 on an Android device via ADB.
# Logic:
#   - Vulnerability is Pixel-family specific per Google's OSV record.
#   - Fixed at Pixel security patch level 2026-03-05.
# Output:
#   VULNERABLE / PATCHED / UNKNOWN
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -euo pipefail

TARGET_SERIAL="${1:-}"
ADB=(adb)
if [[ -n "$TARGET_SERIAL" ]]; then
  ADB+=( -s "$TARGET_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 accessible adb device"
fi

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

MANUFACTURER="$(getprop_safe ro.product.manufacturer)"
BRAND="$(getprop_safe ro.product.brand)"
MODEL="$(getprop_safe ro.product.model)"
PATCH="$(getprop_safe ro.build.version.security_patch)"
ANDROID_VER="$(getprop_safe ro.build.version.release)"

if [[ -z "$PATCH" ]]; then
  fail_unknown "security patch level unavailable"
fi

# Normalize to lowercase for comparisons
MANUFACTURER_LC="$(printf '%s' "$MANUFACTURER" | tr '[:upper:]' '[:lower:]')"
BRAND_LC="$(printf '%s' "$BRAND" | tr '[:upper:]' '[:lower:]')"
MODEL_LC="$(printf '%s' "$MODEL" | tr '[:upper:]' '[:lower:]')"

# Heuristic: Pixel-family specific exposure. If it's clearly not Google/Pixel, mark UNKNOWN rather than PATCHED.
IS_PIXEL=0
if [[ "$MANUFACTURER_LC" == *google* ]] || [[ "$BRAND_LC" == *google* ]] || [[ "$MODEL_LC" == *pixel* ]]; then
  IS_PIXEL=1
fi

if [[ "$IS_PIXEL" -ne 1 ]]; then
  echo "UNKNOWN: device does not appear to be a Google Pixel family device | manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL android=$ANDROID_VER patch=$PATCH"
  exit 2
fi

FIXED_PATCH="2026-03-05"

# Lexicographic compare works for YYYY-MM-DD
if [[ "$PATCH" < "$FIXED_PATCH" ]]; then
  echo "VULNERABLE: Pixel-family device below fixed patch level | manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL android=$ANDROID_VER patch=$PATCH fixed=$FIXED_PATCH"
  exit 1
fi

if [[ "$PATCH" >= "$FIXED_PATCH" ]]; then
  echo "PATCHED: Pixel-family device at or above fixed patch level | manufacturer=$MANUFACTURER brand=$BRAND model=$MODEL android=$ANDROID_VER patch=$PATCH fixed=$FIXED_PATCH"
  exit 0
fi

fail_unknown "unexpected comparison state"

Sources

1. Google Pixel Update Bulletin — March 2026
2. Android Security Bulletin — March 2026
3. Google OSV entry PUB-A-430693465
4. Google Android OSV JSON for PUB-A-430693465
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS data and stats
7. OpenCVE mirror of CVE-2026-0123 with CISA ADP enrichment