Is CVE-2024-29745 (Android Pixel Information Disclosure) being exploited in the wild?

Yes. CISA added CVE-2024-29745 to its Known Exploited Vulnerabilities catalogue on 4 April 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Android Pixel contains an information disclosure vulnerability in the fastboot firmware used to support unlocking, flashing, and locking affected devices.

What “exploited in the wild” means for this CVE

For a vulnerability question like this, the practical answer is about confirmation, not speculation. If CISA has placed a CVE in the Known Exploited Vulnerabilities catalog, that is the operational signal that defenders should treat it as actively exploited and prioritize response accordingly. For this case, the issue is tied to Android Pixel fastboot firmware and an information disclosure condition that can matter during device handling and recovery workflows.

That makes the first question for defenders very simple: can you identify affected Pixel devices, and do you know whether they are exposed to the vulnerable fastboot path? The most useful source of truth is still the vendor advisory plus the CISA Known Exploited Vulnerabilities Catalog, because those are the places where remediation status and authoritative guidance are maintained.

Why fastboot information disclosure matters operationally

Information disclosure in firmware is not just about curiosity or low-value leakage. On mobile devices, it can expose details that help an attacker understand the device state, unlock workflow, or follow-on attack surface, especially if the device is handled outside normal enterprise controls. On Android, Mobile Device Security Guide is a useful baseline for thinking about how device posture, enrolment, and administrative controls reduce the chance that a local weakness becomes an enterprise incident.

Fastboot is also a special case because it sits near provisioning, unlocking, flashing, and repair operations. Those are high-trust moments in the device lifecycle, so a flaw there can create disproportionate exposure compared with a normal app-level bug. If your fleet allows technicians, developers, or users to interact with bootloader functions, the vulnerability can matter even when the rest of the Android estate is well managed.

What to check before assuming you are safe

First confirm whether your environment includes the affected Pixel models and whether any of them have been through unlocking, flashing, repair, resale, or lab use. Those devices are usually the ones where fastboot exposure is most relevant. Then verify whether your mobile management process actually records bootloader state, device ownership, and exception handling, because a device can look compliant at the MDM layer while still carrying a firmware-level exposure.

Next, decide whether you need to treat this as a pure patching issue or as a broader compromise review. If any vulnerable device was used in a sensitive workflow, you should consider whether local access to the device could have revealed enough information to support later misuse. That is especially true where device credentials, pairing information, or administrative trust relationships may have been present on the handset.

Risk and Threat Considerations

Active exploitation changes the priority from routine patch management to exposure reduction and compromise review. The main risk is not just the disclosure itself, but the fact that disclosed device information can help an attacker target a trusted endpoint, refine an attack path, or support follow-on abuse of a device that was assumed to be protected.

Failure mechanism: A local or semi-local attacker abuses the fastboot firmware path to read information that should not be exposed, then uses that knowledge to improve device targeting, device tampering, or later-stage compromise.

Impact: Security teams may face device trust erosion, higher likelihood of successful follow-on attacks against a managed endpoint, and the need to review whether sensitive workflows on affected devices were exposed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Physical devices and systems are inventoried	Pixel exposure depends on knowing which devices are in scope.
	PR.DS-01 — Data-at-rest is protected	Information disclosure can expose device data or sensitive device state.
	RS.MA-01 — Incidents are managed	KEV-listed active exploitation warrants coordinated response and triage.
Recommendation — Inventory affected devices and flag any Pixel units exposed to fastboot use. Protect exposed device data and treat disclosed state as potentially sensitive. Escalate KEV-listed exploitation into your incident handling process.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	A KEV-listed CVE requires confirmation of exposure across the device fleet.
	IR-4 — Incident Handling	Active exploitation calls for containment, investigation, and response actions.
Recommendation — Scan for affected devices and verify whether the vulnerability is present. Treat confirmed exposure as an incident to contain and investigate.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited flaws should be prioritized for rapid remediation.
	CIS-17 — Incident Response Management	Wild exploitation requires coordinated handling and escalation.
Recommendation — Prioritize remediation of the KEV-listed flaw across exposed devices. Route confirmed exposure through incident response and escalation paths.

Practitioner Guidance

What to prioritise: Confirm exposure first, then patch or mitigate, then decide whether any device needs a compromise assessment. For a KEV-listed issue, “we have not seen abuse” is not a sufficient reason to delay action if vulnerable devices are still reachable or in circulation.

What to verify: Check fleet inventory for the affected Pixel devices, bootloader state, and any history of unlocking or flashing. If the device has been used for privileged administration, device testing, or sensitive enrolment, treat it as higher value for review.

Decision rule: If the device can reach the vulnerable fastboot path and cannot be updated immediately, isolate it from sensitive use, restrict physical access, and remove it from high-trust workflows until the fix or vendor mitigation is in place.

Practitioner takeaway: For KEV-listed mobile firmware issues, the important decision is whether the exposure is still reachable in your fleet, because active exploitation makes unknown inventory and delayed remediation the real risk multipliers.