On April 9, 2026, Microsoft's security researchers published an advisory that should have been the top story in every mobile security briefing that week.

They had found an intent redirection vulnerability in EngageLab's EngageSDK, a push-notification SDK integrated into Android apps with more than 50 million combined installations, including over 30 million for third-party cryptocurrency wallets. A malicious app installed on the same device could bypass Android's sandbox, forge intents that the vulnerable SDK would trust as internal, and exfiltrate private app data, authentication tokens, and wallet credentials. Microsoft has not reported any active exploitation in the wild, but the attack path was fully demonstrated, and the affected apps were pulled from Google Play.

The fix had shipped in EngageSDK version 5.2.1 on November 3, 2025. Every app built on an older version, and there were a lot of them, had been shipping that vulnerability to users for months.

Here is the uncomfortable part: the developers of those 50 million-install apps did not write the vulnerable code. They integrated a dependency to save a few weeks of engineering work. When the flaw was disclosed, they had no visibility into it, no way to detect it with their existing tooling, and no option but to wait for the SDK vendor to patch and then ship a new release of their app.

This is SDK security, and it is the fastest-growing, least-understood category of risk in mobile application security today.

The scale problem: what's really inside your mobile app

Most mobile security programs treat the app as if it were the code their team wrote. It is not. By volume, a modern mobile app is mostly third-party code, and by attack surface, it is mostly third-party behavior.

Industry research over the past several years has repeatedly shown that the majority of security debt in modern applications comes from third-party components and the software supply chain, with published estimates ranging well above half. For mobile specifically, a typical app integrates a large number of SDKs, and the third-party share of the codebase tends to dominate the code the team wrote itself. iOS apps often carry more SDKs than Android on average, and the count has grown steadily over the past five years.

Firebase alone, which is Google's analytics, messaging, and auth platform, appears in the vast majority of Android apps and a substantial share of iOS apps. That single dependency typically pulls in several subsidiary components. Add a payment SDK, an ad network, a crash reporter, a fraud-detection library, a deep-linking framework, and two or three attribution vendors, and the "your team's code" portion of the app is a thin layer of glue on top of a stack of third-party machinery.

Meanwhile, supply chain attacks have surged. Multiple industry analyses over the past two years have documented sharp year-on-year increases in cyber incidents traced to supply-chain compromises. Mobile is increasingly part of that picture, not as an afterthought but as a primary target, because a single compromised SDK propagates to every downstream app in a single update cycle.

The core insight for any CISO or Head of Application Security is simple: the attack surface of your mobile app is overwhelmingly composed of code your team did not write and cannot see the source of. That is not an engineering problem. It is a risk-governance problem, and it is the one your current tooling is almost certainly failing to address.

How SDK vulnerabilities expand your attack surface

SDK security starts with a simple fact: every SDK you integrate inherits the trust boundary of the host app. It runs inside the same process, with the same user ID, the same file system access, the same network permissions, and the same cryptographic material. If the SDK misbehaves, the app misbehaves. If the SDK has a vulnerability, the app has a vulnerability.

The specific attack surfaces that SDKs introduce fall into a handful of recurring patterns. We have found variants of all of them in real production apps across banking, fintech, e-commerce, and consumer verticals.

Exported components and intent redirection

Android's inter-process communication is built on intents. An SDK that needs to handle push notifications, deep links, or callbacks will typically declare Activity, BroadcastReceiver, or Service components as exported, meaning other apps on the device can send intents to them directly. SDKs may also be intended for internal use, but bugs or misconfigurations cause them to export components anyway, exposing internal functionality to every other app on the device. The danger compounds when that internal functionality is also overly permissive: a component that was never meant to be reachable from outside, combined with logic that performs sensitive operations without validating its input, is exactly the combination that turns an accidental export into a severe vulnerability.

A 2024 disclosure in the open-source canhub image cropper SDK is a textbook example. The library's CropImageActivity processed inbound intents without validating the customOutputUri parameter, and BitmapUtils.writeBitmapToUri did not check whether the file extension matched the compressFormat. A malicious app on the same device could launch the activity with a crafted URI pointing into the host app's private storage and overwrite arbitrary files, including credential stores like SecureStore.xml, simply by passing the URI as an intent extra:

