{“lastseen”:”2026-04-10T17:44:51″,”description”:”In this article\\n\\n 1. Technical details\\n 2. Disclosure timeline\\n 3. Mitigation and protection guidance\\n 4. References\\n 5. Learn more\\n\\n\\n\\nDuring routine security research, we identified a severe intent redirection vulnerability in a widely used third-party Android SDK called EngageSDK. This flaw allows apps on the same device to bypass Android security sandbox and gain unauthorized access to private data. With over 30 million installations of third-party crypto wallet applications alone, the exposure of PII, user credentials and financial data were exposed to risk. All of the detected apps using vulnerable versions have been removed from Google Play.\\n\\nFollowing our Coordinated Vulnerability Disclosure practices (via Microsoft Security Vulnerability Research), we notified EngageLab and the Android Security Team. We collaborated with all parties to investigate and validate the issue, which was resolved as of November 3, 2025 in version 5.2.1 of the EngageSDK. This case shows how weaknesses in third\u2011party SDKs can have large\u2011scale security implications, especially in high\u2011value sectors like digital asset management. \\n\\nAs of the time of writing, we are not aware of any evidence indicating that this vulnerability has been exploited in the wild. Nevertheless, we strongly recommend that developers who integrate the affected SDK upgrade to the latest available version. While this is a vulnerability introduced by a third-party SDK, Android\u2019s existing layered security model is capable of providing additional mitigations against exploitation of vulnerabilities through intents. Android has updated these automatic user protections to provide additional mitigation against the specific EngageSDK risks described in this report while developers update to the non-vulnerable version of EngageSDK. Users who previously downloaded a vulnerable app are protected.\\n\\nIn this blog, we provide a technical analysis of a vulnerability that bypasses core Android security mechanisms. We also examine why this issue is significant in the current landscape: apps increasingly rely on third\u2011party SDKs, creating large and often opaque supply\u2011chain dependencies. \\n\\nAs mobile wallets and other high\u2011value apps become more common, even small flaws in upstream libraries can impact millions of devices. These risks increase when integrations expose exported components or rely on trust assumptions that aren\u2019t validated across app boundaries. \\n\\nBecause Android apps frequently depend on external libraries, insecure integrations can introduce attack surfaces into otherwise secure applications. We provide resources for three key audiences: \\n\\n * Developers: In addition to the best practices Android provides its developers, we provide practical guidance on identifying and preventing similar flaws, including how to review dependencies and validate exported components. \\n * Researchers: Insights into how we discovered the issue and the methodology we used to confirm its impact. \\n * General readers: An explanation of the implications of this vulnerability and why ecosystem\u2011wide vigilance is essential. \\n\\n\\n\\nThis analysis reflects Microsoft\u2019s visibility into cross\u2011platform security threats. We are committed to safeguarding users, even in environments and applications that Microsoft does not directly build or operate. You can find a detailed set of recommendations, detection guidance and indicators at the end of this post to help you assess exposure and strengthen protections.\\n\\n## Technical details\\n\\nThe Android operating system integrates a variety of security mechanisms, such as memory isolation, filesystem discretionary and mandatory access controls (DAC\/MAC), biometric authentication, and network traffic encryption. Each of these components functions according to its own security framework, which may not always align with the others[1]. \\n\\nUnlike many other operating systems where applications run with the user\u2019s privileges, Android assigns each app with a unique user ID and executes it within its own sandboxed environment. Each app has a private directory for storing data that is not meant to be shared. By default, other apps cannot access this private space unless the owning app explicitly exposes data through components known as content providers. \\n\\nTo facilitate communication between applications, Android uses intents[2]. Beyond inter-app messaging, intents also enable interaction among components within the same application as well as data sharing between those components. \\n\\nIt\u2019s worth noting that while any application can send an intent to another app or component, whether that intent is actually delivered\u2014and more broadly, whether the communication is permitted\u2014depends on the identity and permissions of the sending application. \\n\\n### Intent redirection vulnerability \\n\\nIntent Redirection occurs when a threat actor manipulates the contents of an intent that a vulnerable app sends using its own identity and permissions. \\n\\nIn this scenario, the threat actor leverages the trusted context of the affected app to run a malicious payload with the app\u2019s privileges. This can lead to: \\n\\n * Unauthorized access to protected components \\n * Exposure of sensitive data \\n * Privilege escalation within the Android environment\\n\\nFigure 1. Visual representation of an intent redirection.\\n\\nAndroid Security Team classifies this vulnerability as severe. Apps flagged as vulnerable are subject to enforcement actions, including potential removal from the platform[3].\\n\\n### EngageLab SDK intent redirection\\n\\nDevelopers use the EngageLab SDK to manage messaging and push notifications in mobile apps. It functions as a library that developers integrate into Android apps as a dependency. Once included, the SDK provides APIs for handling communication tasks, making it a core component for apps that require real-time engagement.\\n\\nThe vulnerability was identified in an exported activity (_MTCommonActivity_) that gets added to an application’s Android manifest once the library is imported into a project, after the build process. This activity only appears in the merged manifest, which is generated post-build (see figure below), and therefore is sometimes missed by developers. Consequently, it often escapes detection during development but remains exploitable in the final APK.\\n\\nFigure 2. The vulnerable MTCommonActivity activity is added to the merged manifest.\\n\\nWhen an activity is declared as exported in the Android manifest, it becomes accessible to other applications installed on the same device. This configuration permits any other application to explicitly send an intent to this activity. \\n\\nThe following section outlines the intent handling process from the moment the activity receives an intent to when it dispatches one under the affected application’s identity. \\n\\nIntent processing in the vulnerable activity \\n\\nWhen an activity receives an intent, its response depends on its current lifecycle state: \\n\\n * If the activity is starting for the first time, the _onCreate()_ method runs. \\n * If the activity is already active, the _onNewIntent()_ method runs instead. \\n\\n\\n\\nIn the vulnerable _MTCommonActivity_ , both callbacks invoke the _processIntent()_ method. \\n\\nFigure 3: Calling the processIntent() method.\\n\\nThis method (see figure below) begins by initializing the _uri_ variable on line 10 using the data provided in the incoming intent. If the uri variable is not empty, then \u2013 according to line 16 – it invokes the _processPlatformMessage()_ : \\n\\nFigure 4: The processIntent() method.\\n\\nThe _processPlatformMessage()_ method instantiates a JSON object using the uri string supplied as an argument to this method (see line 32 below): \\n\\nFigure 5: The processPlatformMessage() method.\\n\\nEach branch of the _if_ statement checks the JSON object for a field named _n_intent_uri_. If this field exists, the method performs the following actions: \\n\\n * Creates a _NotificationMessage_ object \\n * Initializes its _intentUri_ field by using the appropriate setter (see line 52). \\n\\n\\n\\nAn examination of the _intentUri_ field in the _NotificationMessage_ class identified the following method as a relevant point of reference:\\n\\nFigure 6: intentUri usage overview.\\n\\nOn line 353, the method above obtains the _intentUri_ value and attempts to create a new intent from it by calling the method _a()_ on line 360. The returned intent is subsequently dispatched using the _startActivity(_) method on line 365. The _a()_ method is particularly noteworthy, as it serves as the primary mechanism responsible for intent redirection:\\n\\nFigure 7: Overview of vulnerable code.\\n\\nThis method appears to construct an implicit intent by invoking _setComponent()_ , which clears the target component of the _parseUri_ intent by assigning a null value (line 379). Under normal circumstances, such behavior would result in a standard implicit intent, which poses minimal risk because it does not specify a concrete component and therefore relies on the system\u2019s resolution logic. \\n\\nHowever, as observed on line 377, the method also instantiates a second intent variable \u2014 its purpose not immediately evident\u2014which incorporates an explicit intent. Crucially, this explicitly targeted intent is the one returned at line 383, rather than the benign _parseUri_ intent. \\n\\nAnother notable point is that the _parseUri()_ method (at line 376) is called with the URI_ALLOW_UNSAFE flag (constant value 4), which can permit access to an application\u2019s content providers [6] (see exploitation example below). \\n\\nThese substitutions fundamentally alter the method\u2019s behavior: instead of returning a non\u2011directed, system\u2011resolved implicit intent, it returns an intent with a predefined component, enabling direct invocation of the targeted activity as well as access to the application\u2019s content providers. As noted previously, this vulnerability can, among other consequences, permit access to the application’s private directory by gaining entry through any available content providers, even those that are not exported.\\n\\nFigure 8: Getting READ\/WRITE access to non-exported content providers.\\n\\nExploitation starts when a malicious app creates an intent object with a crafted URI in the extra field. The vulnerable app then processes this URI, creating and sending an intent using its own identity and permissions. \\n\\nDue to the URI_ALLOW_UNSAFE flag, the intent URI may include the following flags; \\n\\n * _FLAG_GRANT_PERSISTABLE_URI_PERMISSION_ \\n * _FLAG_GRANT_READ_URI_PERMISSION_ \\n * _FLAG_GRANT_WRITE_URI_PERMISSION_ \\n\\n\\n\\nWhen combined, these flags grant persistent read and write access to the app\u2019s private data. \\n\\nAfter the vulnerable app processes the intent and applies these flags, the malicious app is authorized to interact with the target app\u2019s content provider. This authorization remains active until the target app explicitly revokes it [5]. As a result, the internal directories of the vulnerable app are exposed, which allows unauthorized access to sensitive data in its private storage space. The following image illustrates an example of an exploitation intent:\\n\\nFigure 9: Attacking the MTCommonActivity.\\n\\n### Affected applications \\n\\nA significant number of apps using this SDK are part of the cryptocurrency and digital\u2011wallet ecosystem. Because of this, the consequences of this vulnerability are especially serious. Before notifying the vendor, Microsoft confirmed the flaw in multiple apps on the Google Play Store.\\n\\nThe affected wallet applications alone accounted for more than 30 million installations, and when including additional non\u2011wallet apps built on the same SDK, the total exposure climbed to over 50 million installations. \\n\\n## Disclosure timeline\\n\\nMicrosoft initially identified the vulnerability in version 4.5.4 of the EngageLab SDK. Following Coordinated Vulnerability Disclosure (CVD) practices through Microsoft Security Vulnerability Research (MSVR), the issue was reported to EngageLab in April 2025. Additionally, Microsoft notified the Android Security Team because the affected apps were distributed through the Google Play Store. \\n\\nEngageLab addressed the vulnerability in version 5.2.1, released on November 3, 2025. In the fixed version, the vulnerable activity is set to non-exported, which prevents it from being invoked by other apps. \\n\\nDate | Event \\n—|— \\nApril 2025 | Vulnerability identified in EngageLab SDK v4.5.4. Issue reported to EngageLab \\nMay 2025 | Escalated the issue to the Android Security Team for affected applications distributed through the Google Play Store. \\nNovember 3, 2025 | EngageLab released v5.2.1, addressing the vulnerability \\n \\n## Mitigation and protection guidance\\n\\nAndroid developers utilizing the EngageLab SDK are strongly advised to upgrade to the latest version promptly. \\n\\nOur research indicates that integrating external libraries can inadvertently introduce features or components that may compromise application security. Specifically, adding an exported component to the merged Android manifest could be unintentionally overlooked, resulting in potential attack surfaces. To keep your apps secure, always review the merged Android manifest, especially when you incorporate third\u2011party SDKs. This helps you identify any components or permissions that might affect your app\u2019s security or behavior.\\n\\n### Keep your users and applications secure\\n\\nStrengthening mobile\u2011app defenses doesn\u2019t end with understanding this vulnerability.\\n\\nTake the next step: \\n\\n * Strengthen your defenses with Microsoft Defender XDR \\n * Accelerate investigations with Microsoft Security Copilot \\n\\n\\n\\nLearn more about Microsoft\u2019s Security Vulnerability Research (MSVR) program at https:\/\/www.microsoft.com\/en-us\/msrc\/msvr\\n\\n## References\\n\\n[1] Mayrhofer, Ren\u00e9, Jeffrey Vander Stoep, Chad Brubaker, Dianne Hackborn, Bram Bonn\u00e9, G\u00fcliz Seray Tuncay, Roger Piqueras Jover, and Michael A. Specter. The Android Platform Security Model (2023). ACM Transactions on Privacy and Security, vol. 24, no. 3, 2021, pp. 1\u201335. arXiv:1904.05572. https:\/\/doi.org\/10.48550\/arXiv.1904.05572. \\n\\n[2] https:\/\/developer.android.com\/guide\/components\/intents-filters \\n\\n[3] https:\/\/support.google.com\/faqs\/answer\/9267555?hl=en \\n\\n[4] https:\/\/www.engagelab.com\/docs\/ \\n\\n[5] https:\/\/developer.android.com\/reference\/android\/content\/Intent#FLAG_GRANT_PERSISTABLE_URI_PERMISSION \\n\\n[6] https:\/\/developer.android.com\/reference\/android\/content\/Intent#URI_ALLOW_UNSAFE\\n\\n_This research is provided by Microsoft Defender Security Research with contributions from Dimitrios Valsamaras_ _and other members of Microsoft Threat Intelligence._\\n\\n## Learn more\\n\\nReview our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization. \\n\\n * Evaluate your AI readiness with our latest Zero Trust for AI workshop.\\n * Learn more about Protect your agents in real-time during runtime (Preview)\\n * Explore how to build and customize agents with Copilot Studio Agent Builder \\n * Microsoft 365 Copilot AI security documentation \\n * How Microsoft discovers and mitigates evolving attacks against AI guardrails \\n * Learn more about securing Copilot Studio agents with Microsoft Defender \\n\\n\\n\\nThe post Intent redirection vulnerability in third-party SDK exposed millions of Android wallets to potential risk appeared first on Microsoft Security Blog.”,”published”:”2026-04-09T13:21:18″,”modified”:”2026-04-09T13:21:18″,”type”:”mssecure”,”title”:”Intent redirection vulnerability in third-party SDK exposed millions of Android wallets to potential risk”,”source”:””,”references”:””,”id”:”MSSECURE:3565466EE661431E6D6FB3009757C720″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.microsoft.com\/en-us\/security\/blog\/2026\/04\/09\/intent-redirection-vulnerability-third-party-sdk-android\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-10T17:44:51″,”description”:”In this article\\n\\n 1. Technical details\\n 2. Disclosure timeline\\n 3. Mitigation and protection guidance\\n 4. References\\n 5. Learn more\\n\\n\\n\\nDuring routine security research, we identified a…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,110,13,33,7,11,5],"class_list":["post-42670","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-mssecure","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n