Google Android Vulnerabilities Under Attack: March 2025

Google Warned of Two Android Vulnerabilities Under Targeted Attack

Google's March 2025 Android Security Bulletin warned that CVE-2024-43093 and CVE-2024-50302 may have been under limited, targeted exploitation. Both were rated High severity by Google.

That point needs to be clear from the start. The March bulletin also contained separate Critical vulnerabilities capable of remote code execution, but CVE-2024-43093 and CVE-2024-50302 were not those Critical RCE flaws.

The two exploited vulnerabilities also worked differently. CVE-2024-43093 affected the Android Framework and could lead to local privilege escalation. CVE-2024-50302 affected the Linux kernel's Human Interface Device, or HID, subsystem and could disclose kernel memory. Google's 2025-03-05 security patch level covered both issues in the March bulletin.

Google's original technical information is available in the March 2025 Android Security Bulletin.

For organizations, the incident is also a reminder that protecting phones requires more than checking installed apps. Patch management, device visibility, access policy and mobile security and threat defense address different parts of the problem.

Key Findings

• Google warned of indications that CVE-2024-43093 and CVE-2024-50302 were under limited, targeted exploitation.
• Both vulnerabilities were classified as High severity in Google's March bulletin.
• CVE-2024-43093 affected Android 12, 12L, 13, 14 and 15 and could lead to local privilege escalation. User interaction was required.
• CVE-2024-50302 was a Linux kernel HID information-disclosure issue capable of leaking uninitialized kernel memory.
• CVE-2024-43093 belonged to the 2025-03-01 patch level, while CVE-2024-50302 belonged to 2025-03-05. A 2025-03-05 or later patch level therefore covered both March issues.
• CISA lists both vulnerabilities in its Known Exploited Vulnerabilities catalog. CVE-2024-43093 was added on November 7, 2024, and CVE-2024-50302 on March 4, 2025.
• Amnesty International linked CVE-2024-50302 to a sophisticated physical-access USB exploit chain used against a Serbian student activist's Samsung Galaxy A32.
• The broader Cellebrite exploit chain also involved CVE-2024-53104 and CVE-2024-53197, with Android fixes arriving across February, March and April 2025.
• Amnesty said the underlying USB-driver exposure could potentially affect more than one billion Android devices. That was an estimate of potential exposure, not a count of compromised phones.

CVE-2024-43093 and CVE-2024-50302 at a Glance

Detail	CVE-2024-43093	CVE-2024-50302
Component	Android Framework	Linux kernel HID core
Google severity	High	High
Type	Elevation of privilege	Information disclosure
Core issue	Incorrect Unicode normalization can bypass a file-path filter	Uninitialized HID report buffer can expose kernel memory
Exploitation requirement	Local attack with user interaction required	Physical information disclosure through crafted HID interaction
Android versions explicitly listed	12, 12L, 13, 14, 15	Google does not provide the same AOSP-version list in the kernel table
March patch level	2025-03-01	2025-03-05
Exploitation evidence	Google warning and CISA KEV	Google warning, CISA KEV and Amnesty forensic investigation

 

Security teams should therefore avoid treating the two CVEs as interchangeable. A useful endpoint security strategy considers the vulnerable component, attack conditions, affected asset and evidence of exploitation before deciding remediation priority.

CVE-2024-43093: Android Framework Privilege Escalation

CVE-2024-43093 could bypass an Android file-path filter because of incorrect Unicode normalization, potentially allowing local privilege escalation.

The current CVE record places the vulnerability in shouldHideDocument within ExternalStorageProvider.java. This code helps prevent access to restricted storage locations.

The issue arose because a path could be represented in a way that was not normalized correctly before the security filter evaluated it. That could allow the intended path restriction to be bypassed.

Google's CVE record says exploitation can result in local escalation of privilege, with no additional execution privileges needed. It also explicitly says user interaction is required.

Google currently lists these affected Android versions:

1. Android 12
2. Android 12L
3. Android 13
4. Android 14
5. Android 15

The March bulletin placed CVE-2024-43093 in its 2025-03-01 security patch level. It was also included under the Documents UI component of Google Play system updates.

Why CVE-2024-43093 Deserved Priority

