Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
21 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The findiconpathzip() function in MobSF does not properly sanitize the android:icon attribute extracted from an Android manifest before resolving it as a filesystem path. An attacker can supply a malicious android:icon value containing path traversal sequences, causing MobSF to read arbitrary files from the server filesystem and copy them into the downloads directory (DWDDIR). These files can then be retrieved by any authenticated user via the /download/<filename endpoint, provided the file extension is included in ALLOWEDEXTENSIONS. Details https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/iconanalysis.py#L126 This code enables path traversal if a value like 'res/../../../signatures/maltrail-malware-domains.txt' is used as the icon path. This path will resolve to outside the scan directory, and the file will eventually be copied into DWDDIR/<md5-icon.<ext:…
Recommended action: Upgrade to 4.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARECLASSES (ignored since Django 2.0). The active MIDDLEWARE tuple does not include it. All authenticated web POST endpoints (delete scan, upload, download APK, change password, manage users) accept requests without CSRF tokens. Verified Impact This was verified by actually deleting a real scan from the running server using only a session cookie — no CSRF token was required: The scan was removed from the database. This attack works from any website via HTML form auto-submission because: - No CSRF token is validated (middleware absent) - Cookie SameSite=Lax allows form-based top-level navigation to send the session cookie Affected Component Steps to Reproduce 1. Start MobSF v4.4.6 and log in at http://127.0.0.1:8000/login/ (creds: mobsf/mobsf). 2. Upload and scan any APK to create a scan entry. Note the MD5 hash from "Recent Scans". 3. Open the following HTML file in the same browser (simulates visiting…
Recommended action: Upgrade to 4.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MobSF's Android App Link assetlinks checker validates only the manifest android:host value with validhost(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in validhost() and lets a crafted APK cause MobSF to fetch http://host:<attacker-port/.well-known/assetlinks.json or https://host:<attacker-port/.well-known/assetlinks.json. Impact An authenticated user who can upload or trigger analysis of a crafted APK can cause the MobSF server to make an outbound request to an attacker-selected port during Android manifest analysis. When the host is controlled by the attacker and uses DNS rebinding, the validation lookup can resolve to a public IP while the later HTTP client lookup resolves to an internal address, allowing SSRF to internal services on non-80/443 ports. This is not arbitrary URL SSRF. The path remains fixed to /.well-known/assetlinks.json, and redirects are disabled. The bypass…
Recommended action: Upgrade to 4.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIPMAXUNCOMPRESSEDFILESIZE (400 MB) and logs "Skipping" — but the code lacks a continue statement, so extraction proceeds anyway. The log message is misleading; the file is still written to disk. Verified Impact (Code Audit) The vulnerable code path in sharedfunc.py lines 153–182: The control flow is clear: after the size check logs "Skipping", no continue or break is issued. The code proceeds to line 182 which extracts the file unconditionally. Steps to Reproduce 1. Create a ZIP/APK with a file exceeding 400 MB (zeros compress very well): 2. Upload via API: 3. Trigger scan, then verify: Why This Is Not a Self-Bug - This affects any user who scans a maliciously crafted APK - The APK could come from a legitimate-looking package submitted for security review - Matches the pattern of GHSA-c5vg-26p8-q8cr (Zip bomb DoS, affected <=4.3.2) — that advisory fixed the total size limit but this per-file…
Recommended action: Upgrade to 4.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MobSF's readsqlite() function in mobsf/MobSF/utils.py (lines 542-566) uses Python string formatting (%) to construct SQL queries with table names read from a SQLite database's sqlitemaster table. When a security analyst uses MobSF to analyze a malicious mobile application containing a crafted SQLite database, attacker-controlled table names are interpolated directly into SQL queries without parameterization or escaping. This allows an attacker to: 1. Cause Denial of Service -- A malicious table name causes the database viewer to crash, preventing the analyst from viewing ANY data in the SQLite database. A malicious app can use this to hide sensitive data (C2 server URLs, stolen credentials, API keys) from MobSF's analysis. 2. Achieve SQL Injection -- The SELECT FROM query on line 557 is provably injectable via UNION SELECT, allowing attacker-controlled data to be returned in query results. The current code structure (a PRAGMA statement that runs first on line 553) limits…
Recommended action: Upgrade to 4.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Stored Cross-site Scripting (XSS) vulnerability in MobSF's Android manifest analysis allows an attacker to execute arbitrary JavaScript in the context of a victim's browser session by uploading a malicious APK. The android:host attribute from <data android:scheme="androidsecretcode" elements is rendered in HTML reports without sanitization, enabling session hijacking and account takeover. Details When MobSF analyzes an Android APK containing a <data element with android:scheme="androidsecretcode", it extracts the android:host attribute and inserts it directly into the analysis report without HTML escaping. Vulnerable Code Path 1. Data Extraction - mobsf/StaticAnalyzer/views/android/manifestanalysis.py (line 776): 2. Template String Formatting - mobsf/StaticAnalyzer/views/android/manifestanalysis.py (line 806): 3. Template Definition - mobsf/StaticAnalyzer/views/android/kb/androidmanifestdesc.py (line 200): 4. Unsafe Rendering -…
Recommended action: Upgrade to 4.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GET /download/<filename route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWDDIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWDDIR (e.g., .../downloadsbak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak. Details commonprefix compares raw strings, not path components. For: the function returns True, incorrectly treating downloadsbak as inside downloads. Download handler: If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed issafepath then accepts any sibling directory whose absolute path shares the same string prefix. The ../ check does not catch this. Which file types are retrievable: Whatever is allowed by settings.ALLOWEDEXTENSIONS PoC Prereqs: authenticated user; standard install. Assume: Prepare a sibling directory…
Recommended action: Upgrade to 4.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The vulnerability allows any user to overwrite any files available under the account privileges of the running process. Details As part of static analysis, iOS MobSF supports loading and parsing statically linked libraries .a. When parsing such archives, the code extracts the embedded objects to the file system in the working directory of the analysis. The problem is that the current implementation does not prohibit absolute file names inside .a. If an archive item has a name like /abs/path/to/file, the resulting path is constructed as Path(dst) /name; for absolute paths, this leads to a complete substitution of the destination directory: writing occurs directly to the specified absolute directory. the path (outside the working directory). Thus, an authenticated user who uploaded a specially prepared .a, can write arbitrary files to any directory writable by the user of the MobSF process (for example, /tmp, neighboring directories inside ~/.MobSF, etc.). The key reason is…
Recommended action: Upgrade to 4.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for the "SSRF Vulnerability on assetlinkscheck(actname, wellknowns)" vulnerability could potentially be bypassed. Details Since the requests.get() request in the checkurl method is specified as allowredirects=True, if "https://mydomain.com/.well-known/assetlinks.json" returns a 302 redirect, subsequent requests will be sent automatically. If the redirect location is "http://192.168.1.102/user/delete/1", a request will be sent here as well. <img width="610" alt="image" src="https://github.com/MobSF/Mobile-Security-Framework-MobSF/assets/150332295/a8c9630e-3d12-441a-816c-8f5e427a5194" It will be safer to use allowredirects=False. Impact The attacker can cause the server to make a connection to internal-only services within the organization's infrastructure.
Recommended action: Upgrade to 3.9.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerable MobSF Versions: <= v4.3.2 CVSS V4.0 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N) Details: A Stored Cross-Site Scripting (XSS) vulnerability has been identified in MobSF versions ≤ 4.3.2. The vulnerability arises from improper sanitization of user-supplied SVG files during the Android APK analysis workflow. When an Android Studio project contains a malicious SVG file as an app icon (e.g path, /app/src/main/res/mipmap-hdpi/iclauncher.svg), and the project is zipped and uploaded to MobSF, the tool processes and extracts the contents without validating or sanitizing the SVG. Upcon ZIP extraction this icon file is saved by MobSF to: user/.MobSF/downloads/<filename.svg This file becomes publicly accessible via the web interface at: http://127.0.0.1:8081/download/filename.svg If the SVG contains embedded JavaScript (e.g., an XSS payload), accessing this URL via a browser leads to the execution of the script in the context of the MobSF user session,…
Recommended action: Upgrade to 4.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The latest deployed fix for the SSRF vulnerability is through the use of the call validhost(). The code available at lines /ae34f7c055aa64fca58e995b70bc7f19da6ca33a/mobsf/MobSF/utils.py#L907-L957 is vulnerable to SSRF abuse using DNS rebinding technique. PoC The following proof of concept: Yields : Which generate an initlal random url that leverages dns rebinding after 1 time host resolution and remains to that IP for 30 seconds. As you can notice the initial resolution was pointing to 1.1.1.1. The second time the IP was resolved to 127.0.0.1. Such an attack could be adjusted for other IP addresses. Impact The usual impact of Server-side request forgery. Remediation - Avoid the use of socket.gethostbyname() since it issues and DNS query.
Recommended action: Upgrade to 4.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Product: Mobile Security Framework (MobSF) Version: 4.3.0 CWE-ID: CWE-269: Improper Privilege Management CVSS vector v.4.0: 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N) CVSS vector v.3.1: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) Description: MobSF has a functionality of dividing users by roles. This functionality is not efficient, because any registered user can get API Token with all privileges. Impact: Information Disclosure Vulnerable component: Code output component (/sourcecode) Exploitation conditions: authorized user Mitigation: Remove token output in the returned js-script Researcher: Egor Filatov (Positive Technologies) Research Researcher discovered zero-day vulnerability «Local Privilege Escalation» in Mobile Security Framework (MobSF). To reproduce the vulnerability follow the steps below. • A user with minimal privileges is required, so the administrator must create a user account <img width="215" alt="fig1"…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Partial Denial of Service (DoS) Product: MobSF Version: v4.2.9 CWE-ID: CWE-1287: Improper Validation of Specified Type of Input CVSS vector v.4.0: 6.9 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N) CVSS vector v.3.1: 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) Description: DoS in the Scans Results and iOS Dynamic Analyzer functionality Impact: Leveraging this vulnerability would make Scans Results and iOS Dynamic Analyzer pages unavailable. Vulnerable component: urls.py https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/MobSF/urls.py#L401 Exploitation conditions: A malicious application was uploaded to the MobSF. Mitigation: Check the uploaded bundle IDs against the regex. Researcher: Oleg Surnin (Positive Technologies) Research Researcher discovered zero-day vulnerability Partial Denial of Service (DoS) in MobSF in the Scans Results and iOS Dynamic Analyzer functionality. According to Apple's documentation for bundle…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Product: MobSF Version: < 4.3.1 CWE-ID: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CVSS vector v.4.0: 8.5 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N) CVSS vector v.3.1: 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) Description: Stored XSS in the iOS Dynamic Analyzer functionality. Impact: Leveraging this vulnerability would enable performing actions as users, including administrative users. Vulnerable component: dynamicanalysis.html https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/templates/dynamicanalysis/ios/dynamicanalysis.html#L406 Exploitation conditions: A malicious application was uploaded to the Correlium. Mitigation: Use escapeHtml() function on the bundle variable. Researcher: Oleg Surnin (Positive Technologies) Research Researcher discovered zero-day vulnerability Stored Cross-site Scripting (XSS) in MobSF in iOS Dynamic Analyzer functionality. According…
Recommended action: Upgrade to 4.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The application allows users to upload files with scripts in the filename parameter. As a result, a malicious user can upload a script file to the system. When users in the application use the "Diff or Compare" functionality, they are affected by a Stored Cross-Site Scripting vulnerability. Details I found a Stored Cross-Site Scripting vulnerability in the "Diff or Compare" functionality. This issue occurs because the upload functionality allows users to upload files with special characters such as <, , /, and " in the filename. This vulnerability can be mitigated by restricting file uploads to filenames containing only whitelisted characters, such as A-Z, 0-9, and specific special characters permitted by business requirements, like - or . PoC Complete instructions, including specific configuration details, to reproduce the vulnerability. 1. On MobSF version 4.2.8, I clicked on "Unload & Analyze" button. 2. I uploaded zip file as a name test.zip. 3. I used an intercepting…
Recommended action: Upgrade to 4.2.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Upon reviewing the MobSF source code, I identified a flaw in the Static Libraries analysis section. Specifically, during the extraction of .a extension files, the measure intended to prevent Zip Slip attacks is improperly implemented. Since the implemented measure can be bypassed, the vulnerability allows an attacker to extract files to any desired location within the server running MobSF. Details Upon examining lines 183-192 of the mobsf/StaticAnalyzer/views/common/sharedfunc.py file, it is observed that there is a mitigation against Zip Slip attacks implemented as a.decode('utf-8', 'ignore').replace('../', '').replace('..\\', ''). However, this measure can be bypassed using sequences like ....//....//....//. Since the replace operation is not recursive, this sequence is transformed into ../../../ after the replace operation, allowing files to be written to upper directories. <img width="448" alt="image"…
Recommended action: Upgrade to 4.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? An open redirect vulnerability exist in MobSF authentication view. PoC 1. Go to http://127.0.0.1:8000/login/?next=//afine.com in a web browser. 2. Enter credentials and press "Sign In". 3. You will be redirected to afine.com Users who are not using authentication are not impacted. Patches Has the problem been patched? What versions should users upgrade to? Update to MobSF v4.0.5 Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Disable Authentication References Are there any links users can visit to find out more? Fix: https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/fdaad81314f393d324c1ede79627e9d47986c8c8 Reporter Marcin Węgłowski (AFINE Team)
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? SSRF vulnerability in firebase database check logic. The attacker can cause the server to make a connection to internal-only services within the organization’s infrastructure. When malicious app is uploaded to Static analyzer, it is possible to make internal requests. Credits: Oleg Surnin (Positive Technologies). Patches Has the problem been patched? What versions should users upgrade to? v3.9.8 and above Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Code level patch References Are there any links users can visit to find out more? https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/2373
Recommended action: Upgrade to 3.9.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While examining the "App Link assetlinks.json file could not be found" vulnerability detected by MobSF, we, as the Trendyol Application Security team, noticed that a GET request was sent to the "/.well-known/assetlinks.json" endpoint for all hosts written with "android:host". In the AndroidManifest.xml file. Since MobSF does not perform any input validation when extracting the hostnames in "android:host", requests can also be sent to local hostnames. This may cause SSRF vulnerability. Details Example <intent-filter structure in AndroidManifest.xml: We defined it as android:host="192.168.1.102/user/delete/1#". Here, the "#" character at the end of the host prevents requests from being sent to the "/.well-known/assetlinks.json" endpoint and ensures that requests are sent to the endpoint before it. <img width="617" alt="image" src="https://github.com/MobSF/Mobile-Security-Framework-MobSF/assets/150332295/c570cb00-e947-4ad7-af80-26d46c0ad3f7" PoC…
Recommended action: Upgrade to 3.9.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mobile Security Framework (MobSF) <=v3.7.8 Beta is vulnerable to Insecure Permissions. NOTE: the vendor's position is that authentication is intentionally not implemented because the product is not intended for an untrusted network environment. Use cases requiring authentication could, for example, use a reverse proxy server.
Recommended action: Upgrade to 3.9.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mobile Security Framework (MobSF) v0.9.2 and below was discovered to contain a local file inclusion (LFI) vulnerability in the StaticAnalyzer/views.py script. This vulnerability allows attackers to read arbitrary files via a crafted HTTP request.
Recommended action: Upgrade to 0.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.