Description

MobSF is a mobile application security testing tool used. Prior to 4.5.1, find_icon_path_zip in mobsf/StaticAnalyzer/views/android/icon_analysis.py uses the Android manifest android:icon value to construct paths under the scan resource directory without rejecting traversal or verifying containment, allowing an authenticated user to upload a crafted ZIP or APK that reads a server file with an ALLOWED_EXTENSIONS suffix, copies it to DWD_DIR as the predictable name -icon., and retrieves it through the /download/ endpoint. The same behavior provides a file-existence oracle through the icon_path report field. This issue is fixed in version 4.5.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-08-18T18:19:27.907Z",
  "pubdate": "2026-08-18T18:19:27.907Z",
  "executiveSummary": "A path traversal vulnerability exists in MobSF prior to version 4.5.1, specifically within the find_icon_path_zip function located in mobsf/StaticAnalyzer/views/android/icon_analysis.py. The flaw arises because the application utilizes the Android manifest android:icon value to construct file paths under the scan resource directory without adequately validating input, rejecting directory traversal sequences, or verifying path containment.\nAn authenticated attacker with the ability to upload a crafted ZIP or APK file can exploit this deficiency to read arbitrary files from the server, provided the target files end with an ALLOWED_EXTENSIONS suffix. The application subsequently copies the targeted file to the DWD_DIR directory using a predictable naming convention (-icon.) and exposes it for retrieval via the /download/ endpoint. Furthermore, the vulnerability exposes a file-existence oracle through the icon_path report field.\nThe risk implications include unauthorized disclosure of sensitive server-side files matching specific extension criteria. Successful exploitation requires an authenticated user session to upload the malicious package and trigger the static analysis workflow, leading directly to unauthorized file read capabilities.",
  "technicalDetails": "The root cause of the vulnerability resides in the insecure handling of the android:icon attribute extracted from the Android manifest during static analysis in MobSF prior to version 4.5.1. The vulnerable component is the find_icon_path_zip function in mobsf/StaticAnalyzer/views/android/icon_analysis.py.\nDuring the static analysis phase of an uploaded mobile application package, the application parses the Android manifest to locate and extract the icon resource path defined by the android:icon attribute. Instead of sanitizing this value to prevent path traversal sequences (such as dot-dot-slash) or enforcing strict containment within the designated scan resource directory, the function directly concatenates the untrusted string into the file path construction logic.\nTo exploit this vulnerability, an authenticated attacker crafts a malicious ZIP archive or APK file containing a manipulated Android manifest. The android:icon attribute is populated with traversal payloads designed to navigate outside the intended working directory and reference sensitive files on the underlying server. Upon uploading this crafted package to MobSF, the static analysis engine processes the manifest and executes the insecure path construction.\nThe payload behavior involves the application attempting to locate the referenced icon file. Because traversal protections are absent, the application accesses the targeted server file, provided it possesses an ALLOWED_EXTENSIONS suffix. Upon successful access, the application copies the sensitive file into the DWD_DIR directory, assigning it a predictable filename formatted as -icon. and making it accessible for download.\nAdditionally, the vulnerability functions as a file-existence oracle. By analyzing the icon_path field returned in the analysis report, an attacker can determine whether specific files exist on the server based on the path resolution outcomes.\nThe attack parameters involve authentication requirements (an authenticated user), privilege requirements (ability to initiate a static analysis scan), and network exposure via the web application interface and the /download/ endpoint where the exfiltrated file can ultimately be retrieved."
}