MobSF 4.5.2: string analysis now flags well-known secret formats

What happened on this date

At 06:20 UTC on 2026-08-10, the Mobile Security Framework (MobSF) published v4.5.2 on GitHub. The listed enhancements: Android certificate analysis now uses apksigner from build-tools 37.0.0 and supports apktool 3.x for more reliable certificate parsing across versions; Android and iOS string analysis now detects high-confidence known secret formats, naming GitHub, Slack, Stripe and OpenAI tokens and PEM keys; the VirusTotal integration moved to API v3 with uploads up to 650MB; and CI and Docker supply-chain hardening such as SBOM attestations and PyPI publishing through OIDC Trusted Publishing. Bug fixes included a CSRF "null origin" error during SAML SSO login and a corrected rule for the mode argument of getSharedPreferences. The notes do not list a separate security-fix section.

Why it matters for people protecting app logic

For developers the most notable change is secret detection. Anyone who scans an APK or IPA with this open-source tool now gets common service tokens and PEM private keys flagged automatically, with no manual string hunting. For the growing number of apps that call LLM APIs directly from the client, an embedded API key is now a default finding. Its limits matter too. It covers only high-confidence known formats, so an empty result does not mean the app holds no secrets, and splitting, encoding or obfuscating a key before reassembling it only hides it from static scanning; at runtime the key still appears in clear form in memory or in network requests. The right response is not to evade the scanner but to stop shipping abusable keys in the client.

Concrete checks

First, run MobSF or an equivalent scanner on your own release APKs and IPAs in CI and make secret findings a blocking result. Second, re-scan versions you have already shipped, and treat any flagged key as leaked and rotate it. Third, route calls to third-party AI and payment services through your own backend, so the client holds only revocable, narrowly scoped session credentials. Fourth, compare the signing certificate details in the scan report with your expected release certificate to catch accidental changes to signing configuration. Keep the scan reports with each release so you can show later what was checked and when.

Your checklist

• Scan your release builds in CI and block on secret findings
• Re-scan shipped versions and rotate every flagged key
• Proxy third-party AI and payment calls through your backend
• Check the reported signing certificate matches your release certificate