java

Bundle extras = new Bundle();

Uri.Builder builder = new Uri.Builder();

builder.scheme("file");

builder.authority("");

builder.path("/data/user/0/com.example/cache/DocumentPicker/646fe846-40dd-47a0-9683-c5f799970d1f.jpeg");

Uri uri = builder.build();

extras.putParcelable("CROP_IMAGE_EXTRA_SOURCE", uri);

builder.path("/data/user/0/com.example/shared_prefs/SecureStore.xml");

Uri uri2 = builder.build();

CropImageOptions opt = new CropImageOptions();

if (uri2 != null) {

    opt.customOutputUri = uri2;

}

extras.putParcelable("CROP_IMAGE_EXTRA_OPTIONS", opt);

Intent intent = new Intent();

intent.putExtra("CROP_IMAGE_EXTRA_BUNDLE", extras);

intent.setClassName("com.example", "com.canhub.cropper.CropImageActivity");

mStartForResult.launch(intent);

The root cause sits one layer deeper, in the BitmapUtils.writeBitmapToUri function. It accepts the attacker-controlled Uri and writes to it directly, with no validation of the destination path, the file extension, or whether an existing file would be overwritten:

kotlin

fun writeBitmapToUri(

    context: Context,

    bitmap: Bitmap,

    compressFormat: CompressFormat,

    compressQuality: Int,

    customOutputUri: Uri?,

): Uri {

    val newUri = customOutputUri ?: buildUri(context, compressFormat)

    return context.contentResolver.openOutputStream(newUri, WRITE_AND_TRUNCATE).use {

        bitmap.compress(compressFormat, compressQuality, it)

        newUri

    }

}

A check that the file extension matches compressFormat, plus a guard against overwriting existing files outside the SDK's own working directory, would have closed this entire class of attack at the library level. The vulnerability was found by a researcher now on the Oversecured team in a major cryptocurrency app and reported upstream. Any app that exported the activity, deliberately or accidentally, inherited the issue. The affected library is open source and available on GitHub for anyone who wants to verify the behavior.

If that SDK does not validate the source of the intent or sanitize the payload, a malicious app can redirect sensitive operations through the trusted context of the host app. The EngageSDK vulnerability Microsoft disclosed in April 2026 is a textbook example: the SDK's MTCommonActivity processed inbound intents without verifying their origin, allowing a malicious app to obtain content-provider permissions that exposed the host app's private storage.

This is not a rare class of bug. Oversecured's detection categories include "Arbitrary code execution via third-party package contexts" and generic hostname-validation bypass through faulty logic. The second of these was cited by a major social platform's mobile security team as a category of vulnerability their in-house taint analyzer could not catch on its own, precisely because it lives at the framework and third-party-library layer rather than in application code.

Misconfigured WebViews in ad and analytics SDKs

Ad SDKs, in-app browser SDKs, and rich-media analytics SDKs all tend to rely on embedded WebViews. That WebView becomes a privileged execution environment inside the host app's process. If the SDK enables JavaScript, exposes native methods through a JS bridge, allows file access from file URLs, or permits arbitrary origin access to geolocation, any remote content the SDK loads can escalate into the native app.

The consequences range from session-token exfiltration to full remote code execution within the app's sandbox. Documented attacks on Android WebView misconfiguration show that a URL parameter passed from an SDK-generated deep-link directly into a WebView is enough to leak authentication tokens or execute bridge methods, with no user interaction beyond tapping a link.

Insecure deep-link handlers

SDKs frequently add their own URI schemes and intent filters to handle marketing links, password resets, or OAuth callbacks. Each new scheme is a new untrusted entry point into the app. If the handler does not validate the origin, enforce replay protection, or sanitize parameters, an attacker who can deliver a crafted link (via phishing, a malicious app, or a compromised website) can trigger sensitive actions inside the app under the user's identity.

Hardcoded secrets in SDK code

