How to Fix CVE-2024-43093: Android Framework Privilege Escalation

What is CVE-2024-43093?

CVE-2024-43093 is a local elevation-of-privilege flaw in the Android framework, reported by Google and assigned CWE-176 (Improper Handling of Unicode Encoding). It carries a CVSS 3.1 base score of 7.3 (High), vector AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H.

The bug lives in shouldHideDocument() inside ExternalStorageProvider.java. That method is the gatekeeper that decides which file paths the Storage Access Framework should hide from an app. protected locations such as Android/data, Android/obb, and other sensitive directories on the shared volume. The filter normalises and compares the requested path string, but it handles unicode incorrectly. A path that contains specially crafted unicode characters normalises to a different value after the check than it did during the check, so a string that should have been hidden slips past the filter and resolves to a real, protected location.

The practical result: a malicious or compromised app already installed on the device can read or write directories that the storage sandbox is supposed to keep off-limits, gaining access to another app's private data. This is a privilege escalation, not remote code execution and not a denial of service, no remote network vector and no extra execution privileges are involved. The CVSS vector confirms it: attack vector is Local and user interaction is required, meaning the victim has to install and engage with the attacking app. Confidentiality, integrity, and availability impacts are all rated High because the bypass reaches another app's protected storage.

Am I affected?

Affected releases are Android 12, 12L, 13, 14, and 15. The fix is bundled in the 2025-03-01 Android security patch level. Check what your device runs:

• On the device: Settings > About phone > Android version. Expand it to see the Android security update date. If that date is earlier than March 1, 2025 (2025-03-01), the device is unpatched for this CVE.
• Over ADB: run adb shell getprop ro.build.version.security_patch and compare the returned date against 2025-03-01.
• Across a fleet (MDM): pull the reported security patch level from Intune, Android Enterprise, or your EMM and flag any device below 2025-03-01.

There is no log signature to look for: the flaw is exploited by a local app, not over the network, so version (patch level) is the only reliable indicator.

How to fix CVE-2024-43093

There is one real fix: get the device to the 2025-03-01 Android security patch level or later. The patch updates ExternalStorageProvider.java so the path filter normalises unicode correctly before it decides what to hide. The exact commit is referenced in the March 2025 Android Security Bulletin.

Pixel and consumer phones

1. Open Settings > System > System update (on some skins, Settings > Security > Security update).
2. Tap Check for update and install whatever is offered. Pixel devices received this fix in the March 2025 monthly update; other OEMs ship it on their own schedule, so keep checking until your security patch level reaches 2025-03-01 or newer.
3. Reboot when prompted, then re-open the same screen and confirm the Android security update date now reads March 1, 2025 or later.

Confirm the patch level over ADB

# Before and after the update, read the device security patch level.
# A patched device returns 2025-03-01 (or a later date).
adb shell getprop ro.build.version.security_patch

# Also confirm the Android release so you know which line you are on.
adb shell getprop ro.build.version.release

Managed fleets (Android Enterprise / MDM)

You cannot push an Android OS patch directly from an MDM, the OTA comes from the OEM. What the MDM gives you is enforcement and reporting:

• Report: export the security-patch-level field for every enrolled device and flag anything below 2025-03-01.
• Enforce: in Microsoft Intune, set a device compliance policy with a Minimum security patch level of 2025-03-01 and tie it to Conditional Access so non-compliant devices lose access to corporate apps until the user installs the OEM update. Android Enterprise and other EMMs expose the same minimum-patch-level control.
• Retire: devices past end-of-life that will never receive the March 2025 patch cannot be fixed. Block them and plan replacement.

# Intune: list enrolled Android devices and their reported security patch level
# so you can flag anything below 2025-03-01.
Connect-MgGraph -Scopes DeviceManagementManagedDevices.Read.All
Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'Android'" |
  Select-Object DeviceName, OSVersion, AndroidSecurityPatchLevel |
  Sort-Object AndroidSecurityPatchLevel

If you can't patch immediately

Google's bulletin lists no standalone workaround for this CVE. applying the security patch level is the remediation. Until the update lands, reduce exposure with the controls that actually fit a local-app attack:

• Install only trusted apps. Exploitation needs a malicious app on the device with user interaction. Keep Google Play Protect enabled, avoid sideloading APKs from unknown sources, and remove apps you do not recognise.
• Audit installed apps on high-value or BYOD devices, especially anything recently sideloaded or requesting broad storage access.
• Gate corporate access with a Conditional Access / compliance policy keyed to the minimum patch level so unpatched devices cannot reach sensitive data in the meantime.

