01 · The Real Story
This is a trapdoor inside the phone, not a hole in the perimeter
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.
"Serious on a compromised Pixel, but not a fleet-wide fire unless the attacker already has code running on-device."
02 · The Attack Path
3 steps from start to impact.
STEP 01
Land low-privilege code execution on the device
The attacker first needs a running context on the target Pixel, typically a malicious app or an already-compromised app process. No public exploit chain is published for this CVE, so the practical weapon here is a custom LPE chain rather than an off-the-shelf kit.
Conditions required:
- Target is a supported Google Pixel device
- Attacker already has local code execution or equivalent low-privileged execution on the device
- Device is not yet at security patch level 2026-03-05 or later
Where this breaks in practice:
- This is not unauthenticated remote reachability
- Modern enterprise mobile fleets often restrict sideloading and unknown app sources
- Play Protect and MDM app allow-listing reduce how often attackers reach this step
Detection/coverage: Standard network scanners will miss this entirely. Detection is mostly indirect: mobile threat defense, EDR-for-mobile, app reputation controls, and inventorying Android security patch levels.
STEP 02
Trigger the bootloader memory corruption
A local payload exercises the private vulnerable bootloader-facing path and hits the missing bounds check, producing an out-of-bounds write. Because Google has not published root-cause code or a PoC, defenders should assume private exploit development is required.
Conditions required:
- Attacker can reach the affected bootloader code path from a low-privileged context
- Build contains the vulnerable bootloader component
Where this breaks in practice:
- Bootloader bugs are often device/build-specific and brittle across models
- Private bug details mean opportunistic commodity abuse is less likely
- Exploit reliability may vary across firmware revisions
Detection/coverage: Very limited signature coverage. You are more likely to detect the precursor malware/app than the corruption event itself unless the device crashes or mobile telemetry captures abnormal privilege transitions.
STEP 03
Escalate to elevated privileges on that device
Successful exploitation gives the attacker a stronger execution context on the same handset, materially improving their ability to tamper with data, disable protections, or pivot into credential theft. The blast radius is usually one device at a time, not the whole tenant.
Conditions required:
- Exploit succeeds reliably on the target build
- Post-exploitation payload is present
Where this breaks in practice:
- Per-device exploitation does not scale like a remote service bug
- Fleet impact depends on how many already-compromised devices you have, not how many devices exist
- Some enterprise containers and server-side conditional access still limit follow-on access even after local elevation
Detection/coverage: Look for downstream indicators: security tool disablement, suspicious adb state changes, credential replay from mobile users, unusual app installs, or anomalous MDM posture drift.
03 · Compensating Control
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.
What doesn't work
- Perimeter scanning doesn't help; there is no internet-facing service to find or block.
- WAF/NGFW controls are irrelevant because exploitation is local on the device, not over HTTP or a routable enterprise port.
- Version-only server vulnerability scanners usually miss this unless they ingest mobile device patch posture from MDM/EMM data.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the sources reviewed. CISA ADP enrichment marks exploitation as none, and the CVE is not in KEV. |
|---|---|
| PoC availability | No public PoC located. Google marks the Android bug reference with *, meaning the issue is not publicly available and the fix is in binary drivers/firmware rather than an openly reviewable patch. |
| EPSS | 0.00024 per user-supplied intel; that is extremely low and consistent with a niche, post-compromise mobile LPE rather than a mass-exploited edge bug. |
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities catalog as of this assessment. |
| CVSS vector reality check | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H says local + low privileges required. That is the key friction: the attacker must already have code running on the phone. |
| Affected versions | Google's Pixel bulletin ties exposure to supported Pixel devices before security patch level 2026-03-05. OSV expresses this as Pixel-family specific affected until fixed at 2026-03-05. |
| Fixed version | Android/Pixel security patch level 2026-03-05 or later. Treat this as the operative fixed version for enterprise inventory and compliance checks. |
| Scanning/exposure data | No meaningful Shodan/Censys/GreyNoise angle. This is a *local bootloader EoP*, so there is no direct internet-facing scan surface; exposure is determined by device patch level and attacker presence on-device, not open ports. |
| Disclosure timeline | Disclosed 2026-03-10 in NVD/CVE records; Pixel bulletin published 2026-03-03, updated 2026-03-09, and states the fix is in patch level 2026-03-05 or later. |
| Reporter / source | Public aggregator views of the CVE record attribute reporting credit to Christopher Wade; CNA/source is Google Devices. |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to MEDIUM (5.3/10)
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.
06 · Verification
Crowdsourced verification payload.
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