Hardcoded secrets, including cloud-provider keys, analytics tokens, and credentials for embedded LLM APIs, regularly turn up inside SDK wrapper classes. They are visible to anyone who decompiles the APK, so backend resources provisioned to "just the SDK" become resources accessible to the entire internet.

Insecure local storage

SDKs routinely stash user identifiers, device fingerprints, session tokens, and telemetry in SharedPreferences or unencrypted SQLite databases. Forensic recovery on rooted devices repeatedly surfaces these artifacts even when the host app's own storage is properly encrypted.

Excessive permissions and PII over-collection

SDKs often declare broader permissions than their documented functionality requires: location, camera, microphone, external storage, and reading of installed apps. These permissions merge into the host app's manifest and inflate the app's overall permission surface. Analytics and attribution SDKs have also been repeatedly caught collecting device identifiers, precise location, and behavioral data beyond what the host app's privacy policy discloses, which is what brought U.S. Federal Trade Commission (FTC) enforcement down on location-data vendors like X-Mode. 

Payment-SDK cryptography failures

Payment and wallet SDKs are a category of their own, because a single flaw (a weak TLS configuration, unsafe key storage, a flawed certificate pin, or a replay-prone nonce) can expose cardholder data or payment tokens. Under PCI DSS 4.0.1's mobile guidance, third-party payment SDKs must be treated as untrusted by default, and the entire payment flow they mediate falls under the app's compliance scope.

Landmark SDK security incidents (2024 to 2026)

To make this concrete, here are the incidents that define the modern SDK threat landscape. None of these were caused by bad code written in-house. All of them affected thousands to millions of apps that had simply integrated a dependency.

These are not isolated incidents. They are the pattern.

Why traditional SAST can't see SDK vulnerabilities

Here is where mobile app security testing programs typically fail: they are built around tools that cannot analyze the part of the app that matters most.

The dominant category of application security testing, Static Application Security Testing or SAST, was designed for source code. You point the tool at your repository, it parses your code, and it flags issues. That model works for the small portion of the app that your team wrote. It fails for the much larger portion that came from SDKs, because you do not have the source code for a third-party SDK. You have a compiled .aar, a .jar, a .framework, or a .xcframework. Source-only SAST simply cannot look inside.

The Head of CI/CD at one of Europe's largest banks summarized the gap to us bluntly. Their team evaluated multiple commercial tools before choosing Oversecured. The reason: "Other tools look at the code we create. On Android specifically, Oversecured decompiles the entire application, so even if the code is coming from a library or from some dependency, you can see if there is a vulnerability. We have contracts with our SDK vendors, but if there are vulnerabilities in the libraries, we might not know. That was one important factor for me."

Open-source tools like MobSF do scan compiled APKs, which is a meaningful step up from pure source-code SAST, but they rely on pattern matching rather than dataflow analysis. They can tell you that a class exists that looks suspicious. They cannot trace whether attacker-controlled data actually reaches an exploitable sink through the SDK's internal logic. In practice, this produces two failure modes: either false negatives (the tool misses real vulnerabilities because it cannot follow the data flow) or false noise at rates that render the output unusable. Customers we have worked with consistently report very high false-positive rates from MobSF's output, which makes it less a tool and more a prompt to do the analysis yourself.

Commercial mobile SAST tools typically do better than open-source, but most carry a variant of the same limitation. Some require source code on both platforms, which rules out SDK analysis entirely. Others scan the compiled artifact but do not keep their detection rules up to date as SDK ecosystems evolve, so teams run into a predictable pattern: initial scan finds some issues, those get fixed, and the tool stops producing new findings even as the app and its SDKs continue to change. A security engineering lead at a large marketplace app we now work with described this precisely when explaining why they replaced their previous tool: "There were no new findings despite ongoing development." For any program that takes third-party risk seriously, that is not a gap. It is a disqualification.

What proper SDK security analysis actually requires

If traditional SAST can't see SDK code, what does work? The short answer is: analyze the artifact that the user actually installs.

An Android APK or App Bundle contains the complete, compiled, bundled form of every line of code that will run on the user's device: your code and every SDK's code, merged into one executable. Decompiling that artifact back to a readable representation, then running full dataflow and taint analysis across the entire decompiled codebase, is the only way to answer the question "is this app actually exploitable?"