Verify the fix landed

1. Re-read ro.build.version.security_patch (or the Settings > About screen) and confirm it reports 2025-03-01 or later.
2. In your MDM, confirm the device flips to compliant against the 2025-03-01 minimum-patch-level rule.
3. Re-run any mobile vulnerability scanner (for example Microsoft Defender for Endpoint mobile, or your MTD tool); it should no longer flag CVE-2024-43093 on the device.

Frequently asked questions

Which Android versions are affected by CVE-2024-43093?

Android 12, 12L, 13, 14, and 15. The fix ships in the 2025-03-01 (March 2025) Android security patch level. Check yours under Settings > About phone > Android version > Android security update.

How is CVE-2024-43093 exploited?

A local app uses crafted unicode characters in a file path to defeat the shouldHideDocument filter in ExternalStorageProvider, reaching protected directories such as Android/data and Android/obb. Exploitation requires the user to interact with the malicious app; no extra execution privileges are needed. CVSS is 7.3 (High).

How do I fix CVE-2024-43093 on my phone?

Install the update that brings your device to the 2025-03-01 or later Android security patch level via Settings > System > System update. Devices that no longer receive security updates cannot be patched and should be retired or restricted.

Is CVE-2024-43093 actively exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalog on 2024-11-07, and Google's bulletin flagged it as under limited, targeted exploitation. Treat patching as an emergency change.

References

• Official vendor advisory: https://android.googlesource.com/platform/frameworks/base/+/7f83c671626f9bf993581f4598c22482d87cba10
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-43093
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://source.android.com/security/bulletin/2025-03-01

This guide was assembled from the official vendor advisory, NVD record, and CISA KEV listing on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Why a storage filter bug becomes privilege escalation

On the surface, “a path filter let a file through” sounds minor. The reason this earns a 7.3 and a spot on CISA KEV is the security boundary it breaks. Android isolates each app's data so that one app cannot read another app's files. The Storage Access Framework, and ExternalStorageProvider behind it, is one of the components that enforces that boundary on the shared storage volume. shouldHideDocument() is the function that decides whether a given path should be invisible to the requesting app, directories like Android/data/<other.package> are supposed to be off-limits.

Unicode normalisation is the weak link. The same logical character can be expressed by more than one byte sequence (for example a precomposed character versus a base character plus a combining mark). If the filter compares the raw string but the file system resolves the normalised form: or vice versa, the string the filter inspects is not the string that ultimately gets opened. An attacker who knows the mismatch can encode a path so the filter sees something harmless and the resolver sees a protected directory. That is exactly the class of weakness CWE-176 describes, and it is why the fix is a normalisation correction rather than a permission change.

Because the gain is access to another app's private storage, a single malicious app can use this to harvest tokens, cached credentials, or personal data belonging to other apps on the device. without ever requesting a suspicious permission. That is the “local escalation of privilege” the description calls out, and the High confidentiality and integrity impacts in the CVSS vector reflect it.

How to prioritise this one

Two facts move this above an ordinary monthly patch. First, it is on the CISA KEV catalog (added 2024-11-07), and Google's own disclosure noted indications of limited, targeted exploitation at the time it was published. Second, it spans four major Android releases (12 through 15), so the affected population is enormous. The attack is local and needs user interaction, which is why the score is 7.3 rather than higher, but on a fleet of phones that install apps from outside a curated store, that prerequisite is routinely met.

For an organisation, the cleanest control is policy-driven: set a minimum security patch level of 2025-03-01 in your MDM, wire it to Conditional Access, and let non-compliant devices fall out of access until users take the OEM update. For an individual, the action is simpler: check for a system update and confirm the security-patch date moves to March 2025 or later.

Related fixes

Other flaws in this area worth reviewing while you patch this one:

• How to Fix CVE-2024-4947: Security Vulnerability in Google Chrome
• How to Fix CVE-2024-29745: Information Disclosure in Google Android
• How to Fix CVE-2024-7965: Security Vulnerability in Google Chrome
• How to Fix CVE-2024-22004: Out-of-bounds Read in Nest Wifi Pro
• How to Fix CVE-2024-47039: Information Disclosure in Android