The Log Said Skipping. The Disk Said Otherwise: CVE-2026-68924 in MobSF

A log line is a promise the code makes to whoever is reading later. "Skipping oversized file" says: I saw this, and I did not act on it. An attacker's instinct is to distrust the promise and check whether the next line of code actually keeps it — because a reassuring message in front of a fall-through is worse than no message at all.

CVE-2026-68924 is exactly that: a size check that logged a refusal and then extracted the file anyway.

The target

MobSF unpacks the APK/ZIP archives you hand it so it can analyze their contents. Unpacking attacker-supplied archives is a classic danger zone — zip bombs, path traversal, resource exhaustion — so MobSF has a guard: a per-file ceiling, ZIP_MAX_UNCOMPRESSED_FILE_SIZE, set to 400 MB. Any single entry larger than that is supposed to be left on the floor.

The assumption that broke

In shared_func.py (lines 153–182), the extraction loop checked each entry's uncompressed size, and when an entry was too large it logged Skipping. The problem is what came after the log call: nothing stopped the loop iteration. There was no continue. Execution fell straight through into the extraction code, and the oversized file was written to disk — while the log insisted it had been skipped.

The guard computed the right verdict and then failed to enforce it. The one-word gap between "decide" and "do" was a missing control-flow statement.

Walking the path

The public advisory includes a Python proof of concept that builds a ZIP archive containing a single entry whose uncompressed size (~450 MB) is over the 400 MB ceiling, then submits it through MobSF's upload API. The observable result is the tell:

• The log shows Skipping for the oversized entry.

• The oversized file is nonetheless present on disk after extraction.

That contradiction — the refusal in the log, the artifact on disk — is the whole bug, and it's what makes it cleanly verifiable without guesswork. (I'm pointing at the advisory's PoC rather than reprinting a bomb-builder here; the mechanism is what matters, and the fix below closes it regardless.)

What it actually affected

The impact the advisory claims, and no more:

• Disk exhaustion on the host running MobSF.

• Once the disk fills, subsequent scans can't complete — denial of service.

• On a shared MobSF instance, one user's crafted upload degrades the service for everyone.

The scoring reflects the preconditions honestly: CVSS 4.9, AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H. PR:H matters — you need an account that can upload for analysis. No confidentiality or integrity impact; the damage is availability. This is a resource-exhaustion bug (CWE-400), not a code-execution one, and it's written up as such.

The fix

Make the refusal real. Add the continue so a too-large entry is actually skipped instead of logged-and-extracted:

if uncompressed_size > ZIP_MAX_UNCOMPRESSED_FILE_SIZE:
    logger.warning('Skipping %s ...', name)
    continue   # <- the line that was missing
# ... extraction happens only for entries that passed the check

Fixed in MobSF 4.5.1.

The lesson

Two habits meet in this bug. The defender's habit: trust the log, because the log says the right thing. The attacker's habit: treat the log as a claim to be falsified, and look for the gap between the decision and the action. Guard clauses that compute a verdict but don't return/continue/break on it are a recurring pattern — the check is there to satisfy a reviewer's eye, but control flow walks right past it into the dangerous path.

When you review a size, type, or permission check, don't stop at "is the check present?" Follow the very next statements and confirm the rejected case actually leaves the function or the loop. A check that doesn't change control flow isn't a check.

---

Disclosure

• Reported by @ya3raj.

• Advisory: GHSA-x768-8642-mmq9 · CVE-2026-68924

• Fix: PR #2627, commit 62563ca, release v4.5.1