That is the core of what Oversecured does. We accept .apk, .apks, and .aab files directly, with no source code required on Android. We decompile the artifact, build a model of the data flows across every component, and trace attacker-controlled data (from deep links, intents, QR codes, IPC, the local network, SMS, and more) through all of the code, your own and every SDK's, until it either reaches a dangerous sink or provably does not. We do this across 175+ vulnerability categories for Android and 85+ for iOS, covering the full OWASP Mobile Top 10 and substantially beyond it, including the SDK-specific attack surfaces described above.

A few details worth being explicit about:

• Obfuscated SDK code is still analyzable. We scan apps built with ProGuard and R8 routinely. Non-obfuscated builds produce slightly better first-party versus third-party distinction, but obfuscation does not blind the analysis.

• iOS is an honest asymmetry. Our iOS analysis currently requires source code or a Swift build, which means the binary-advantage argument applies most cleanly to Android. We are actively working on iOS binary analysis and the engineering challenges that come with it.

• Framework-level vulnerabilities are first-class. Categories like generic hostname-bypass logic flaws are not bolted on as afterthoughts; they are core detection rules. These are the attack classes that even sophisticated in-house teams cannot maintain rules for without a dedicated third-party team behind the analyzer.

• SDK findings go into the same report as first-party findings. We do not currently partition "your code" from "SDK code" in the UI. Both appear as vulnerabilities in the final report, with full dataflow context, so the security team can triage based on real risk rather than on which GitHub repository the code happens to live in.

This is what mobile application security testing looks like when it is designed around the actual composition of a modern mobile app rather than around the assumption that the app is your source code.

SAST vs DAST for SDK security: where each fits

The SAST vs DAST question matters for SDK security, too. Static analysis of the compiled artifact gets you deep coverage of SDK code. But some SDK behavior only manifests at runtime, particularly ad-network SDKs and dynamic-content loaders that fetch and execute remote content, and the network-layer behaviors that depend on configuration at launch.

This is where Dynamic Application Security Testing (DAST) complements SAST rather than replacing it. A proper mobile DAST runs the app in a controlled environment, exercises its attack surface, and observes what the SDKs actually do: what domains they contact, what data they send, how they interact with the Android OS, and whether they honor consent flags. Each finding is validated at runtime rather than inferred statically, which means the false-positive rate for well-designed mobile DAST tends toward zero, and each finding can include a reproducible proof-of-concept.

The right SDK-security program uses both: SAST for coverage of the full codebase, including SDKs, to find vulnerabilities that could be exploited; DAST for runtime validation of what SDKs actually do in practice. If your current program is SAST-only, or worse, source-SAST-only, you are missing half of the SDK threat model.

Compliance: OWASP MASVS and PCI DSS on third-party code

Regulators and standards bodies have caught up to the SDK problem faster than most application security programs have. The compliance environment now treats SDKs as first-class components that must be inventoried, monitored, and governed.

OWASP MASVS, the Mobile Application Security Verification Standard, codifies the expectation explicitly. MASVS-CODE-5 requires that all third-party components used by the app are identified and checked for known vulnerabilities, with mechanisms to update or remove vulnerable versions. MASVS-CODE-3 requires that the app use only components without known vulnerabilities. Taken together, these push teams toward treating every SDK as a security asset subject to continuous verification.

PCI DSS 4.0.1 makes clear that third-party payment SDKs in mobile apps must be treated as in-scope for the full range of PCI controls (key management, encryption, secure communication, logging, tamper resistance, and regular penetration testing) unless the SDK is strictly isolated from cardholder data, which in practice it rarely is. Similar tightening is visible across NIST's SSDF guidance on third-party components, FTC enforcement against analytics and data-broker SDKs, and GDPR treatment of SDKs as intermediary data processors.

The direction of travel is clear: opacity about third-party code is no longer an acceptable compliance posture. Security programs that cannot produce an SDK inventory, evidence of vulnerability scanning across the compiled artifact, and a documented response process for SDK disclosures are going to find that the compliance gap is widening each year.

Building an SDK security program: practical steps

