A critical Android software development kit (SDK) flaw has turned a utility tool into a malware bridge, gaining access to some of the platform’s most secure apps.
The EngageLab SDK is used in many Android apps as a push notification tool. Once integrated, it inherits the same level of permission and trust as its host app. Microsoft’s research reveals that the vulnerability stems from the way the SDK processes app-to-app messages, allowing malicious external apps to send harmful messages that are misread as legitimate internal commands.
Although already patched, Microsoft security researchers say that upon discovery, several apps were running the vulnerable version of the EngageLab SDK, leaving more than 50 million users exposed. On its end, Android has taken down these flagged apps.
How does the EngageLab SDK work
To better understand this vulnerability and the potentially severe consequences of a successful exploit, one needs to understand how the SDK operates.
EngageLab SDK is a popular push notification tool used by many Android apps. By integrating with apps, developers save time building such a feature from scratch.
Because the tool sits deep within the app’s security sandbox, a place reserved for highly trusted services, its critical location grants it access to the host app’s internal files and data, as well as every user permission the app has.
To function, it uses intents, a communication framework Android apps use to pass messages between components within the app or with other apps on the same device. It relies on these intents to read app behavior, communicate with its servers, trigger notifications, or even route users to a page.
In other words, it behaves like a trusted internal module of an app, even though it comes from a third-party provider. That trust is what makes it a powerful utility, and also what makes its flaws a time bomb waiting to explode.
How does a utility tool turn into a malware bridge?
Microsoft calls the vulnerability an “intent redirection vulnerability.” Put simply, the SDK accepts a specially crafted message from outside its host app sent as an intent(message), trusts it, and executes its instructions inside its privileged environment.
Under the hood, a successful exploit will follow this flow:
- App integration: A legitimate app integrates the SDK for push notifications, which runs inside the app and inherits its permissions.
- An exposed entry point: The SDK uses exported components (application elements made available to other apps) to communicate with other apps on the device. Microsoft notes that the risk originates from developers assuming that any element being called is from a trusted app, which is fine, except that the SDK itself fails to validate the source of those requests because it assumes they come from within the app it’s integrated into.
- Malicious step-in: A malicious app on this same device sends a crafted message to this exposed element. Because no special permissions are required, Android allows this by design.
- The break-in trick: Because the SDK does not properly validate any incoming message, it assumes they are from within, and hence, should be trusted. By trusting the message, the SDK executes its hidden instruction, which can include accessing private app files, triggering internal components, and exfiltrating sensitive credentials such as crypto wallet keys.
The vulnerability is, in effect, an abuse of privileged trust, sharing some high-level similarity with an SQL injection attack.
Microsoft’s preventive role in this
According to Microsoft, the vulnerability was discovered during routine security research.
Upon further investigation, Microsoft found that apps using vulnerable versions of the SDK accounted for more than 50 million installations, including over 30 million installations of third-party crypto wallet apps alone. This means that a successful exploit could quickly turn into one of the biggest financial losses in recent years.
Microsoft, through its coordinated vulnerability disclosure practice, informed EngageLab’s team of it in April 2025. On November 3, 2025, the EngageLab Team resolved the issues in version 5.2.1.
A month after informing the EngageLab team, Microsoft notified Android of the vulnerability. Android responded by removing all flagged apps that were running the vulnerable SDK version from the Google Play Store.
What developers and users must do to stay safe
On the bright side, Microsoft notes that as of April 9, 2026, five months after the patch, and 12 months after the first discovery, there has not been any known exploitation of this vulnerability. However, staying safe from vulnerabilities like this requires a joint effort from developers and users.
For developers, an app is as secure as the third-party tools it relies on. While EngageLab is a popular choice, developers are advised to conduct their own independent research on each library they add to their apps. Popular, vulnerable third-party tools can have severe consequences if exploited.
Developers whose apps are still running on any EngageLab SDK version below 5.2.1 are strongly advised to update the tool to keep their users safe.
On the other hand, users are always advised to download reputable apps and read reviews before installing potentially high-risk apps. This is because the vulnerability can only be exploited if a user-installed malicious app sends a crafted message to the EngageLab SDK of a secure app running on a vulnerable version of the SDK.
Also read: Google has patched an actively exploited Chrome zero-day vulnerability that could enable full device compromise.
Read the full article here
