CVE-2023-35674

What it actually does

CVE-2023-35674 is a local privilege escalation flaw in the Android Framework, specifically in WindowState.java. A logic error in onCreate can allow an application to launch an activity from the background when it should be restricted by Android’s background activity launch controls. Because exploitation requires only local app execution with low privileges and no user interaction, a malicious installed application can abuse this behavior to gain elevated capabilities or access paths normally gated by foreground execution, potentially affecting confidentiality, integrity, and availability on the device.

Why it matters to the business

Successful exploitation can allow a malicious Android application already present on a device to bypass platform protections and escalate privileges, increasing the risk of data theft, unauthorized changes, persistence, spyware behavior, or device disruption. This vulnerability is listed in CISA’s Known Exploited Vulnerabilities catalog with a remediation due date of 2023-10-04 and is reported as actively exploited in the wild, so organizations managing Android fleets should treat exposure as high priority even though exploitation starts locally. The lack of user interaction increases operational risk because compromise can occur after app installation without additional prompts or obvious user action.

How an attack unfolds

An attacker first gets a malicious application installed on a vulnerable Android device, commonly through sideloading, a trojanized application, phishing that persuades a user to install an APK, abuse of an app distribution channel, or compromise of an already installed app. Once running with ordinary application privileges, the malicious app triggers the vulnerable Android Framework logic path in WindowState.java. Due to the flaw, the app can cause a background activity launch that should normally be blocked. That bypass can be used as part of a local privilege escalation chain to access privileged flows, manipulate user-visible or system-mediated actions, or combine with other Android weaknesses to obtain broader control of the device. Because this vulnerability is in the Android Framework and is known exploited in the wild, defenders should assume commodity mobile malware or targeted spyware may use it as one stage in a larger infection chain rather than as a standalone observable event.

How to fix it

Apply the Android security update that includes the fix for CVE-2023-35674. In practice, this means updating affected Google Android devices to a vendor build that incorporates the September 2023 Android Security Bulletin fixes or a later security patch level that explicitly includes this issue. Because Android fixes are delivered through device OEMs and carriers, verify the patch level and build provenance for each device model rather than relying only on the Android major version. For managed fleets, enforce minimum Android security patch levels through enterprise mobility management or mobile device management policy, block enrollment or access from devices below the required patch level, and prioritize devices that allow sideloading or are outside standard app-control policy. Where immediate patching is not possible, reduce risk by disabling or restricting sideloading, enforcing Google Play Protect or equivalent mobile threat defense, limiting installation to trusted app stores, removing unknown or untrusted applications, and isolating vulnerable devices from sensitive applications and data.

How to confirm the fix worked

Confirm remediation by verifying that each affected device reports an Android security patch level at or after the vendor update that includes the September 2023 Android Framework fixes for this issue, or a later OEM advisory that explicitly lists CVE-2023-35674 as fixed. Validate through device settings, Android Enterprise/MDM inventory, or ADB where authorized using properties such as ro.build.version.security_patch and build fingerprint data. Confirm that OEM firmware, not only application updates, has been applied because the vulnerable code is in the Android Framework. For exposure validation, inventory Android devices by model, OS build, and security patch level; flag devices with security patch levels before the relevant September 2023 fix level or unsupported devices that no longer receive framework security updates. Where possible, test policy controls by ensuring untrusted app installation is blocked and devices below the required patch level are denied access to enterprise resources.

Typical attack path

1. Attacker prepares or obtains a malicious Android application that contains logic to trigger the vulnerable Android Framework behavior.
2. Victim device runs a vulnerable Android build that has not received the security update containing the fix.
3. Attacker gets the app installed or executed on the device through sideloading, social engineering, app repackaging, malicious mobile device management abuse, or another initial access method.
4. The malicious app runs with low local privileges and invokes the affected background activity launch path.
5. The Android Framework incorrectly permits an activity launch from the background due to the WindowState.java logic error.
6. The attacker uses the unintended activity launch to bypass platform restrictions and escalate local privileges or advance a broader exploit chain.
7. The attacker performs follow-on actions such as data access, persistence, surveillance, additional payload execution, or device setting manipulation.

How to detect it

Detection should focus on signs of exploitation chains rather than a single guaranteed log line, because the vulnerable behavior occurs inside the Android Framework and may not produce a unique public artifact. Use MDM/UEM, mobile threat defense, Android forensic collections, and EDR telemetry to identify vulnerable devices that had suspicious app activity while unpatched. Review application installation history for sideloaded APKs, unknown package sources, newly installed apps shortly before abnormal behavior, and apps granted sensitive permissions such as accessibility, notification listener, device administrator, VPN, SMS, contacts, location, overlay, or usage access. Examine Android logs where available for unexpected background activity starts, activity-task-manager events, process starts from non-foreground apps, and repeated attempts to launch activities while the app is backgrounded. Investigate signs of mobile malware follow-on activity: persistence through device-admin or accessibility services, overlay phishing, unusual outbound network connections, credential or token access, SMS interception, screen capture, microphone/camera access, or disabling of security tools. Since this vulnerability is KEV and actively exploited, correlate suspicious app behavior with devices running Android security patch levels before the fix. Threat intelligence references this as an Android Framework privilege escalation vulnerability, so detection should include both generic mobile malware hunting and targeted review of suspicious background activity launches on unpatched devices.

• ro.build.version.security_patch=<2023-09-01
• ro.build.version.security_patch=<2023-09-05
• Unknown sources enabled
• Install unknown apps allowed
• android.permission.SYSTEM_ALERT_WINDOW
• android.permission.BIND_ACCESSIBILITY_SERVICE
• android.permission.BIND_NOTIFICATION_LISTENER_SERVICE
• android.app.action.ADD_DEVICE_ADMIN
• android.permission.REQUEST_INSTALL_PACKAGES
• ActivityTaskManager
• ActivityManager
• Background activity start
• Background activity launch
• START u0
• cmp=

What your security team should do

• Prioritize patch verification across all managed Android devices because the vulnerability is in CISA KEV, has a past federal remediation deadline of 2023-10-04, and is reported as actively exploited in the wild.
• Set or raise the minimum allowed Android security patch level in MDM/UEM to a build that includes the September 2023 Android Framework security fixes or later.
• Identify and quarantine or restrict access for devices that are unsupported, cannot receive OEM fixes, or report outdated Android security patch levels.
• Disable sideloading and unknown-source installation where operationally feasible; alert on policy drift enabling APK installation from untrusted sources.
• Review mobile threat defense, EDR, or MDM telemetry for suspicious app installations, background activity launch abuse, accessibility-service misuse, device-admin grants, and unusual permission escalation following app install events.
• Remove unknown, recently installed, repackaged, or non-business applications from devices that were vulnerable during the exploitation window.
• Communicate to users that OS security updates are required and that installing apps from outside trusted stores materially increases risk.
• If compromise is suspected, preserve mobile forensic evidence before wiping, including installed package lists, app install times, Android event logs where available, MDM telemetry, and network activity from suspicious apps.