Closing the SDK security gap does not require rebuilding your application security program from scratch. It requires four shifts.

Maintain a mobile SBOM. Every release of every app should produce a software bill of materials that lists every SDK, every version, every transitive dependency. Without this, you cannot respond to an SDK disclosure. When the next EngageSDK happens, you need to know within minutes whether you are exposed, not days.

Scan the compiled artifact, not just the source. Your SAST must analyze the APK, AAB, or IPA that is actually shipped to users. Source-only analysis fundamentally cannot see SDK code. If your current tool does not accept compiled mobile artifacts as input, that is the gap to close first.

Track SDK CVEs and update cadence. Subscribe to security advisories for every SDK you integrate. Put the top-ten-by-install-base SDKs on a named update cadence: quarterly at minimum, monthly for payment and auth SDKs. For commercial SDKs, treat a vendor's slow patch response as a procurement signal. Many widely used SDKs are open source, where there is no vendor relationship to lean on; in that case, the signal is whether the project is actively maintained, and a stalled repository should drive a decision to fork, replace, or contribute the fix yourself.

Audit SDK permissions and network behavior. Before integrating any new SDK, enumerate every permission it declares, every network endpoint it contacts, every piece of data it collects, and every component it exports. If the SDK vendor cannot produce this documentation on request, that is itself a finding. After integration, validate the SDK's runtime behavior with DAST. What it declares and what it does are often not the same thing.

Set up runtime enforcement. Network Security Config should be configured restrictively and tested. Deep-link handlers should validate the origin. Exported components should be minimized at the app level. A hardened host-app posture limits the blast radius when an SDK does turn out to be vulnerable.

None of these steps is difficult individually. Collectively, they turn SDK security from an invisible risk into a managed one.

Frequently asked questions

Can source-code SAST tools scan third-party SDKs?

No. Source-code SAST tools require access to source, and SDK vendors distribute compiled binaries (.aar, .jar, .framework). Scanning SDK code requires tools that analyze the compiled artifact, the APK, AAB, or IPA, through decompilation and dataflow analysis.

How many SDKs does a typical mobile app contain?

Industry measurements vary widely by app category. Estimates in published research range from a handful of SDKs in minimalist apps to several dozen in ad-heavy or content-rich categories, with iOS often carrying slightly more SDKs than Android on average. Firebase alone appears in the vast majority of Android apps and a substantial share of iOS apps, and typically pulls in additional subsidiary SDKs.

What is the difference between SAST and DAST for mobile SDK security?

SAST analyzes the application's code, including SDK code if the tool supports compiled-artifact analysis, to identify potential vulnerabilities based on how data flows through the program. DAST runs the app in a controlled environment and observes its actual runtime behavior. Both matter for SDK security: SAST provides breadth of coverage, DAST validates what the SDK is really doing at runtime.

How do I respond to a newly disclosed SDK vulnerability like EngageSDK?

You need three things in place before the disclosure: an SBOM that tells you which apps use the affected SDK and at what versions, a scanning capability that can verify whether the vulnerable code path is reachable in your specific integration, and a release process that can ship a patched version of the app quickly. Without the SBOM, the first hours of any disclosure are spent figuring out whether you are exposed at all. And it's worth assuming that many SDK vulnerabilities are disclosed late, partially, or not at all; the program that depends on a clean public CVE feed is a program that will be surprised.

The EngageSDK disclosure is not the last incident of its kind. It is the shape of the mobile threat landscape going forward: opaque dependencies, millions of affected installs, patches that ship on the SDK vendor's schedule rather than yours, and application security programs built around the assumption that the app is the code your team wrote.

That assumption is no longer defensible. The app is mostly code that your team did not write, and the attack surface that matters most is the one inside the SDKs you integrated. The tools, the standards, and the regulatory environment are all adapting to that reality. The question for every Head of Application Security is whether their program is adapting too.

If you want to know what is actually inside your app, every SDK, every exported component, every data flow that crosses a third-party boundary, we can scan your production Android APK and show you. iOS scans are also supported with source code. No source code is required on Android, and the scan takes about 15 minutes. Scan your app for free.