EngageLab SDK vulnerability: Android intent redirection flaw

Last updated: 2026-10-02

On April 9, 2026, Microsoft's Defender Security Research Team published its analysis of an intent redirection vulnerability in the EngageLab SDK (EngageSDK), a push notification and messaging library for Android apps. An exported activity, MTCommonActivity, let a malicious app on the same phone obtain persistent read and write access to the private files of the app that bundles the SDK (the host app). Microsoft found the flaw in SDK version 4.5.4; EngageLab fixed it in version 5.2.1, released on November 3, 2025. Microsoft reports more than 30 million installs of crypto wallet apps with the vulnerable SDK and over 50 million installs in total.

An intent is Android's message object for asking another app component to do something. Intent redirection is the case where an attacker controls an intent that a vulnerable app then sends with its own identity and permissions.

How does the EngageLab SDK vulnerability work?

Microsoft's analysis traces the path through the SDK's code:

1. MTCommonActivity is declared with android:exported="true" in the SDK's manifest. The Android build merges the SDK's manifest into the app's, so the declaration is present in the built APK; Microsoft notes that developers sometimes miss it there. Any app on the device can send it an intent.
2. Both onCreate() and onNewIntent() call processIntent(), which passes the incoming data to processPlatformMessage(). That method parses the data as JSON and takes the string in a field named n_intent_uri.
3. The SDK turns that string into an intent with parseUri() and the URI_ALLOW_UNSAFE flag (constant value 4). It returns a second, explicit intent, with a set target component in place of a system-resolved one, and starts it with startActivity() under the host app's identity.

Because of URI_ALLOW_UNSAFE, the crafted URI can contain FLAG_GRANT_PERSISTABLE_URI_PERMISSION, FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION. Per Microsoft, "When combined, these flags grant persistent read and write access to the app's private data." Microsoft adds that the grant covers the host app's content providers, "even those that are not exported". The Android Intent reference states a persistable grant "can be persisted across device reboots until explicitly revoked". The attacker needs a malicious app already installed on the same device; the flaw is local to the phone.

Which EngageLab SDK versions are affected?

EngageLab's security statement lists "EngageLab Android SDK v5.2.0 and earlier" as affected and v5.2.1 and later as fixed. The fix sets MTCommonActivity to android:exported="false"; EngageLab also lists "Input validation for incoming Intent data" among further changes.

I downloaded every numbered release of com.engagelab:engagelab from Maven Central on October 2, 2026 (versions 3.0.0 to 5.5.1, 33 releases) and read the AndroidManifest.xml inside each .aar file. All 23 releases from 3.0.0 to 5.2.0 declare MTCommonActivity with android:exported="true" (in 4.5.4, on line 24 of the manifest); all 10 releases from 5.2.1 to 5.5.1 declare android:exported="false". The activity class is com.engagelab.privates.common.component.MTCommonActivity.

Sources: the .aar files in each Maven Central directory linked above, opened on 2026-10-02; status column from EngageLab's statement. The manifest column shows the exported flag only. Microsoft analyzed the redirection code in 4.5.4; my check covers the exported flag in every release and leaves the code path of the other releases unexamined. An app developer can override the flag in the app's own manifest, so the built APK is the evidence for any given app.

How many apps and users were affected?

Microsoft reports that "The affected wallet applications alone accounted for more than 30 million installations, and when including additional non‑wallet apps built on the same SDK, the total exposure climbed to over 50 million installations" (Microsoft). Microsoft gives the figures as installations and states no counting method. The report gives no count of devices that still had a vulnerable build in April 2026.

Microsoft states that "All of the detected apps using vulnerable versions have been removed from Google Play" and names none of them. Google Play's general remediation page for intent redirection flaws states that "any apps that contain unfixed security vulnerabilities will be removed from Google Play" after the deadline shown in the Play Console. Neither Microsoft nor EngageLab names the apps or says whether each one was removed or updated to 5.2.1.

On exploitation, Microsoft wrote: "we are not aware of any evidence indicating that this vulnerability has been exploited in the wild." EngageLab's statement says "No known exploitation in the wild based on information available to us." Microsoft adds that Android updated its automatic user protections "to provide additional mitigation against the specific EngageSDK risks described in this report" and that "Users who previously downloaded a vulnerable app are protected"; Microsoft's post gives no detail on how that protection works.

When was the EngageLab flaw reported and fixed, and is there a CVE?

The two primary timelines differ on the first report. Microsoft states it reported the issue to EngageLab in April 2025 and escalated it to the Android Security Team in May 2025. EngageLab states it "was notified of the issue through the Android / Google security review process" in May 2025.

Neither Microsoft's post nor EngageLab's statement gives a CVE identifier, and a keyword search of the NVD CVE API for "EngageLab", "EngageSDK" and "MTCommonActivity" returned zero records on October 2, 2026. The OSV database and the GitHub Advisory Database returned no advisory for com.engagelab:engagelab on the same date. Version scanners that match dependencies against these databases therefore have no record to match for this flaw; the identifiers are the SDK version (5.2.0 or earlier) and the android:exported value on MTCommonActivity.

The host apps got the exported activity by adding the SDK dependency with its default manifest. The post on the EFF ad SDK location study covers another SDK default: ad SDKs that include precise location in ad auction requests.

What does a scan of an Android app show for the EngageLab flaw?

A built APK contains the merged AndroidManifest.xml and the dex files, and a binary scan parses both. The manifest shows whether MTCommonActivity is declared and its android:exported value; the dex files show whether com.engagelab.privates classes are present. An exported MTCommonActivity with those classes is presence evidence: the vulnerable component is in the build. Exploitation is a separate on-device test, run with a second, attacking app installed on the same phone as the target.

When I scan an Android app, the report lists the SDKs found in the binary, the permissions the manifest declares, the consent flow, and the network traffic recorded on test devices: what was sent, to which host, and whether before or after consent. Every static finding cites its file and line; every traffic finding cites its capture. What a scan checks and the limits of a scan are on the methodology page.

I run these investigations for lawyers and for researchers working with lawyers, on one app or on a list of apps in bulk. Sign up for a CanITrustThat account to run your own research, let us run an investigation for you, or browse the scanned apps.