CVE-2026-0032 · Android pKVM mem_protect.c out-of-bounds write privilege escalation

01 · The Real Story

This is a hidden stairwell inside the building, not an unlocked front door

CVE-2026-0032 is an out-of-bounds write in Android's arch/arm64/kvm/hyp/nvhe/mem_protect.c, tied to the pKVM memory-sharing path. Google describes it as a logic error that can lead to local elevation of privilege, and the March 2026 Android bulletin places it in Kernel components / pKVM with fixes shipping under the 2026-03-05 security patch level. In practice, that means affected exposure is not "all Android" in a useful operational sense; it is Android builds carrying the vulnerable pKVM kernel component and missing the March 5, 2026 patch level.

The vendor's HIGH 7.8 score is technically fair in a lab because memory corruption in kernel-adjacent code can end badly. In fleet reality, it overstates urgency: this is local, requires an existing foothold, and Google's own bulletin says the kernel-components section assumes System execution privileges needed. That is a major friction point for real attackers and a major downgrade factor for defenders scheduling patches across thousands of endpoints.

"Serious kernel bug, but it is a post-compromise Android privesc with narrow reach and no exploitation signal."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Get code running on the device first

An attacker needs a pre-existing local foothold such as a malicious app, a compromised privileged service, or another exploit chain that already lands code on-device. This CVE is not a remote entry point; it is a privilege-escalation stage used after initial access. Typical weaponization here is a malicious APK or a chained exploit dropper rather than a network exploit.

Conditions required:

Local code execution on the Android device
Affected Android build missing the 2026-03-05 patch level
Relevant pKVM code path present on the target

Where this breaks in practice:

No unauthenticated remote reachability
App vetting, Play Protect, MDM allow-listing, and user-install controls reduce the population that ever reaches this step
Enterprise blast radius is one device at a time unless chained with distribution malware

Detection/coverage: Traditional perimeter scanners will miss this entirely. Detection lives in mobile threat defense, EMM app inventory, Play Protect telemetry, and incident artifacts from the initial foothold.

STEP 02

Reach the vulnerable pKVM memory-sharing path

The patched commits show Google tightened validation around sharing memory outside valid RAM regions in mem_protect.c. An exploit would need to drive the affected KVM/pKVM path with crafted parameters so the bad logic writes outside intended bounds. The relevant code sits in the protected virtualization subsystem, not a broad internet-facing daemon.

Conditions required:

arm64 Android kernel with vulnerable mem_protect.c logic
Access to the code path that triggers pKVM memory-sharing operations
Build-specific exploit compatibility

Where this breaks in practice:

pKVM is a narrower subcomponent than generic Android userspace
Device/vendor differences matter
Some fleets will have no reachable trigger path from ordinary app context

Detection/coverage: Signature-based network detection is not applicable. Kernel telemetry is sparse; at best you may see crashes, SELinux denials, or anomalous virtualization-related instability.

STEP 03

Turn memory corruption into privilege escalation

If the out-of-bounds write is controlled reliably, the attacker pivots from a logic bug to corruption of page-state or protection bookkeeping and then to elevated execution. The impact can be root-equivalent control on the device, which is why the raw CVSS impact metrics are high. This is the point where the bug becomes strategically useful for bypassing app sandboxing and device policy.

Conditions required:

Reliable write primitive from the vulnerable path
Exploit adapted to target kernel build and mitigations
Successful bypass of normal exploit-hardening variability

Where this breaks in practice:

Exploit reliability is build-specific
Modern Android hardening and vendor kernel variance raise development cost
No public authoritative exploit in vendor references

Detection/coverage: Most enterprise teams will not get high-fidelity pre-exploit alerts here. Post-event signals are stronger: root detection, attestation drift, security-control tampering, or suspicious persistence.

STEP 04

Abuse root on the compromised handset

With elevated privileges, the attacker can tamper with local data, weaken controls, or stage persistence until reboot or patching intervenes. On managed fleets, the real risk is policy bypass, credential theft from the device context, and use of the handset as a trusted endpoint inside enterprise workflows.

Conditions required:

Successful local privilege escalation
Access to enterprise apps or device-resident secrets

Where this breaks in practice:

Blast radius is usually the single device
Verified Boot, attestation, and EMM compliance checks can catch or contain post-root abuse
This still depends on the attacker already owning the handset

Detection/coverage: Look for failed integrity attestation, MDM compliance drift, unauthorized admin changes, or indicators of rooting/persistence from mobile defense tooling.

03 · Compensating Control

Block sideloading — Reduce the chance attackers ever get the local foothold this CVE needs. Enforce this through EMM/MDM policy immediately where possible; for a MEDIUM verdict there is no mitigation SLA, so use it as a risk-reduction control while moving to the 365-day remediation window.

Enforce app allow-listing and Play Protect — This bug is most valuable when paired with a malicious app or another on-device foothold. Require Google Play Protect, restrict unknown sources, and tighten enterprise app distribution policy; again, there is no mitigation SLA for MEDIUM, but these controls should be kept in place continuously.

Prioritize March 2026 SPL inventory — Use EMM to identify devices with ro.build.version.security_patch earlier than 2026-03-05 and treat them as the candidate set. This is the fastest way to scope the fleet because network scanners cannot see this class of bug; remediate inside the 365-day window.

Monitor attestation and root signals — Because this ends in local privilege escalation, post-exploit signals matter more than pre-exploit signatures. Enable device integrity checks, root detection, and compliance actions in your mobile stack and maintain them until all affected devices are patched.

What doesn't work