CISA added CVE-2024-43093 to its Known Exploited Vulnerabilities catalog on November 7, 2024.

That illustrates an important vulnerability-management lesson: severity and exploitation are separate signals.

A High-severity vulnerability that attackers are already exploiting may deserve faster remediation than a vulnerability with a higher theoretical score but no known exploitation.

Organizations can monitor the official CISA Known Exploited Vulnerabilities Catalog and combine that information with a broader cyber threat intelligence process.

CVE-2024-50302: Linux Kernel HID Memory Disclosure

CVE-2024-50302 could expose uninitialized Linux kernel memory through specially crafted HID reports.

HID means Human Interface Device. The subsystem supports devices such as keyboards, mice and touchpads.

The Android OSV record says the issue existed in hid_alloc_report_buf within hid-core.c. Memory used for the HID report buffer was not properly initialized before use. That could leak kernel memory to a USB HID device.

The remediation involved zero-initializing the relevant report buffer.

Google placed CVE-2024-50302 in the kernel section of the 2025-03-05 security patch level, classified it as Information Disclosure and rated it High severity.

CISA describes it as a use-of-uninitialized-resource vulnerability that allows kernel memory to be leaked using a specially crafted HID report. CISA added it to KEV on March 4, 2025. (cisa.gov)

This is exactly why a mature vulnerability management program should consider active exploitation and asset context rather than prioritizing solely by a headline or severity label.

Does CVE-2024-50302 Automatically Expose Passwords?

The available evidence does not establish that every successful exploitation automatically returns passwords, encryption keys or authentication tokens.

The verified impact is kernel-memory disclosure. The exact information present in leaked memory depends on the system state and the wider exploitation technique.

That distinction prevents a technically valid memory-disclosure vulnerability from being exaggerated into a capability that the evidence does not prove.

The Serbian Activist Case and Cellebrite USB Exploit Chain

Amnesty International Security Lab documented a sophisticated exploit chain used to unlock the Samsung Galaxy A32 of a student activist detained in Serbia.

The attack involved physical possession of the locked phone and a sequence of emulated USB devices. Amnesty found forensic evidence that Cellebrite's UFED technology successfully obtained privileged root access and unlocked the device.

The full investigation is available in Amnesty International Security Lab's Cellebrite zero-day exploit investigation.

This is important context because CVE-2024-50302 should not be described as a one-click Android lock-screen bypass.

It was part of a wider exploit chain.

Vulnerabilities Associated With the Chain

CVE-2024-53104

This Linux USB Video Class vulnerability involved an out-of-bounds write. Google included it in the February 2025 Android Security Bulletin and warned that it may have been under limited, targeted exploitation.

CVE-2024-50302

The HID memory-disclosure issue was included in the March 2025 Android bulletin. =

CVE-2024-53197

This USB vulnerability was later included in the April 2025 Android Security Bulletin. Google also warned of limited, targeted exploitation involving CVE-2024-53197.

Amnesty's forensic work found multiple emulated USB devices appearing during the exploitation flow, including video, audio, touchpad and HID devices. The final HID device was repeatedly connected shortly before signs of successful arbitrary code execution as root appeared.

Patch Timeline: The Wider Chain Was Fixed Across Three Months

Android bulletin	Patch level	Relevant vulnerability	Main component
February 2025	2025-02-05	CVE-2024-53104	Linux kernel UVC
March 2025	2025-03-01	CVE-2024-43093	Android Framework
March 2025	2025-03-05	CVE-2024-50302	Linux kernel HID
April 2025	2025-04-05	CVE-2024-53197	Linux kernel USB

 

This timeline fills an important gap in many early reports.

The 2025-03-05 patch level addressed both exploited vulnerabilities highlighted in Google's March bulletin. It did not represent the final Android patch for every vulnerability associated with the wider Cellebrite USB exploit chain.

CVE-2024-53197 reached Android's April 2025 bulletin.

Could More Than One Billion Android Devices Have Been Exposed?

Amnesty International wrote that because the exploit targeted core Linux kernel USB drivers, the underlying vulnerability exposure was not limited to one device or manufacturer and could impact more than one billion Android devices.

The wording matters.

This does not mean:

