Is CVE-2023-35674 (Android Framework Privilege Escalation) being exploited in the wild?

What the KEV listing tells you about active exploitation

The practical signal is not just that the CVE exists, but that CISA placed it in the Known Exploited Vulnerabilities Catalog. For defenders, that means exposure should be treated as an active exploitation problem, not a routine patch-cycle item. If you manage Android fleets, the first question is whether any enrolled devices are still running the affected framework build.

Use the vendor advisory and the KEV entry together to confirm scope, because the response urgency comes from exploitation status, while the exact remediation instructions come from the product guidance. That separation matters when you have mixed fleets, managed work profiles, or devices that are not directly under IT control.

Why Android framework privilege escalation is operationally serious

An Android Framework privilege-escalation flaw can move an attacker from a constrained foothold to broader device control, which changes the incident from a single-app problem to a device-trust problem. Once privilege increases, attackers may be able to access data, bypass local controls, or establish persistence on the endpoint.

For mobile environments, that can become an access-path issue as much as a device issue. A compromised phone often carries email, chat, SSO sessions, corporate apps, and sometimes cached secrets or tokens, so the blast radius can extend into enterprise accounts if the device is trusted by other services.

In practice, this is why mobile security programs need the same urgency for exploited platform flaws that they already apply to server-side KEV items. The relevant question is not whether the phone is “just a user device,” but whether it is a gateway to corporate identity, data, or application access.

What to do if patching has to wait

If you cannot remediate immediately, reduce exposure by isolating the affected devices from sensitive access paths, tightening mobile device policy, and looking for alternate control points that can reduce trust in the endpoint. The Mobile Device Security Guide is a useful reference when you need to align device controls, work profiles, and enrolment policy with a known-exploited mobile issue.

Prioritise devices that can reach sensitive email, VPN, admin portals, or internal apps. If a vulnerable device cannot be patched quickly, treat it as potentially untrusted until remediation is complete and validate whether compensating controls actually block the paths that matter.

For larger fleets, use a vulnerability-management process that can rank this as urgent, track exception expiry, and verify remediation rather than assuming the update happened. The Vulnerability Management Guide is relevant here because KEV-backed items need prioritisation, clear ownership, and closure evidence, not just ticket creation.

Risk and Threat Considerations

Exploited mobile platform flaws are attractive because they can convert ordinary device compromise into broader enterprise reach, especially when the handset is enrolled, trusted, or used for work access. The risk is amplified when the device holds active sessions, cached credentials, or access to approved enterprise apps.

Failure mechanism: A local Android framework weakness can be used to elevate privileges on the device, after which an attacker may access protected data, interfere with security controls, or use the device as a stronger pivot into enterprise services.

Impact: The likely consequence is broader compromise of mobile data and connected enterprise accounts, plus higher likelihood of persistence, lateral movement, or follow-on abuse if the device remains trusted after exploitation.

Practitioner Guidance

What to verify: Confirm whether your mobile inventory actually includes the affected Android framework exposure, not just whether devices are “Android.” Managed and unmanaged devices often drift apart, so verification needs to be fleet-specific and version-specific.

What to prioritise: Patch exposed devices first, then review the access they had while vulnerable. If the device reached mail, SSO, privileged apps, or administrative portals, treat the case as more than a normal handset update.

Practitioner takeaway: For KEV-listed mobile flaws, remediation speed matters, but trust recalibration matters too. The device should not be considered safe again until the platform issue is fixed and any enterprise access it could have carried is reviewed.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2023-35674 (Android Framework Privilege Escalation)?
• Is CVE-2025-48572 (Android Framework Privilege Escalation) being exploited in the wild?
• Is CVE-2024-43093 (Android Framework Privilege Escalation) being exploited in the wild?
• CVE-2023-35674 (Android Framework Privilege Escalation)