Are F-Droid risks proven or just theoretical?

Meatheadmarty

Have people been compromised by f-droid security issues ever or is this just a theoretical attack vector?

nandohyphen1

Meatheadmarty I've been using F Droid no problem since starting with GrapheneOS. Couldn't be happier with it and there are no security risks for me

de0u

Meatheadmarty The Concorde was numerically the world's safest jet for many years, because it had zero deaths across all of its flights, though there weren't that many (source). Then suddenly it was numerically not at all a safety leader.

We know people break into WhatsApp, but there are billions of WhatsApp users. We know malware makes it into the Google and Apple app stores, but again the user counts are at least low billions. Meta, Apple, and Google have security teams monitoring those stores.

So... does a lack of reports of actual malware on F-Droid mean they've been successful at filtering out malware? Or does it mean not enough people are looking for malware on F-Droid? I don't know.

But, like the Concorde situation, if the F-Droid app counts and user counts are small, there might be a time when it could go from being apparently the safest app store to being apparently the least-safe app store due to a single incident. Comparing large-number phenomena to small-number phenomena in a meaningful way is hard.

Franckienogotobollywood

Meatheadmarty The risk depends on your threat model. If you want to escape the GAFAM then fdroid will be infinitely better.

GrapheneOS

Meatheadmarty It's not a theoretical problem. There have been numerous cases of F-Droid reintroducing vulnerabilities patched by apps and breaking the security of apps. F-Droid also rarely every notices when apps make changes they consider a problem prior to publishing the updates but rather they mark their list of anti-features or patch the app retroactively. It's only when an app very openly does something detected by their basic scanning that they'll deal with it prior to publication. It's a misconception that it provides any protection from app developers since they publish whatever is published by app developers unless they did something like including a closed source library detected by their scans, which can be tested by someone malicious in advance. Multiple F-Droid core developers have also repeatedly covered up vulnerabilities, misled people about how things work and other actions demonstrating it isn't trustworthy.

02673853

de0u We know people break into WhatsApp, but there are billions of WhatsApp users. We know malware makes it into the Google and Apple app stores, but again the user counts are at least low billions. Meta, Apple, and Google have security teams monitoring those stores.

So... does a lack of reports of actual malware on F-Droid mean they've been successful at filtering out malware? Or does it mean not enough people are looking for malware on F-Droid? I don't know.

But, like the Concorde situation, if the F-Droid app counts and user counts are small, there might be a time when it could go from being apparently the safest app store to being apparently the least-safe app store due to a single incident. Comparing large-number phenomena to small-number phenomena in a meaningful way is hard.

I think F-Droid open source requirement deters malicious devs who normally want to hide their malware in some way, esspecially if the found some powerful zero day which could escape the app sandbox.

brookie229

I've been using F-Droid since 2012 on multiple devices (BB10 and Android) and never any problems that I'm aware of but that's just one guy in the ether. Could mean that I'm just lucky, who knows.

avaluedcustomer

Installing software you have not validated yourself, essentially means you are trusting the publisher.

I have not heard of any malware or spyware that was distributed through F-Droid, but there was plenty that Google's validation didn't catch and was installed millions of times from PlayStore.

Would it be easier for someone to do this through F-Droid? Probably yes, but then those people won't consider a distribution channel that covers only a tiny fraction of possible targets.

n3t_admin

02673853 I think F-Droid open source requirement deters malicious devs

it's not about devs and more about supply chain attacks. That's the problematic part. Also, quick reminder: F-Droid is not some sort of av-scanner.

de0u

02673853 I think F-Droid open source requirement deters malicious devs who normally want to hide their malware in some way, esspecially if the found some powerful zero day which could escape the app sandbox.

Open source probably helps to some extent (especially at limiting the deployment on F-Droid of highly-valuable zero-day attacks).

But the xz attack was on open source.

And the repeated waves of npm supply-chain attacks (reported November 2024, May 2025, September 2025) are also on open source.

As were the various Python repository attacks, etc.

I'm generally an advocate of open source, but it isn't a silver bullet (nothing is).

