MobSF 4.5.3: hardening the scanner itself and a decompiled-XML API

What happened on 2026-09-21

At 02:52 UTC on 2026-09-21, the Mobile Security Framework (MobSF) published v4.5.3 on GitHub. On the feature side, the REST endpoint api/v1/view_source gained type=xml for viewing decompiled Android XML from APK, Android Studio source ZIP and AAR scans. The signature pack was updated, dependencies and supply-chain components were refreshed (including LIEF 0.17), and GitHub Actions were pinned to full commit SHAs. The release notes also list these fixes: a DNS-rebinding SSRF closed by pinning safe server-side HTTP requests; hardened path-traversal checks against Windows root-relative and drive-relative escapes; a bound on androguard's in-memory ZIP member decompression to block zip bombs; a path-traversal fix when resolving iOS Info.plist and CFBundleExecutable paths; CSRF protection for dynamic analysis actions, which now require token-bearing POST requests; plus fixes for apktool PAK extraction and a leaking mitmdump helper process.

What it means for self-assessment workflows

Many independent developers run MobSF on their own APKs or IPAs before release. Most fixes in this version target MobSF itself. An analysis tool has to process untrusted input files, which makes it an attack surface in its own right, and zip bombs, path traversal and SSRF all belong to that category. There is also a risk defenders often overlook: a self-hosted scanning instance stores unreleased builds and scan reports, and those are assets worth protecting. Meanwhile, the new decompiled-XML endpoint is another reminder that manifests and resource XML are routine, programmatically accessible output of analysis workflows. Configuration values, URLs and switches placed in resources should not be considered hidden. Scanner output is a checklist, not proof of security. Whatever it finds, someone else running the same tool can find too.

Checks you can put in place

First, if you self-host MobSF, upgrade to 4.5.3 or later and make sure the instance is not directly exposed to the internet and requires authentication. Second, treat scan reports and uploaded builds as internal material, with retention limits and access control. Third, scan every release candidate in CI. Focus on exported components, debug flags and network security configuration in the manifest, as well as URLs, keys and switches in resource XML. Fourth, diff each scan against the previous release and pay attention to what is new, rather than looking only at the overall score.

Your checklist

• Upgrade self-hosted MobSF to 4.5.3+ and keep it off the public internet
• Apply access control and retention limits to scan reports and uploaded builds
• Scan release candidates in CI and diff results against the previous release