• One billion phones were compromised.
• One billion phones were confirmed vulnerable to the complete chain.
• CVE-2024-50302 alone affected exactly one billion phones.
• Every exposed Android phone could be unlocked using the same procedure.

The number describes the potential reach of vulnerable shared kernel code.

The broader security lesson is that a flaw in a low-level Linux component can cross device-manufacturer boundaries because many Android devices rely on common upstream kernel code.

Which Android Devices Were Affected?

For CVE-2024-43093, Google's current CVE record explicitly identifies Android 12, 12L, 13, 14 and 15 as affected.

CVE-2024-50302 is different.

Google lists it in the kernel HID section rather than providing the same Android-version table. Exposure therefore depends on the kernel and vendor software used by a particular device.

This means checking only the major Android version is not enough.

A phone running Android 14 could have a very different security posture from another Android 14 device if their security patch dates differ.

Why 2025-03-01 and 2025-03-05 Are Different

Google's March bulletin used two patch levels.

2025-03-01 covered the vulnerabilities assigned to the first part of the March bulletin, including CVE-2024-43093.

2025-03-05 covered the second patch group, including CVE-2024-50302, together with the earlier applicable fixes.

Google states that security patch levels of 2025-03-05 or later address all applicable issues listed in the March 2025 bulletin.

Therefore:

• A device showing 2025-03-01 could have the CVE-2024-43093 fix.
• A device needed 2025-03-05 or later to demonstrate that both March vulnerabilities were covered through that bulletin.

This is a more useful check than simply asking whether a phone "received the March update."

What Should Android Users Check in 2026?

March 2025 is now a historical security baseline.

As of September 10, 2026, Google's September 2026 Android Security Bulletin has already been published. Google says 2026-09-05 or later addresses all issues in that September bulletin.

That does not mean every Android phone worldwide will already have the same update. Release timing still depends on manufacturer, model, chipset and carrier support.

The practical rule is:

Use the newest security update currently supported and available for your device. Do not intentionally stop at the March 2025 patch simply because it fixes these two CVEs.

How to Check Your Android Security Patch Level

1. Open the Android Version Screen

On many Android devices:

Settings → About phone → Android version

Look for the Android security update or Android security patch level entry.

Menu wording can differ by manufacturer.

2. Check for a System Update

Usually:

Settings → System → Software updates

Install available security updates.

3. Check the Patch Date Again

After installation and any required restart, verify the displayed security patch date changed.

For the two vulnerabilities discussed in the March 2025 bulletin, 2025-03-05 or later was the relevant historical baseline.

For a supported phone in September 2026, the target should be the newest vendor-supported patch available rather than that old baseline.

4. Check Google Play System Updates

CVE-2024-43093 also appeared in the March bulletin's Documents UI Google Play system update section.

Android devices can receive both operating-system security updates and Google Play system updates, so users should keep both current when available.

5. Confirm the Phone Is Still Supported

A device can eventually stop receiving security updates.

When that happens, pressing "Check for updates" and seeing nothing new does not prove that the device has no known security exposure.

For people handling sensitive corporate, financial, administrative or personal data, prolonged loss of security-update support is a valid reason to evaluate replacing the device.

Google Play Protect Helps, but It Does Not Replace Patching

Google Play Protect monitors potentially harmful applications and is enabled by default on devices that use Google Mobile Services. Google specifically recommends keeping Android updated and notes that Play Protect provides another protective layer.

But Play Protect and an operating-system security patch solve different problems.

CVE-2024-50302 existed in Linux kernel code. App scanning does not rewrite vulnerable kernel code.

A secure Android setup therefore combines:

• Current security patches
• Google Play Protect
• Careful app installation
• Strong authentication
• Device encryption
• Appropriate USB and physical-access policies
• Enterprise monitoring where required

OEM Fragmentation Makes Patch Verification Harder

One of the original concerns around these vulnerabilities remains valid: Android security fixes do not reach every device at the same moment.

Android uses a broad ecosystem of:

• Google
• Device manufacturers
• Chipset vendors
• Mobile carriers
• Open-source Linux components

That structure gives Android manufacturers flexibility, but it also means patch delivery can differ across brands and models.

Google's own bulletin system acknowledges this by giving Android partners multiple patch levels so they can address groups of vulnerabilities more quickly.

