CVE-2024-35255

What it actually does

This is a local elevation-of-privilege/confidentiality issue in Microsoft Authentication Library/Azure Identity Library code for Android caused by a race condition. A local attacker with low privileges on the same Android device could potentially win a timing window during authentication-library operations and gain access to sensitive authentication material or identity-related data that should be isolated from that attacker. The CVSS vector indicates local access is required, exploitation complexity is low, no user interaction is required, scope is unchanged, and the primary impact is high confidentiality exposure rather than integrity or availability loss.

Why it matters to the business

Applications that embed a vulnerable version of the Microsoft Authentication Library for Android may expose user authentication data on a compromised or shared device, which can lead to account access, privacy violations, incident response costs, and loss of trust in mobile authentication flows. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported mature public exploit, so it is generally lower urgency than remotely exploitable internet-facing flaws; however, it has been public for a long time and should be removed from supported mobile applications during normal dependency maintenance.

How an attack unfolds

An attacker first needs local code execution or an app-level foothold on the same Android device, such as through a malicious installed application, a compromised device, or another local execution path. The attacker then targets an application that uses the vulnerable Microsoft Authentication Library for Android. By repeatedly interacting with, monitoring, or racing authentication-library operations, the attacker attempts to trigger the vulnerable timing condition. If the race is won, the attacker may gain access to sensitive identity or token-related information that the library should have protected. The attacker can then use the exposed data to impersonate the affected user or access downstream services, subject to token validity, conditional access controls, device binding, and server-side session protections.

How to fix it

Update applications that use azuread/microsoft-authentication-library-for-android to a version that includes the upstream fix. The fixed upstream Git commit is 3da30567e68ec62987d2c57d7967135fb3883fc5. If consuming MSAL Android through a package manager rather than directly from Git, upgrade to the first released package version that contains this commit or any later supported version. Rebuild and redeploy affected Android applications after updating the dependency; simply updating source control is not sufficient for already-distributed mobile apps. If immediate upgrade is not possible, reduce exposure by limiting use on unmanaged or rooted devices, enforcing mobile device compliance and app protection policies, minimizing token lifetimes where practical, requiring strong conditional access, and revoking sessions for users/devices suspected of compromise.

How to confirm the fix worked

Confirm the application dependency tree no longer resolves to vulnerable MSAL Android code and that the source or binary includes the fix corresponding to commit 3da30567e68ec62987d2c57d7967135fb3883fc5 or a later release. For source builds, inspect lockfiles, Gradle dependency output, vendored source, and software composition analysis results. For compiled Android artifacts, inspect the APK/AAB software bill of materials or decompile/scan the packaged libraries to confirm the updated Microsoft Authentication Library is present. Perform regression testing of sign-in, token acquisition, token refresh, account switching, brokered authentication if used, and sign-out. Validate exposure reduction by ensuring vulnerable application versions are no longer distributed through app stores, MDM/MAM channels, or internal release pipelines.

Typical attack path

1. Gain local execution capability on the same Android device as a target application using the vulnerable authentication library.
2. Identify that a target mobile application includes the affected Microsoft Authentication Library for Android code path.
3. Trigger or wait for authentication-library activity such as sign-in, token acquisition, account selection, or token refresh.
4. Exploit the race condition by manipulating timing around the vulnerable operation.
5. Recover sensitive authentication or identity data exposed through the race condition.
6. Use the recovered data to attempt access to protected services or user resources before tokens expire or are revoked.

How to detect it

There are no widely published, unique exploit indicators for this issue, and successful exploitation may not leave a distinctive application log entry because it is a local library race condition. Detection should combine exposure analysis with identity and endpoint telemetry. Review mobile application inventories, SBOMs, Gradle dependency reports, and SCA findings to identify apps built with vulnerable MSAL Android code. For possible prior exploitation, examine Microsoft Entra ID sign-in logs, token issuance and refresh activity, conditional access results, device identifiers, user agents, and impossible-travel or unfamiliar-device alerts for users who used vulnerable app versions. On managed Android endpoints, review EDR/MDM telemetry for malicious or sideloaded applications, rooted or tampered devices, suspicious inter-process behavior, accessibility abuse, overlay abuse, credential/token theft tooling, and abnormal access to application-private storage. Application teams should review crash logs and debug logs around authentication flows for unusual race-related errors, repeated token acquisition attempts, unexpected account context changes, or authentication cache anomalies, while avoiding collection of sensitive tokens in logs. Treat suspicious identity events as potentially token-related: revoke sessions, rotate credentials where applicable, require reauthentication, and correlate timing with vulnerable app usage.

What your security team should do

• Inventory Android applications that include Microsoft Authentication Library for Android or Azure Identity authentication components.
• Prioritize updating any supported app that uses azuread/microsoft-authentication-library-for-android to a release containing commit 3da30567e68ec62987d2c57d7967135fb3883fc5 or later.
• Rebuild, sign, and redistribute patched mobile application versions; track adoption and force upgrade where business risk justifies it.
• Use software composition analysis and mobile build pipeline checks to prevent reintroduction of vulnerable MSAL Android versions.
• Review identity telemetry for anomalous sign-ins, token use, and device changes associated with users of vulnerable mobile app versions.
• Apply compensating controls for high-risk users, including conditional access, device compliance enforcement, app protection policies, session revocation, and shorter refresh-token validity where appropriate.
• Because there is no known KEV listing, ransomware association, or mature public exploit, handle as a dependency remediation item with elevated attention for apps used on unmanaged, shared, or high-risk Android devices.