CVE-2024-29745

What it actually does

CVE-2024-29745 is a local information disclosure vulnerability in Google Android caused by uninitialized data being exposed to a lower-privileged local caller. An attacker who already has the ability to run code locally, such as through a malicious app, compromised app context, physical/debug access, or another post-compromise foothold, can trigger the vulnerable code path and receive memory or data that should have been cleared before being returned. The issue does not require user interaction and does not grant code execution by itself, but it can expose sensitive data and may support follow-on exploitation such as credential theft, privacy compromise, or bypassing memory-protection assumptions.

Why it matters to the business

The main operational risk is unauthorized exposure of sensitive data from Android devices, including data that may belong to users, apps, or system components. Because this issue is listed in CISA KEV and has active in-the-wild exploitation, organizations should treat it as an urgent mobile endpoint risk even though the CVSS score is moderate. The CISA remediation deadline was 2024-04-25, so any unmanaged or unpatched Android fleet still exposed is materially overdue. Exploitation is especially concerning for executives, administrators, developers, field staff, and other users whose devices may store business communications, authentication material, customer data, or regulated information.

How an attack unfolds

An attacker first obtains local execution on an affected Android device, commonly by convincing a user to install a malicious app, abusing an already-compromised app, using physical/debug access, or chaining this flaw after another vulnerability. The attacker then invokes the vulnerable Android component or interface that returns uninitialized data. Because the data buffer is not properly initialized before being exposed, the attacker can read residual information that should not be accessible to the calling context. The disclosed information may be used directly for espionage or financial objectives, or as supporting material for a broader exploit chain, for example by exposing sensitive app data, device state, memory contents, identifiers, or values that make a second vulnerability easier to exploit. Public reporting and KEV status indicate this class of issue has been used in 2024 zero-day exploitation campaigns by espionage and financially motivated actors targeting Android/Pixel devices.

How to fix it

Apply the relevant Google Android/Pixel security update that contains the fix for CVE-2024-29745. Where exact package-level fixed versions are not available, use the Android Security Bulletin and Pixel Update Bulletin guidance and update devices to the April 2024 security patch level or later, or to a vendor build that explicitly includes this CVE fix. Prioritize Pixel and Android devices used by high-risk users and devices that permit sideloading, have developer options enabled, are rooted, are unmanaged, or are outside normal MDM enforcement. If immediate patching is not possible, reduce exposure by disabling app sideloading, enforcing Play Protect or equivalent mobile threat defense controls, blocking unknown-source installs, restricting USB debugging and ADB access, removing untrusted apps, and isolating or retiring devices that cannot receive security updates.

How to confirm the fix worked

Confirm that affected devices report an Android security patch level and vendor/Pixel build date that includes the April 2024 or later fix for this vulnerability. Validate through MDM/UEM inventory, Android Enterprise device compliance data, vendor build fingerprints, and direct device checks in Settings > Security & privacy > System & updates, or equivalent OEM menus. Security teams should also confirm that devices are still receiving vendor security updates and are not on end-of-support builds. For unmanaged devices, require attestation or enrollment before allowing access to business services. Exposure remains if devices are Android-based, affected by the bulletin, and running a patch level prior to the vendor fix.

Typical attack path

1. Gain local execution on an affected Android device through a malicious app, physical/debug access, or a separate compromise path.
2. Run code with low local privileges; no additional privileges or user interaction are required for the vulnerable operation itself.
3. Call the vulnerable Android interface or code path that exposes uninitialized data.
4. Collect the returned data and extract sensitive values, identifiers, memory residue, or app/system information.
5. Use the disclosed information for data theft, surveillance, credential/session targeting, or to improve reliability of a larger exploit chain.
6. Cover tracks by removing the malicious app, clearing temporary files, or relying on normal mobile telemetry gaps to avoid detection.

How to detect it

There is no single reliable network IOC for this vulnerability because exploitation is local to the Android device and may only appear as normal-looking calls to vulnerable system components. Detection should focus on evidence that an attacker had local code execution during the exposure window: suspicious sideloaded apps, recently installed APKs from unknown sources, use of USB debugging or ADB, rooting indicators, unexpected accessibility/admin privileges, mobile threat defense alerts, unusual app crashes, SELinux denials, and abnormal access by low-privileged apps to system services. Review MDM/UEM logs for devices below the fixed patch level, app inventory changes, developer-option enablement, unknown-source install events, Play Protect findings, and compliance state changes. If available, collect Android bugreports/logcat, package install history, app signing details, and EDR/MTD telemetry. For suspected targeted exploitation, correlate device exposure with known 2024 zero-day exploitation activity, suspicious physical access, spearphishing or malicious-app delivery, and any subsequent account access from the device. Because disclosed data may include credentials or session material, also review identity logs for anomalous sign-ins or session reuse after the suspected exploitation period.

What your security team should do

• Treat this as a high-priority mobile endpoint remediation item because it is in CISA KEV, has active in-the-wild exploitation, and the KEV due date has passed.
• Use MDM/UEM to identify all Android devices below the April 2024 security patch level or vendor build containing the fix, and block or quarantine noncompliant devices from sensitive business access.
• Prioritize patching or replacement for Pixel devices, high-risk users, privileged users, and devices that allow sideloading or USB debugging.
• Disable or tightly control unknown-source app installation, ADB, developer options, and rooted/jailbroken device access to enterprise resources.
• Review mobile threat defense alerts, app inventory, and device telemetry for suspicious sideloaded apps or local post-compromise activity around the time devices were exposed.
• If compromise is suspected, rotate credentials and tokens used from the affected device, revoke mobile sessions, and consider device wipe/rebuild rather than relying only on app removal.
• Track Google Android and OEM bulletins for downstream device-specific fixed builds, since Android patch availability can vary by manufacturer and carrier.