For users, the important question is not simply:

"Did Google publish a patch?"

It is:

"Did the patch actually reach this device?"

For organizations with many phones, a security gap analysis can help identify unsupported devices, inconsistent patching and weaknesses in mobile-device policy rather than assuming every endpoint is equally protected.

What These Vulnerabilities Mean for Individual Users

For most ordinary users, the key defensive action is straightforward: keep the phone updated.

The Cellebrite case requires additional context. Amnesty's investigation describes a sophisticated attack that required physical access to a locked device and specialist forensic technology. It should not be presented as a common drive-by attack affecting every Android owner in the same way.

Risk can be higher for people likely to face targeted device seizure or forensic examination, including some:

• Journalists
• Activists
• Executives
• Government personnel
• Security professionals
• People working with sensitive investigations or confidential sources

For these users, physical custody of the device deserves more attention alongside normal patching.

What Enterprises Should Do

Organizations need a repeatable process rather than a one-time response to CVE-2024-43093 and CVE-2024-50302.

1. Build an Accurate Mobile Inventory

Record at least:

• Manufacturer
• Model
• Android version
• Security patch level
• Google Play system update status
• Device owner
• BYOD or corporate-owned status
• MDM or EMM enrollment
• Vendor support status
• Business systems accessible from the phone

Without an inventory, there is no reliable way to tell which devices need action.

A broader cyber resilience assessment can help organizations understand how mobile-device weaknesses relate to endpoint, identity, network and incident-response risks.

2. Prioritize Known Exploited Vulnerabilities

Do not base the remediation queue only on CVSS or vendor severity.

Consider:

• Confirmed exploitation
• Attack requirements
• Device exposure
• Business importance
• User privileges
• Sensitive data access
• Patch availability
• Vendor support status

CVE-2024-43093 and CVE-2024-50302 demonstrate why exploitation evidence matters. Both appear in CISA's KEV catalog. (cisa.gov)

3. Establish a Minimum Patch Policy

Where an organization's mobile-management platform supports it, define a minimum acceptable security patch level.

A device that falls too far behind can then be:

• Flagged
• Required to update
• Restricted from sensitive resources
• Investigated for deployment problems
• Replaced if support has ended

The acceptable baseline should move forward as new security updates become available.

4. Verify the Fix

Sending an update request is not the same as remediation.

After deployment, confirm which devices actually received the required patch.

Investigate devices that:

• Remain behind
• Failed installation
• Are offline
• Have insufficient storage
• Are unmanaged
• Are no longer supported

5. Monitor Manufacturer Advisories

AOSP publication does not guarantee that every vendor-specific build receives its update immediately.

Organizations with Samsung, Google Pixel and other Android brands in the same environment should track the relevant manufacturer advisories and observed device patch levels.

6. Include Physical Access in High-Risk Threat Models

The Serbian case shows why possession of a locked phone should not automatically be treated as protection against a sufficiently capable adversary.

For sensitive users, organizations should consider:

• Device custody procedures
• USB policies
• Secure replacement processes
• Incident escalation after unexplained loss or seizure
• Credential rotation after suspected compromise

7. Investigate Suspicious Devices Carefully

If a sensitive device has been seized, lost, accessed by an untrusted party or shows credible signs of compromise, simply installing the latest patch may not answer whether compromise already occurred.

Preserve useful evidence and follow the organization's containment and investigation process.

When specialist help is required, incident response and recovery services can support structured investigation, containment and remediation.

Mobile App Security is a Separate Layer

Updating Android fixes vulnerable platform components. It does not automatically correct security flaws inside an organization's own Android application.

An app can still contain:

• Broken authentication
• Insecure local storage
• Weak authorization
• Exposed APIs
• Hardcoded secrets
• Poor session management
• Unsafe network communication

Those problems require application-level review.

Mobile application security testing is therefore complementary to operating-system patching, not a replacement for it.

Common Misunderstandings

Were CVE-2024-43093 and CVE-2024-50302 Critical Vulnerabilities?

No.

Google rated both High severity.

The March bulletin separately contained Critical vulnerabilities, including System flaws capable of remote code execution.

Did Both Vulnerabilities Provide Remote Code Execution?

