During routine security research, Microsoft uncovered a critical intent redirection vulnerability in a widely used third-party Android library, EngageSDK. This flaw exposed millions of users to potential data breaches by allowing malicious apps to bypass Android’s sandbox protections and access sensitive information such as credentials, personal data, and financial assets.
With over 30 million installations in crypto wallet apps alone, and more than 50 million total affected installations, the scale of risk was significant. Fortunately, all vulnerable applications were removed from Google Play, and a patched version of the SDK (v5.2.1) was released on November 3, 2025.
Understanding Android’s Security Model
Android enforces strict application isolation using a sandboxing mechanism, where each app runs under a unique user ID. This ensures that:
- Apps cannot access each other’s private data
- Sensitive storage remains isolated
- Interactions occur only through controlled mechanisms like intents
Intents serve as a messaging system that allows apps and their components to communicate. However, when improperly handled, they can become an attack vector.
What is Intent Redirection?
Intent redirection occurs when a malicious app manipulates an intent sent by a trusted app, effectively hijacking its permissions.
This vulnerability can lead to:
- Unauthorized access to protected components
- Leakage of sensitive data
- Privilege escalation within the Android ecosystem
In this case, attackers could exploit a trusted app’s identity to execute malicious actions—making the attack particularly dangerous.
Root Cause: EngageSDK’s Exported Activity
The issue originated in an exported activity named MTCommonActivity, automatically added during the SDK integration process. Because it appears only in the merged Android manifest, developers often overlook it.
Key problems included:
- The activity was exported, making it accessible to any app
- It processed incoming intents without proper validation
- It allowed malicious payloads via crafted URI data
Once triggered, the activity parsed a malicious URI and constructed a new intent using unsafe configurations.
Dangerous Implementation Details
The vulnerability was amplified by two critical issues:
1. Unsafe Intent Construction
The SDK created an explicit intent instead of a safe implicit one, allowing direct targeting of internal components.
2. Use of URI_ALLOW_UNSAFE Flag
This flag enabled dangerous permissions such as:
- Persistent read/write access
- Access to content providers (even non-exported ones)
As a result, attackers could gain long-term access to an app’s private storage.
Exploitation Flow
A typical attack would involve:
- A malicious app crafting an intent with a harmful URI
- Sending it to the vulnerable exported activity
- The target app processing the URI and generating a new intent
- Execution occurring under the trusted app’s identity
- Persistent access granted to sensitive data
This effectively breaks Android’s sandbox model.
Mitigation and Fix
The issue was responsibly disclosed through coordinated vulnerability disclosure practices. The fix included:
- Setting the vulnerable activity to non-exported
- Strengthening Android’s system-level protections
- Encouraging developers to upgrade to SDK version 5.2.1
Importantly, there is no evidence of active exploitation, and users are protected through platform-level safeguards.
Key Takeaways for Developers
- Always review merged Android manifests
- Avoid unnecessary exported components
- Validate all incoming intents rigorously
- Audit third-party dependencies regularly
- Follow secure coding practices for inter-app communication
Our Opinion on This Case
This incident is a strong reminder that modern software security is only as strong as its weakest dependency. While Android’s sandbox architecture is robust by design, this case demonstrates how indirect trust—placed in third-party SDKs—can undermine even well-built applications.
What stands out most is how subtle the vulnerability was. The problematic activity was not directly written by developers but introduced during the build process. This reflects a broader industry issue: developers often trust SDKs without deeply auditing their internal behavior. In reality, these libraries operate with the same privileges as the host app, making them high-risk components.
We also believe this case reinforces the importance of secure defaults. SDK providers must ensure that features like exported components are disabled unless explicitly required. Security should not depend on developers catching hidden configurations after compilation.
On a positive note, the coordinated response between researchers, vendors, and platform maintainers shows how effective collaboration can mitigate large-scale risks. However, relying on reactive fixes is not enough.
Going forward, organizations must adopt a “zero-trust dependency model”, where every external component is treated as potentially unsafe until verified. This mindset is essential in an ecosystem where a single overlooked flag can expose millions of users.
