I Scanned 10 Popular F-Droid Apps With My Security Scanner — Open Source Secure

"It's open source, so it's secure."

I hear this all the time. The idea is simple: if the code is public, someone must have reviewed it. Vulnerabilities would be caught. The community would fix them.

I decided to test this assumption with real data.

I took 10 popular open-source Android apps from F-Droid — apps that millions of people use every day — and ran them through my static analysis security scanner. Then I manually verified every single finding against the decompiled APK code.

The result: 60 confirmed vulnerabilities across 10 apps.

The Apps

I intentionally picked well-known, actively maintained apps across different categories:

• AntennaPod — Podcast manager
• Bitcoin Wallet — Cryptocurrency wallet
• DAVx5 — CalDAV/CardDAV sync
• GnuCash Android — Financial accounting
• K-9 Mail — Email client
• KeePassDX — Password manager
• NewPipe — YouTube frontend
• Nextcloud — Cloud storage client
• Signal — Encrypted messenger
• VLC — Media player

These aren't abandoned side projects. They're mature, popular apps with active developer communities. Some of them handle extremely sensitive data — passwords, cryptocurrency, private messages, financial records.

Methodology

For each app I:

1. Downloaded the APK from F-Droid
2. Ran my static analysis scanner (automated SAST covering manifest analysis, smali code analysis, native library inspection, taint analysis, and cryptographic checks)
3. Decompiled the APK using apktool to get the smali code, manifest, and resources
4. Manually verified every finding against the actual decompiled code — checking whether the flagged code was truly vulnerable or a false positive

This last step is critical. Automated scanners generate a lot of candidates. Without manual verification, you don't know what's real and what's noise.

What I Found: The 5 Most Common Vulnerabilities

After manually verifying all findings across 10 apps, clear patterns emerged. The same mistakes appeared again and again — regardless of the app's popularity or the sensitivity of the data it handles.

1. Exported Components Without Permission Guards

Found in: 9 out of 10 apps

Android components (activities, services, receivers, content providers) that are declared as exported="true" without requiring any permission to interact with them. This means any app installed on the same device can launch these components, send them data, or receive data from them.

What makes this dangerous: in a financial app, this could mean a malicious app can launch the "send money" screen. In a password manager, it could trigger the database unlock flow. In an email client, it could launch the compose screen with pre-filled data.

The fix is straightforward — either set exported="false" for components that don't need external access, or add an android:permission attribute to restrict who can interact with them.

2. Overly Broad FileProvider Paths

Found in: 4 out of 10 apps

Android's FileProvider is designed to securely share files between apps. But when the provider's path configuration includes <root-path path="." /> or <external-path path="." />, it effectively grants access to the entire filesystem or all of external storage through content URIs.

I found apps where the FileProvider configuration would allow access to /storage/ (all external storage), the entire app internal directory, and in the worst case, the entire device filesystem.

Even though these providers are typically non-exported, they use grantUriPermissions="true" — so if any exported activity forwards URI permissions (a common Android pattern), the broad paths become exploitable.

3. Cleartext Traffic Permitted + User CA Trust

Found in: 6 out of 10 apps

Many apps had cleartextTrafficPermitted="true" in their network security config, allowing unencrypted HTTP connections. Several also explicitly trusted user-installed CA certificates with <certificates src="user" />.

For apps connecting to self-hosted servers (CalDAV, email, cloud storage), this is partially intentional — users need to connect to their own servers, which may use HTTP or self-signed certificates. But the configuration applies globally, not just to self-hosted endpoints. Every connection the app makes — including API calls, analytics, update checks — defaults to allowing interception.

One particularly concerning case: a media player downloaded update files over plaintext HTTP. A man-in-the-middle attacker on the same network could serve a malicious APK as a legitimate update.

4. Weak Cryptographic Implementations

Found in: 3 out of 10 apps

These ranged from the dangerous to the archaic:

• SSL validation completely disabled — one app called a method that literally accepts ALL certificates without any validation. In a financial app. Handling real money.
• ECB cipher mode — a media player's remote access feature used AES in ECB mode, where identical plaintext blocks produce identical ciphertext blocks. This is a textbook crypto mistake.
• java.util.Random in cryptographic context — instead of SecureRandom, making the output predictable.
• Trust-On-First-Use (TOFU) without pinning — once a server certificate is accepted, it's trusted forever, even if the certificate changes (which could indicate a MITM attack).

5. Missing Tapjacking (Overlay Attack) Protection

Found in: 8 out of 10 apps

Almost none of the apps set filterTouchesWhenObscured="true" on sensitive UI elements. This means a malicious app with overlay permission could draw an invisible layer on top of the app and capture user taps — or trick users into tapping buttons they didn't intend to.

This is especially concerning for:

• Password managers (capturing master password input)
• Cryptocurrency wallets (confirming transactions)
• Certificate trust dialogs (accepting malicious certificates)
• OAuth/login screens (authorizing access)

What This Means

Open source doesn't automatically mean secure. It means the code is available for review — not that it has been reviewed. These are popular, well-maintained apps with active communities, and they still have security issues that a systematic review can catch.

This isn't about shaming developers. Open-source maintainers are often volunteers doing incredible work. The point is that security requires dedicated, focused attention. It's a different skill set from building features, and it benefits from dedicated tooling and expertise.

If your Android app handles sensitive data — financial information, credentials, personal communications, health data — it deserves a security review. Not just an automated scan that generates hundreds of candidates and calls it a day, but a proper assessment where every finding is verified and contextualized.

Key Takeaways

1. Automated scanners find candidates, not confirmed vulnerabilities. Without manual verification, you don't know what's real.

2. The same 5 vulnerability patterns appear across almost every app. Exported components, broad file providers, cleartext traffic, weak crypto, and missing overlay protection. These are low-hanging fruit that any security review should catch.

3. Context matters enormously. Cleartext traffic in a media player streaming public videos is a different risk than cleartext traffic in a banking app. A security finding without context is just a line in a report.

4. Open source enables security review — it doesn't replace it. The code being public is a prerequisite for thorough analysis, not a guarantee that the analysis has happened.

I'm a mobile security researcher specializing in Android application security assessments. If you'd like to discuss your app's security posture, feel free to reach out at yehor.mamaiev@gmail.com.