No.

Google classified CVE-2024-43093 as Elevation of Privilege and CVE-2024-50302 as Information Disclosure.

Did CVE-2024-50302 Alone Unlock an Android Phone?

The available evidence does not support that claim.

Amnesty documented a multi-stage USB exploit chain involving several vulnerabilities.

Were One Billion Android Phones Hacked?

No.

Amnesty described potential exposure across more than one billion Android devices because the vulnerabilities targeted widely used Linux kernel USB drivers. That is not a count of successful attacks.

Does 2025-03-05 Still Count as a Good Patch Level in September 2026?

It proves that a device had the fixes represented by the March 2025 bulletin, but it is now an old security level.

Google's September 2026 bulletin uses patch levels 2026-09-01 and 2026-09-05. Supported devices should remain as current as their manufacturer allows.

The Human Factor Still Matters

Software patches only help when they reach devices.

Users may postpone updates because they:

• Need the phone for work
• Lack storage
• Expect the update to take too long
• Fear battery or compatibility problems
• Do not understand the security impact
• Ignore repeated notifications

Organizations can make compliance easier by explaining:

1. Why an update is required
2. When it should be installed
3. How users verify the patch level
4. Where failed updates should be reported
5. What happens when a device reaches end of support

User education should support technical controls, not replace them.

Longer-Term Lessons for Android Security

Faster Coordination Across the Ecosystem

Google, OEMs, chipset vendors and carriers all play roles in Android patch delivery. Reducing the time between upstream fixes and deployment limits how long known weaknesses remain available to attackers.

Regular Security Audits

Organizations should routinely inspect patch compliance instead of waiting for a widely reported Android zero-day.

Continued Security Research

The Amnesty investigation demonstrates how forensic research can expose previously unknown attack techniques and help platform vendors identify vulnerabilities.

Research, responsible disclosure and patch development remain important parts of improving mobile security.

Better User Awareness

People should know how to check the security patch date instead of relying on the assumption that automatic updates always succeeded.

Centralized Enterprise Monitoring

Large environments benefit from MDM or EMM systems that can track operating-system versions, patch compliance and unsupported devices.

Risk-Based Remediation

Security teams should combine vulnerability intelligence with the importance of the affected device.

A phone used only for low-risk personal tasks does not necessarily carry the same business impact as an executive phone with privileged access to corporate systems.

Practical Android Security Checklist

For Individual Users

1. Check the Android security patch level.
2. Install the newest supported system update.
3. Check Google Play system updates.
4. Restart if required.
5. Confirm the patch date changed.
6. Keep Google Play Protect enabled.
7. Install apps from trusted sources.
8. Check whether the manufacturer still supports the device.
9. Protect physical possession of sensitive devices.
10. Replace unsupported phones when their risk becomes unacceptable.

For Organizations

1. Maintain an Android device inventory.
2. Record patch levels, not only Android versions.
3. Identify unsupported devices.
4. Monitor exploited vulnerabilities.
5. Prioritize according to real business exposure.
6. Enforce an appropriate patch baseline.
7. Use MDM or EMM where suitable.
8. Verify remediation after deployment.
9. Monitor OEM security advisories.
10. Restrict significantly outdated devices.
11. Train users to recognize failed or delayed updates.
12. Maintain an incident-response process for suspected compromise.

Final Takeaway

Google's March 2025 warning concerned two High-severity Android vulnerabilities associated with targeted exploitation.

CVE-2024-43093 affected the Android Framework and could allow local privilege escalation. CVE-2024-50302 affected the Linux kernel HID subsystem and could disclose kernel memory.

The 2025-03-05 patch level covered both issues in the March bulletin. (source.android.com)

The Cellebrite case adds important context. It involved physical access, multiple USB vulnerabilities and specialist forensic tooling rather than a simple single-CVE attack.

For individual users, keeping a supported Android phone updated remains the main practical defense.

For businesses, the job is larger: inventory devices, measure patch levels, identify unsupported phones, prioritize known exploited vulnerabilities, verify remediation and maintain an investigation process for suspicious devices.

That approach remains useful long after one Android security bulletin leaves the news cycle.

More at:

https://cybersecuritynews.com/google-warns-android-vulnerabilities/