Yes. CISA added CVE-2024-43093 to its Known Exploited Vulnerabilities catalogue on 7 November 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Android Framework contains an unspecified vulnerability that allows for privilege escalation. Any organisation running the affected product should treat remediation as urgent.
What “exploited in the wild” means for this CVE
For this question, the key point is not just that a vulnerability exists, but that it has crossed into active abuse. Once CISA places a CVE in the Known Exploited Vulnerabilities catalogue, organisations should treat it as a live exploitation issue, not a theoretical weakness. That status changes prioritisation: exposure, business criticality, and remediation speed matter more than waiting for a fuller postmortem.
For any team confirming exposure, the first check is whether the affected Android Framework version is present anywhere in the fleet, including devices that are unmanaged, personally owned for work, or long-lived endpoints that rarely re-enroll. CISA’s catalogue is the operational signal; the vendor advisory is the source for version-specific remediation details. See the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database for authoritative vulnerability records and references.
Why Android Framework privilege escalation is operationally serious
Privilege escalation on a mobile platform is serious because it can convert a normal app or local foothold into broader device control, weakening the boundary between user-space activity and higher-value data or management controls. On Android, that can matter for corporate email, managed profiles, authentication apps, device-bound secrets, and access to enterprise resources that assume the device remains trustworthy.
When exploitation is active, the practical concern is not only compromise of one phone, but the possibility that a foothold becomes persistent or repeatable across a fleet if devices remain unpatched. That is why mobile patch latency, device compliance drift, and delayed re-enrolment become security issues, not just operations issues.
For threat validation and attack-path thinking, this type of weakness fits the same exploitability pattern tracked in MITRE ATT&CK Enterprise Matrix: local privilege gain often changes what an attacker can access, what they can persist through, and how quickly they can move from a single device to higher-value credentials or sessions.
What to do first when patching or mitigation is delayed
Urgency should be driven by exposure, not by convenience. If you cannot patch immediately, reduce the device’s trust as fast as possible: tighten access to sensitive apps, isolate high-risk endpoints, and assume that any device confirmed vulnerable may need closer monitoring until remediated. Mobile controls are strongest when they are tied to inventory, compliance state, and enforcement, not just policy text.
Where work phones, BYOD devices, or corporate-owned personally enabled devices are in scope, the mobile control plane matters as much as the OS patch itself. A good reference point is the Mobile Device Security Guide, which covers device enrolment, mobile threat defense, work profiles, app management, and compliance controls that help contain exposed endpoints.
If privileged access or sensitive credentials are present on devices that may have been affected, review whether the device could have exposed high-value sessions or token-bearing apps. In that case, rotation or reauthentication may be needed alongside the device fix, especially where a compromised endpoint could have been used to reach administrative consoles or cloud services. For that kind of privilege containment, see the Privileged Access Management Guide.
Risk and Threat Considerations
Active exploitation of a mobile privilege-escalation flaw raises both exposure risk and attacker opportunity. A successful local exploit can turn a low-privilege starting point into device-level trust abuse, which is especially dangerous when the device already carries corporate mail, SSO sessions, or access to managed apps.
Failure mechanism: The attacker leverages the Android Framework weakness to increase privileges on the device, then uses that higher trust position to access data, sessions, or management functions that were not reachable from the original app context.
Impact: The result can include data exposure, session theft, persistent device compromise, and a much smaller barrier to further compromise of enterprise services tied to that endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation makes patch prioritization and exposure tracking central. |
| Recommendation — Prioritise and remediate exposed Android devices using vulnerability inventory and continuous scanning. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This CVE requires timely flaw remediation and tracking of affected endpoints. |
| CM-8 — System Component Inventory | Confirming exposure depends on accurate device inventory and ownership. | |
| Recommendation — Apply flaw-remediation workflows to identify, assess, and correct affected Android endpoints. Maintain authoritative device inventory so vulnerable Android assets can be found and prioritized. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | The issue is an actively exploited vulnerability requiring organized remediation handling. |
| Recommendation — Track and remediate exploited vulnerabilities through a formal technical vulnerability process. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | If a compromised device can reach sensitive sessions or admins, excessive privilege increases impact. |
| Recommendation — Reduce privileges on mobile-accessed service paths and remove unnecessary high-value access. | ||
Practitioner Guidance
What to prioritise: Start with internet-connected, high-risk, and high-trust Android devices, then move to devices that can reach email, collaboration, identity, or admin apps. If a device can authenticate to sensitive systems, it belongs at the front of the queue.
What to verify: Confirm which devices are actually present in inventory, whether they are receiving security updates on time, and whether any vulnerable device has access to privileged mobile workflows. A patch ticket is not enough if the device remains in a trusted state after remediation.
Decision rule: If you cannot patch promptly, treat the endpoint as potentially untrusted until you can revalidate it, then force reauthentication or session renewal where sensitive access may have been exposed.
Practitioner takeaway: CISA KEV listing means the question is no longer “is this exploitable”, but “which devices are still exposed, and what downstream access could a compromised device already have touched?”
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2024-43093 (Android Framework Privilege Escalation)?
- Is CVE-2024-32896 (Android Pixel Privilege Escalation) being exploited in the wild?
- Is CVE-2025-48572 (Android Framework Privilege Escalation) being exploited in the wild?
- CVE-2024-43093 (Android Framework Privilege Escalation)