SDK security in mobile apps: the attack surface your team didn

What it is

An Oversecured guide to third-party SDK risk in Android and iOS apps. It is built on Microsoft's 9 April 2026 advisory about an intent redirection flaw in EngageLab's EngageSDK, a push-notification SDK. The advisory covers apps with more than 50 million combined installs, over 30 million of them in third-party cryptocurrency wallets. Oversecured sells the scanner it recommends, so the tooling comparisons are vendor claims.

How it works

Every SDK runs in the host app's process with the same user ID, file access, network permissions and key material. An SDK component that is exported, by design or by mistake, and trusts its input turns into an entry point for any other app on the device.

• EngageSDK: MTCommonActivity processed inbound intents without checking where they came from. A malicious app on the same device could forge intents the SDK treated as internal and obtain content-provider permissions over the host app's private storage. Microsoft reports no exploitation in the wild, but the attack path was fully demonstrated.
• canhub image cropper (2024 disclosure): CropImageActivity took customOutputUri from the intent without validation. BitmapUtils.writeBitmapToUri then opened that URI with WRITE_AND_TRUNCATE and wrote the bitmap, with no check on destination path, file extension versus compressFormat, or existing files. A crafted file:// URI pointing into the app's shared_prefs overwrote SecureStore.xml. The page shows the full exploit intent. A researcher now at Oversecured found it in a major cryptocurrency app and reported it upstream.

Other recurring SDK surfaces the page lists: WebViews in ad and analytics SDKs (JS bridges, file access), SDK-added deep-link schemes, hardcoded cloud and LLM keys, unencrypted SharedPreferences or SQLite, over-broad manifest permissions, and weak TLS, pinning or nonces in payment SDKs.

Preconditions / Affected

• EngageSDK: any app built on a version before 5.2.1. The fix shipped on 3 November 2025, so affected apps shipped the flaw for months before disclosure. The page says the affected apps were pulled from Google Play.
• canhub: any app that exported CropImageActivity, deliberately or accidentally. The page gives no fixed version.

What to do

• Produce a software bill of materials for every release, covering SDKs, versions and transitive dependencies, so exposure to a disclosure can be answered in minutes.
• Scan the shipped APK, AAB or IPA, not only source. SDKs arrive as .aar, .jar or .framework binaries that source-only SAST cannot read.
• Set an update cadence for SDKs: quarterly at minimum, monthly for payment and auth SDKs. For open-source SDKs, treat a stalled repository as a signal to fork, replace or fix it yourself.
• Before integrating an SDK, list its permissions, network endpoints, collected data and exported components. After integration, check runtime behavior with DAST.
• Harden the host app: restrictive Network Security Config, deep-link origin validation, and as few exported components as possible.
• For the canhub class of bug, the page says an extension-versus-format check plus a guard against overwriting files outside the SDK's working directory would have closed it.
• Standards mapping: MASVS-CODE-5 (identify third-party components and check for known vulnerabilities) and MASVS-CODE-3 (no components with known vulnerabilities). PCI DSS 4.0.1 puts payment SDKs and the flow they mediate in scope.

Caveats

• The "landmark incidents 2024 to 2026" table is missing from the fetched text, so the page's other incidents are not captured here.
• The page's claims that MobSF has very high false-positive rates and that DAST false positives approach zero are anecdotal or unsupported by data.
• Oversecured's iOS analysis needs source code or a Swift build, so binary-level SDK analysis applies to Android only. Its report does not separate first-party from SDK findings.
• The page says SDK flaws are often disclosed late, partially or never, so a CVE feed alone is not enough.