02673853

n3t_admin it's not about devs and more about supply chain attacks.

Yes, this is the most common probelm and the devs of libraries should enforce a lot harder security standards.
But a library manipulation will usually get caught a lot faster and if I am used to waiting a few days or weeks before updating most apps (of course everything vulnerable, like browsers gets its updates quickly)

n3t_admin F-Droid is not some sort of av-scanner.

At least they enforce reproducibility, as far as I know.
So we can be sure that the source code on Github or wherever, is actually the source code of the binary.

n3t_admin

02673853 Yes, this is the most common probelm and the devs of libraries should enforce a lot harder security standards.
But a library manipulation will usually get caught a lot faster and if I am used to waiting a few days or weeks before updating most apps (of course everything vulnerable, like browsers gets its updates quickly)

I think we need to discuss terminology here.

F-Droid is multiple things at the same time:

An app (as in: frontend)
A system (as in: backend/build environment)
A repository (as in: a set of repositories, ties into backend)
(4. technically, also the F-Droid team - as in: the devs).

The problem is, that 1. 2. and 3. all have some sort of design flaws or straight up vulnerabilities.

The last threads I've read on this forum were discussing specifically issues with the repository, where 3rd party repos would be affected by a type of certificate bypass. The main repo/system (the one hosted by F-Droid) would not suffer from the same problems. It suffers from different problems, like signing keys used globally for all apps in 2.
A "library manipulation" wouldn't really get caught by neither 1. or 2., since both systems just provide a backbone for 3. I mean, they also almost leaked their repo access once, but that's a different story.

Now let's get to Nr. 4: the devs don't seem to care about the issues with 1. 2. and 3. at all. So good luck enforcing that.

02673853

n3t_admin The last threads I've read on this forum were discussing specifically issues with the repository, where 3rd party repos would be affected by a type of certificate bypass. The main repo/system (the one hosted by F-Droid) would not suffer from the same problems. It suffers from different problems, like signing keys used globally for all apps in 2.

I can't say something about the certificate bypass, because I don't know the technical details.
But app self signing is possible if the .apk is reproducible:
https://f-droid.org/docs/Security_Model/#app-signing

If someone doesn't agree with F-Droid's default repo manegment, they could creare their own repo and handle this different.

02673853

de0u Open source probably helps to some extent (especially at limiting the deployment on F-Droid of highly-valuable zero-day attacks).

Yes, attackers which such valuable information probably do't want to open source it.

de0u But the xz attack was on open source.

And the repeated waves of npm supply-chain attacks (reported November 2024, May 2025, September 2025) are also on open source.

As were the various Python repository attacks, etc.

I'm generally an advocate of open source, but it isn't a silver bullet (nothing is).

