OWASP Mobile Application Security Testing Guide: MASTG KNOW 0005

---
masvs_category: MASVS-CODE
platform: android
title: Memory Corruption Bugs
---

Android applications typically run within a managed environment where many traditional [memory corruption](../../../Document/0x04h-Testing-Code-Quality.md#memory-corruption-bugs) risks are mitigated by design. The Android Runtime (ART) and Java Virtual Machine handle memory management and enforce type safety, which largely prevents issues such as buffer overflows, out-of-bounds writes, and use-after-free conditions. Applications written in memory-safe languages such as Java or Kotlin are therefore inherently less exposed to these classes of vulnerabilities.

However, these protections do not extend to all components. Memory corruption bugs can still occur in native layers that use the Java Native Interface (JNI) or the Android Native Development Kit (NDK). SDKs and libraries written in C or C++ operate outside the managed memory model and remain susceptible to traditional memory safety issues. For example, [CVE-2018-9522](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9522 "CVE in StatsLogEventWrapper") involved a serialization vulnerability in Android's Parcel implementation, while the Stagefright multimedia framework exploit demonstrated at [BlackHat](https://www.blackhat.com/docs/us-15/materials/us-15-Drake-Stagefright-Scary-Code-In-The-Heart-Of-Android.pdf "Stagefright") showcased memory corruption in a native system component.

Memory leaks are another common concern. These often occur when references to the `Context` object or `Activity` instances are inadvertently retained by non-`Activity` or helper classes, preventing proper garbage collection and leading to resource exhaustion or performance degradation.

> **Why doesn't the OWASP MASTG have tests for this anymore?**
>
> The tests for memory corruption vulnerabilities were removed from the OWASP MASTG because these issues are best addressed during development rather than through black box penetration testing. Memory corruption flaws such as buffer overflows, out-of-bounds access, integer overflows, use-after-free, and format string vulnerabilities should typically be identified **by developers during the development process** through static or dynamic code analysis, compiler protections, and secure coding practices. See the [best practices defined by Android](https://developer.android.com/privacy-and-security/risks/use-of-native-code).
>
> Detecting these flaws in compiled mobile applications is highly complex and unreliable without access to source code or debug symbols. Moreover, modern mobile platforms implement robust memory safety features, including address space layout randomization (ASLR), stack canaries, and runtime protections that significantly reduce the exploitability of such bugs.
>
> OWASP now prioritizes proactive prevention through secure development and automated analysis rather than manual runtime testing. The [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/model/) and [NIST Special Publication (SP) 800-218, Secure Software Development Framework (SSDF)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf) provide structured guidance for integrating security into the development lifecycle, ensuring that developers run the necessary tools and checks to detect and mitigate memory safety issues early through proper coding standards, compiler configurations, and continuous security testing.