A WAF, IDS, or perimeter IPS will not help because there is no network-reachable exploit surface here.
Password resets or MFA hardening do not address the kernel flaw itself; they only matter for the separate initial-access paths an attacker might use before exploiting this CVE.
Version-only kernel string checks can mislead because Android OEMs often backport fixes without obvious version bumps; prefer SPL plus vendor update status.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No current public exploitation evidence in the authoritative sources reviewed. Google's March 2026 bulletin explicitly calls out limited targeted exploitation for CVE-2026-21385, not for CVE-2026-0032, and CISA KEV does not list this CVE.
Proof-of-concept availability	No trusted vendor or upstream PoC is referenced in Google's advisory, NVD, or OSV. A third-party tutorial/exploit listing exists on `mobilehackerforhire.com`, but treat it as unverified research-grade material, not a signal of mature commodity exploitation.
EPSS	0.00004 (~0.004%) from prompt-supplied intel, which is effectively floor-level likelihood. FIRST defines EPSS as the probability of exploitation activity in the next 30 days; this score aligns with a niche, post-compromise mobile privesc rather than a mass-exploitation event.
KEV status	Not KEV-listed in the current CISA Known Exploited Vulnerabilities catalog. That matters because KEV is the strongest public amplifier for shortening timelines on otherwise-local bugs.
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 + no UI with high impact. The important operational caveat is Google's bulletin grouping under Kernel components, where the section notes System execution privileges needed—a meaningful real-world friction not obvious from the top-line 7.8.
Affected surface	This lands in Android pKVM / Protected Kernel-Based Virtual Machine code, specifically `arch/arm64/kvm/hyp/nvhe/mem_protect.c`. That is narrower than generic Android framework exposure and materially narrower than a browser, media, or network stack bug.
Fixed versions	Security patch level 2026-03-05 or later addresses the issue. OSV marks the ecosystem fix event as `2026-03-05`, and the Android bulletin maps the CVE to the March 5, 2026 patch level; OEMs may backport the fix without obvious kernel version-string changes.
Exposure / scanning	Not internet-scannable in any meaningful way. Shodan/Censys/GreyNoise-style exposure counting is the wrong lens because this is a local on-device kernel-component flaw; use EMM inventory and Android SPL state instead of perimeter scanning.
Disclosure and references	Disclosed 2026-03-02 by Android/Google. Public references include Android bug A-439996285, OSV record ASB-A-439996285, and two Android kernel commits by Sebastian Ene fixing memory-sharing validation.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (4.9/10)

Why this verdict

Major downgrade: requires local attacker position — AV:L means the attacker is already on the handset. For enterprise prioritization, that is a second-stage exploit, not a front-door compromise.
Further downgrade: bulletin context says System execution privileges needed — that implies a more privileged starting position than a commodity remote attacker normally has, which compounds the post-initial-access requirement.
Narrower exposure population — the vulnerable code sits in pKVM mem_protect.c under kernel components, not in the generic app, browser, or media path that touches every device and every user.
No threat telemetry amplifier — no KEV listing, no authoritative active-exploitation note, and a floor-level EPSS 0.00004 all argue against emergency treatment.
Impact is still real once chained — successful exploitation can hand over root-level control on a managed Android endpoint, so this is not backlog trash; it just does not deserve remote-RCE urgency.

Why not higher?

There is no unauthenticated remote path, no broad internet exposure, and no current authoritative signal of real-world exploitation. The chain starts after the attacker already has code on the device, and possibly after they already have a privileged local context, which sharply limits reachable population and urgency.

Why not lower?

This is still kernel-adjacent memory corruption with high theoretical impact if successfully weaponized. On enterprise-managed mobile fleets, a rooted handset can undermine compliance, local secrets, and trust in the endpoint, so it deserves scheduled remediation rather than dismissal.

06 · Verification

Crowdsourced verification payload.

Run this on an auditor workstation with adb installed and USB/network debugging access to the target Android device. Invoke it as ./check_cve_2026_0032.sh <device-serial> for example ./check_cve_2026_0032.sh emulator-5554; it does not require root, but it does require the device to authorize adb.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_0032.sh
# Fleet triage for CVE-2026-0032 using Android security patch level.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/tooling error

set -u

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

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

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

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

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

PATCH_LEVEL="$(getprop_safe ro.build.version.security_patch | head -n1 | xargs)"
ABI="$(getprop_safe ro.product.cpu.abi | head -n1 | xargs)"
MODEL="$(getprop_safe ro.product.model | head -n1 | xargs)"
BUILD_FINGERPRINT="$(getprop_safe ro.build.fingerprint | head -n1 | xargs)"

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

# Basic validation for YYYY-MM-DD
if ! [[ "$PATCH_LEVEL" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
  echo "UNKNOWN - unexpected patch level format: $PATCH_LEVEL"
  exit 2
fi

# Lexicographic comparison is safe for YYYY-MM-DD
if [[ "$PATCH_LEVEL" > "$TARGET_PATCH" || "$PATCH_LEVEL" == "$TARGET_PATCH" ]]; then
  echo "PATCHED - model=${MODEL:-unknown} abi=${ABI:-unknown} patch_level=$PATCH_LEVEL target=$TARGET_PATCH"
  exit 0
fi

# Below target SPL. CVE is in arm64 pKVM code; non-arm64 devices are less certain.
if [[ "$ABI" == arm64* ]]; then
  echo "VULNERABLE - model=${MODEL:-unknown} abi=${ABI:-unknown} patch_level=$PATCH_LEVEL target=$TARGET_PATCH fingerprint=${BUILD_FINGERPRINT:-unknown}"
  exit 1
fi

echo "UNKNOWN - patch level is below $TARGET_PATCH but ABI is ${ABI:-unknown}; manual vendor confirmation recommended"
exit 2