Open Source alone isn't sufficent.
The binaries need to be reproducible (https://f-droid.org/docs/Reproducible_Builds/) and we need independent people that do security audits, maybe with the help of AI we can have a semi automated work flow to scan source code for malicous behavior.

deplored

I trust GOS devs when they say there are more vulnerabilities in the chain of distribution. Is it critical for the every day user? That's for you to decide based on your "threat model". Personally I get everything I can there. If no one uses it, they will have no motivation to fix issues. My philosophy is the faster we get away from Google, the better.

GrapheneOS

02673853 There's no one checking the code in updates for apps in practice. F-Droid certainly isn't doing it despite many people having the misconception they do. There are many cases where many months or even years later they found out an app did something against their policies or which they should have marked with one or more of their anti-feature flags. WireGuard successfully switched to a self-update system and escaped from being bound by F-Droid policies because it was one of the few apps using developer signatures and F-Droid never noticed they very obviously shipped a self-update system. It wasn't hidden, was plainly visible in the manifest/code and was openly announced. F-Droid still didn't notice and it was many months before it was brought up by the developer of the WireGuard app which is the only reason they know about it. F-Droid then stopped distributing it, but the app was already handling updating itself so most users weren't cut off from updates unless they were very far behind such as not updating for a year. It goes to show that F-Droid would not provide any protection against a hidden malicious change when developers can openly ship something like this.

A developer only needs to ship code for downloading, verifying and running code within the context of their app to be able to do whatever they want out-of-band without the app store being involved. If someone notices they added it, there's no indication of that being malicious itself. F-Droid knowingly ships apps doing this including Termux and only has a policy against doing it automatically. An app can add a plugin system and encourage users to use it. This enables apps to ship malicious code out-of-band with F-Droid not being involved. Apps can also violate the F-Droid policy and get away with it in practice, and that has happened repeatedly. There are examples within the repository violating the policy as written right now. F-Droid does not truly review updates to apps anyway, they only do naive scanning, but it's easy for a malicious developer to do things in a way where even if they're caught violating policy, there's no sign of malicious code yet. This means a developer can try to do it with minimal consequences if they were theoretically caught prior to deploying it. They'd likely only be caught later and it wouldn't be possible to know what they did with it in practice.

de0u

02673853 Open Source alone isn't [sufficient].

The binaries need to be reproducible and we need independent people that do security audits, maybe with the help of AI we can have a semi automated work flow to scan source code for [malicious] behavior.

Many open-source maintainers report being buried by a deluge of AI-generated vulnerability hallucinations (source).

Open source is arguably a good idea, but not a silver bullet (and, empirically, lots of bad attacks still happen to open-source projects). Reproducible builds are arguably a good idea, but not a silver bullet (and aren't relevant for a lot of bad attacks). Maybe some day AI security scans would have positive value rather than negative value, but that's not clear at present.

It does seem plausible that a giant increase in human effort on security audits would be good, but at present people who can do that work are rare and expensive.

One thing that end users can do right away is to run fewer apps, and to run apps from higher-quality sources. Another thing end users can do right away is to financially support any open-source apps they use.

n3t_admin

02673853 I am referring to this gigantic thread here, where the issue was apparently with 3rd party repos. App self signing has no effect on the vulnerability.

GrapheneOS

02673853 F-Droid only uses developer signing for a tiny portion of the apps they publish despite it being possible for most. A major problem with the approach is that it means updates end if F-Droid disagrees with anything the developer has done instead of F-Droid often eventually doing the update after removing or changing the code they have an issue with. This means users can be indefinitely cut off from security patches and other important updates. F-Droid is not protecting you from app developers in any significant way, that's a misconception, but they are adding another trusted party and are frequently delaying security updates. You're still trusting F-Droid for the initial install with one of the few apps that's signed by developers in their repositories unless you're verifying that another way after installing and are trusting them to provide important updates unless you're closely monitoring it.

02673853

GrapheneOS F-Droid only uses developer signing for a tiny portion of the apps they publish despite it being possible for most. A major problem with the approach is that it means updates end if F-Droid disagrees with anything the developer has done instead of F-Droid often eventually doing the update after removing or changing the code they have an issue with. This means users can be indefinitely cut off from security patches and other important updates. F-Droid is not protecting you from app developers in any significant way, that's a misconception, but they are adding another trusted party and are frequently delaying security updates. You're still trusting F-Droid for the initial install with one of the few apps that's signed by developers in their repositories unless you're verifying that another way after installing and are trusting them to provide important updates unless you're closely monitoring it.

You are right about this and I would too like to have more developer signed apps on F-Droid.

GrapheneOS There's no one checking the code in updates for apps in practice. F-Droid certainly isn't doing it despite many people having the misconception they do. There are many cases where many months or even years later they found out an app did something against their policies or which they should have marked with one or more of their anti-feature flags. WireGuard successfully switched to a self-update system and escaped from being bound by F-Droid policies because it was one of the few apps using developer signatures and F-Droid never noticed they very obviously shipped a self-update system. It wasn't hidden, was plainly visible in the manifest/code and was openly announced. F-Droid still didn't notice and it was many months before it was brought up by the developer of the WireGuard app which is the only reason they know about it. F-Droid then stopped distributing it, but the app was already handling updating itself so most users weren't cut off from updates unless they were very far behind such as not updating for a year. It goes to show that F-Droid would not provide any protection against a hidden malicious change when developers can openly ship something like this.

I don't expect F-Droid to check all their apps and therefore I am still very careful with critical permissions.
F-Droid shouldn't say that they check all the code, and I don't think that they say it like this.
But what I really appreciate is, that F-Droid encourage and tests reproducible builds, so the "everyone can check the source code and conform that the app is legit" phrase, is actually true for 99% of F-Droid apps.
Outside F-Droid, reproducible builds are very rare.
F-Droid's push for reproducibility is even useful if you don't want to use the F-Droid store, because its also part of their build environment which can be used to publish everywhere.

But the main reason I use F-Droid is not that they offer reproducible builds, but that they are the main app store at the moment if you don't want to use a proprietary system for getting and managing your apps.
The only real alternative to F-Droid is the Aurora store, but its dependent on Google and Amazon controlled backend's.
I believe that centralized (and closed source) control over app distribution is not a good thing, especially cause I live in the EU and if we get unlucky the will pass a law's for chat control and other garbage. If this happens, Google will probably help them enforcing it.

I also want to give credit to F-Droid alternatives like Acresscent and in my opinion more promising: The Zapstore, it seems to have a portfolio comporable to F-Droid. is also federated and unlike F-Droid, it lets the devs sign their apps themself per default.
It also as other nice features but I think this would be to off topic.

GrapheneOS A developer only needs to ship code for downloading, verifying and running code within the context of their app to be able to do whatever they want out-of-band without the app store being involved. If someone notices they added it, there's no indication of that being malicious itself. F-Droid knowingly ships apps doing this including Termux and only has a policy against doing it automatically. An app can add a plugin system and encourage users to use it. This enables apps to ship malicious code out-of-band with F-Droid not being involved. Apps can also violate the F-Droid policy and get away with it in practice, and that has happened repeatedly. There are examples within the repository violating the policy as written right now. F-Droid does not truly review updates to apps anyway, they only do naive scanning, but it's easy for a malicious developer to do things in a way where even if they're caught violating policy, there's no sign of malicious code yet. This means a developer can try to do it with minimal consequences if they were theoretically caught prior to deploying it. They'd likely only be caught later and it wouldn't be possible to know what they did with it in practice.

I don't see this as a problem.
As your mentioned Termux: Its very useful if you want to run a python script or something similar on Android.

Watermelon

GrapheneOS A developer only needs to ship code for downloading, verifying and running code within the context of their app to be able to do whatever they want out-of-band without the app store being involved

We users can block this with your dynamic code loading mitigations :)

GrapheneOS

Watermelon That feature exists to protect apps from themselves, not to stop apps dynamically loading code for malicious purposes. It doesn't block an app including an interpreter and using it to run interpreted code which is not actually native code executed by the CPU. It blocks dynamically loading native code in-memory or from storage via SELinux which cannot be bypassed by an app, so they cannot dynamically run any native code, but they can interpret code. It disables dynamically loading classes in-memory or from storage for the Android Runtime but not in a way that can do more than protecting an app from itself since apps cannot be prevented from interpreting code dynamically in general. On a technical level, it's simply not possible to block apps from interpreting code. Even at a policy enforcement level, it's hard to define what interpreting code actually means and there's very little enforcement even for the iOS App Store. iOS App Store allows interpreters but theoretically limits usage for code downloaded out-of-band via store policy... but not so much in practice. They make many exceptions to this rule and allow it for native code in narrow cases including for web browsers in the EU.

Watermelon

GrapheneOS That feature exists to protect apps from themselves, not to stop apps dynamically loading code for malicious purposes. It doesn't block an app including an interpreter and using it to run interpreted code which is not actually native code executed by the CPU.

Fwiw, the DCL mitigations help increase the belief that the app is what was reviewed by the app store reviewers. If they don't have a good policy against interpreters, and don't check what the included interpreter is capable of, then yeah you're right. It'd be weird if every app suddenly started to include a general-purpose interpreter but they'd have to enforce against this practice