CVE-2024-29748

What are Android Pixel Devices?

Google Pixel phones run Android with Google's direct software maintenance, receiving monthly security updates from Google. Pixel devices include enterprise mobile device management (MDM) support, allowing IT administrators or device admin apps to remotely wipe or factory reset a device to protect corporate data if the device is lost, stolen, or compromised. This factory reset protection is a critical security feature for organizations managing fleets of devices containing sensitive data.

Overview

CVE-2024-29748 is a privilege escalation vulnerability in Android Pixel devices that allows an attacker to interrupt a factory reset that has been triggered by a device admin app or MDM solution. By preventing the factory reset from completing, an attacker who has physical access to a device — or who can install a malicious app — can preserve sensitive data that was intended to be wiped. Google confirmed "limited, targeted exploitation" at the time of disclosure, consistent with use by mobile forensics tools or law enforcement-adjacent technology vendors. The KEV addition on April 4, 2024 — the day before the CVE publication date — reflects the urgency of confirmed exploitation.

Affected Versions

Technical Details

CWE-755 (Improper Handling of Exceptional Conditions). The vulnerability lies in how the Pixel firmware handles error conditions or interruptions during the factory reset process initiated by a privileged device admin application. When a factory reset is triggered via the DevicePolicyManager API, the reset process can be interfered with through a carefully timed action (such as triggering a crash, rebooting the device in a specific state, or exploiting an error path) that causes the reset to abort before completing.

The result is that the device retains its data, user accounts, and applications — defeating the security guarantee that a remotely-triggered wipe actually removes sensitive information from the device. This is particularly exploitable in scenarios where: law enforcement or adversaries have physical access to a device that the owner is attempting to remotely wipe; or a malicious app installed on the device prevents factory resets initiated by corporate MDM to persist on the device after an attempted wipe.

CVE-2024-29748 is closely related to CVE-2024-29745, which leaks fastboot memory in a way that assists in bypassing Android's security model — the two vulnerabilities were used together in forensic exploitation chains targeting specific individuals.

Discovery

The "limited, targeted exploitation" designation indicates Google TAG or a security partner observed this being exploited against specific individuals. The vulnerability's nature — interrupting MDM-triggered factory resets — is consistent with commercial mobile forensics tools that have developed techniques to extract data from devices that an owner has attempted to remotely wipe. The same April 2024 bulletin addressed the companion CVE-2024-29745.

Exploitation Context

The ability to interrupt a factory reset is most valuable to: (1) law enforcement and intelligence agencies conducting device forensics, (2) adversaries with physical access to a target's device who want to prevent the owner from wiping it remotely, and (3) malicious apps installed by stalkerware or spyware operators that want to survive MDM wipe commands. The "limited, targeted exploitation" language explicitly rules out broad criminal campaigns and points to sophisticated, individualized targeting.

Remediation

1. Apply the April 2024 Pixel security update immediately — verify via Settings → Security → Security update.
2. Enable automatic system updates on all managed Pixel devices to minimize the window of vulnerability.
3. For organizations relying on MDM remote wipe as a data protection control: verify that wipes complete successfully after patching, and treat unpatched devices as unable to guarantee remote wipe effectiveness.
4. Consider physical security controls for devices containing highly sensitive data — remote wipe should be a secondary control, not the sole protection against device compromise.