In April 2025, Microsoft's threat research team quietly began a responsible disclosure process that would culminate in one of the more consequential mobile supply chain vulnerabilities of the year. The target was not a household-name application. It was the EngageLab Android SDK — a push notification and engagement library embedded inside dozens of apps, including a significant cluster of cryptocurrency and digital wallet applications. By the time EngageLab shipped the patched v5.2.1 in November 2025, Microsoft estimated the vulnerable SDK had reached over 50 million Android installs, with more than 30 million of those belonging to wallet apps specifically.
This post breaks down exactly how the vulnerability works, what data is at risk, how to detect exposure in your mobile application portfolio, and what developers and security teams need to do right now. If your organization ships Android apps or manages a mobile app inventory, this supply chain risk belongs on your radar.
How the EngageLab Intent-Redirection Flaw Actually Works
Android Intents and the Exported Component Problem
Android's Intent system is the inter-process communication backbone of the operating system. Apps use Intents to pass data between components — activities, services, broadcast receivers — both within the same app and across different apps. When a component is marked as exported="true" in an app's manifest, other apps on the device can send Intents directly to it.
The EngageLab SDK contained exported components that did not adequately validate the source or content of incoming Intents. This created a classic intent-redirection vulnerability: a malicious app installed on the same device could craft a malformed Intent, direct it at the exported SDK component, and intercept or redirect Intents that were supposed to stay within the target app's trust boundary.
What an Attacker Can Capture
The data traveling inside Intents in a wallet application context is not trivial. Depending on how the developer implemented their app and integrated the SDK, exploitable Intents could carry:
- Wallet addresses and transaction metadata
- User identifiers and session tokens
- Authentication parameters passed between app components
- Deeplink payloads carrying payment or transfer details
This maps to MITRE ATT&CK technique T1417 (Input Capture: GUI Input Capture on mobile) and T1409 (Stored Application Data access), with the delivery mechanism relying on T1474 (Supply Chain Compromise) — the SDK is the vector, not the app developer's own code.
Important: Developers who used EngageLab's push notification features may not have realized they were also inheriting exported components that touched their app's Intent routing. SDK integration documentation rarely surfaces this kind of secondary exposure. Assuming a library only affects the feature you integrated it for is a persistent and costly mistake in mobile security.
The Supply Chain Risk Model: Why SDK Vulnerabilities Scale Differently
A flaw in one application affects the users of that application. A flaw in a widely distributed SDK affects every application that bundles it, proportional to each app's install base. This is the core reason supply chain vulnerabilities carry outsized risk — the blast radius scales with adoption, not with the vulnerability's technical sophistication.
The EngageLab case illustrates this precisely. The SDK itself may have had a narrow user base, but it was embedded in applications with collective installs exceeding 50 million. The wallet subset alone — 30 million installs — represents a financially motivated attacker's near-ideal target profile: high value data, user population with assets worth stealing, and a vulnerability that requires only a malicious co-installed app to exploit.
Historical Context and Trend
This pattern is not new. The mobile SDK supply chain has produced critical vulnerabilities repeatedly:
| Year | SDK / Library | Affected Apps | Risk Category |
|---|---|---|---|
| 2023 | SpinOk (malware SDK) | 421 apps, 421M installs | Data exfil, ad fraud |
| 2024 | Multiple ad SDKs | Dozens of finance apps | Intent hijacking, data leakage |
| 2025 | EngageLab (<5.2.1) | 50M+ installs, 30M wallets | Intent redirection, credential exposure |
The CVSSv3 score for the EngageLab flaw is 9.3 — critical. That score reflects the combination of low attack complexity, no required permissions for the malicious app, and high confidentiality impact.
Detection and Risk Assessment for Security Teams
Inventorying Your Mobile App Portfolio
If your organization develops or manages Android applications, the first question is whether any of them embed the EngageLab SDK at a version prior to 5.2.1. This is not always easy to answer. Many development teams integrate SDKs via package managers and do not maintain a live software bill of materials (SBOM) for their mobile apps.
Recommended steps:
- Pull current APKs for all managed applications and decompile using
apktoolor a SAST tool with dependency detection (MobSF works well here) - Search the decompiled output for EngageLab package references (
com.engagelaborcom.push.android) - Cross-reference the identified version string against the v5.2.1 threshold
- Review the AndroidManifest.xml of any app using EngageLab for exported component declarations
Pro Tip: Run this analysis against your production APK, not your source tree. Build pipelines sometimes inject SDK versions different from what's declared in your project-level build files, particularly when using automated dependency resolution. The APK in production is the ground truth.
Mobile Application Security Testing Alignment
This vulnerability class is covered under OWASP Mobile Top 10 M1 (Improper Credential Usage) and M8 (Security Misconfiguration), which includes insecure component exports. Your mobile SAST and DAST tooling should flag exported components that handle sensitive data without source validation.
| Detection Method | What It Finds | Tooling |
|---|---|---|
| Static manifest analysis | Exported components in SDK | MobSF, apktool, manual review |
| SAST (dependency scan) | EngageLab SDK version | MobSF, Checkmarx, Semgrep |
| Dynamic analysis (DAST) | Intent interception at runtime | Frida, Drozer, custom instrumentation |
| Play Store vetting reports | Google's removal notices | Google Play Console, MDM reporting |
| SBOM audit | SDK version inventory across fleet | CycloneDX, SBOM tooling in CI/CD |
Developer Remediation: What Needs to Happen
Update the SDK — But That's Not the Complete Fix
The immediate action is updating to EngageLab SDK v5.2.1 or later. This is necessary but not sufficient. Developers who have been shipping vulnerable builds need to audit their own manifest declarations alongside the SDK update.
Specifically:
- Review every component in
AndroidManifest.xmlforexported="true"declarations, particularly those added or modified during SDK integration - Ensure that components handling sensitive Intents implement explicit source validation — check the calling package against an allowlist where possible
- Remove or restrict exported components that do not require cross-app accessibility
- Implement
android:permissionattributes on exported receivers and activities to require a custom permission for callers
Apps using explicit Intents to communicate internally do not require components to be exported. If the SDK integration documentation instructed developers to set exported attributes without explaining the security implications, that guidance created the conditions for this vulnerability to persist.
Framework and Compliance Mapping
| Framework | Relevant Control | Application |
|---|---|---|
| NIST CSF 2.0 | ID.AM-2 (software inventory) | SBOM for mobile apps, SDK tracking |
| CIS Controls v8 | Control 2 (Inventory of SW assets) | SDK version enforcement |
| OWASP Mobile Top 10 | M8 (Security Misconfiguration) | Exported component review |
| ISO 27001:2022 | A.8.26 (Application security requirements) | Third-party library vetting |
| GDPR / PCI DSS | Data minimization, access control | Wallet data in Intents, token exposure |
For organizations under PCI DSS, the exposure of payment-adjacent data through Intent redirection is a direct compliance concern. Transaction metadata and auth tokens captured from wallet Intents could constitute cardholder data depending on implementation — worth a conversation with your QSA.
Key Takeaways
- Audit your Android app portfolio immediately for EngageLab SDK versions prior to 5.2.1 using APK decompilation and manifest inspection.
- Update to EngageLab SDK v5.2.1 or later and ship updated builds to the Play Store; users on older versions remain exposed until they update.
- Review all exported component declarations in your AndroidManifest.xml — not just those from EngageLab, but across your full component surface.
- Implement SBOM tracking for mobile apps so you can identify SDK-level vulnerabilities in your portfolio within hours of disclosure, not weeks.
- Add Intent security to your SAST/DAST pipeline — exported component validation and Intent source checking should be standard test cases.
- Brief your compliance and legal team if your app handles wallet data, payment tokens, or authentication parameters, given the PCI DSS and GDPR implications of this exposure class.
Conclusion
The EngageLab vulnerability is not a novel attack class, but its scale — 50 million installs, 30 million crypto wallets, a 9.3 CVSSv3 score — makes it a useful forcing function for security teams to reassess how they handle third-party mobile SDK risk. The seven-month gap between Microsoft's initial disclosure in April 2025 and the November 2025 patch release is also a reminder that responsible disclosure timelines in the SDK ecosystem can be long, and that defenders cannot rely on patch availability as their primary control.
The practical next step is a mobile app inventory audit this week. Pull your production APKs, run manifest and dependency analysis, and establish a baseline SBOM for your Android app portfolio. That baseline will pay dividends not just for this vulnerability, but for every SDK-level disclosure that follows — and there will be more.
Frequently Asked Questions
What does intent redirection actually allow an attacker to do? A malicious app installed on the same device can send crafted Intents to the vulnerable exported SDK component, intercept Intents in transit, or redirect data to itself. In the context of wallet applications, this means the attacker's app could capture wallet addresses, transaction parameters, or auth tokens that were supposed to stay within the legitimate app's process.
Do users need to install a specific malicious app for this to work, or is it a remote exploit? This is a local, on-device exploit. The attacker needs a malicious app installed on the same Android device as the vulnerable wallet or EngageLab-integrated app. It cannot be exploited remotely over the network. That said, Android malware delivered through sideloading, malicious ad networks, or compromised Play Store apps could serve as the malicious co-installer.
Our developers used EngageLab for push notifications only. Are we still affected? Potentially yes. The exported components that create the vulnerability are part of the SDK's base integration, not necessarily tied to specific features your developers implemented. If you integrated EngageLab at any level in versions prior to 5.2.1, you should audit your manifest and update the SDK.
Google removed the affected apps from the Play Store. Does that mean affected users are protected? No. Removal from the Play Store prevents new installs but does nothing for the 50 million devices that already have a vulnerable version installed. Users are protected only when developers ship updated builds using the patched SDK and users install those updates. This is why Play Store removal is a containment action, not a remediation.
How do we prevent this class of vulnerability in future SDK integrations? Integrate mobile SAST into your CI/CD pipeline with rules that flag exported component declarations and flag SDK dependencies without version pinning. Require an SBOM for every mobile release. Establish a process for monitoring CVE and vendor advisory feeds for SDKs in your dependency tree — the EngageLab advisory was available via Microsoft's MSRC blog and could have triggered an internal response the day it was published.
Enjoyed this article?
Subscribe for more cybersecurity insights.