Is flatpak's sandboxing insecure?

[bonjour540 (Bonjour Bonjour)]

While I was surfing on the internet, I came across multiple websites that claim that the sandbox of flatpak is insecure as it can be bypassed. Is that true as of 2026?

First website: Flatpak Permissions on Upgrade, Unravelled | Eric Anderson

Claim: Flatpaks can obtain new permission automatically when they are updated. (I am unsure what the “Relatively small beans” section is talking about though"

Note: I am unsure if the claim also applies to permissions that have been manually overriden/disabled via flatseal.

Second website: Flatpak: "home" access allows trivial privilege escalation, what to do instead

Claim (What I have understood at least): D Vitamin said that if Nautilus is installed, and the app has this permission --talk-name=org.freedesktop.FileManager1 , they can call something named “the dbus method of Nautilus” to for example replace the real ~/.bashrc with another bashrc file that the app created. The comment suggests in my opinion at least that this works regardless of the --filesystem=home permission.

Third website: https://flatkill.org/

Claim: It claims the following:

1- Flatpak apps with the --filesystem=home permission can simply just rewrite ~/.bashrc if they want (Although if that is true then it wouldn’t be a major problem for me as I always remove that permission anyways)

2- “Official applications and runtimes are vulnerable to known easily-exploitable code execution vulnerabilities, some of the vulnerabilities have been known (and fixed in distributions but not in flatpak) for half a year.”

3- “Up until 0.8.7 all it took to get root on the host was to install a flatpak package that contains a suid binary (flatpaks are installed to /var/lib/flatpak on your host system). Again, could this be any easier? A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue.”

Finally, I have a question. Using Flatseal (or the terminal if Flatseal has no such feature), Can I remove an app’s permission to access specific files (like for example allow --filesystem=home but exclude ~/.bashrc or exclude important partitions)?

[catanzaro (Michael Catanzaro)]

@bonjour540

While I was surfing on the internet, I came across multiple websites that claim that the sandbox of flatpak is insecure as it can be bypassed. Is that true as of 2026?

Currently there are some significant privately-reported vulnerabilities with a disclosure deadline in early April. You’ll learn about them soon enough.

Those aside, you can assume the sandbox is generally safe. Every once in a while, somebody finds a way to escape the sandbox and reports it. There is a list of past vulnerabilities here.

@bonjour540

First website: Flatpak Permissions on Upgrade, Unravelled | Eric Anderson

Claim: Flatpaks can obtain new permission automatically when they are updated. (I am unsure what the “Relatively small beans” section is talking about though"

Note: I am unsure if the claim also applies to permissions that have been manually overriden/disabled via flatseal.

You know that is true because Eric showed an example of it:

$ flatpak update
Looking for updates…

New org.flatpak.Hello permissions:
    network



        ID                  Branch   Op   Remote          Download
 1.     org.flatpak.Hello   master   u    tutorial-repo   < 647 bytes

Proceed with these changes to the user installation? [Y/n]:

Second website: Flatpak: “home” access allows trivial privilege escalation, what to do instead

Claim (What I have understood at least): D Vitamin said that if Nautilus is installed, and the app has this permission --talk-name=org.freedesktop.FileManager1 , they can call something named “the dbus method of Nautilus” to for example replace the real ~/.bashrc with another bashrc file that the app created. The comment suggests in my opinion at least that this works regardless of the --filesystem=home permission.

This is a sandbox hole, not a sandbox escape. Flatpak’s sandbox is strong by default, but applications are allowed to configure their own permissions (statically, when you install or update them, not at runtime). It’s very common for applications to use permissions that render the sandbox totally meaningless. Granting D-Bus access to nautilus is just one of many possible ways to sabotage the sandbox. I wrote about this here under the heading “Phase Out Most Sandbox Holes (Eventually).”

By default, Flatpak blocks D-Bus access to everything except (a) portal services, and (b) I think also a very small list of services known to be safe?

Third website: https://flatkill.org/

Claim: It claims the following:

1- Flatpak apps with the --filesystem=home permission can simply just rewrite ~/.bashrc if they want (Although if that is true then it wouldn’t be a major problem for me as I always remove that permission anyways)

There’s no point in trying to sandbox an app that uses --filesystem=home and has access to all of your personal files. This would be futile.

2- “Official applications and runtimes are vulnerable to known easily-exploitable code execution vulnerabilities, some of the vulnerabilities have been known (and fixed in distributions but not in flatpak) for half a year.”

I can only suggest investigating the security policies of the applications and runtimes that you use. Flatpak itself cannot possibly be responsible for everything that people do with it, and examples from 2018 are unlikely to be relevant today.

I suspect the security posture of most applications on Flathub is relatively poor, especially if the application has many bundled dependencies. But each app is maintained by different people, and they’ll all have different practices.

Most major runtimes like GNOME, KDE, and freedesktop.org are likely somewhat better, if you stick to supported versions. In general, you can expect major runtimes to update to new software versions relatively quickly. You cannot expect them to patch CVEs. If upstream fixes a CVE but does not create a new release, you’ll probably be vulnerable until the next release.

3- “Up until 0.8.7 all it took to get root on the host was to install a flatpak package that contains a suid binary (flatpaks are installed to /var/lib/flatpak on your host system). Again, could this be any easier? A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue.”

That is true, but it’s also from 2017.

Finally, I have a question. Using Flatseal (or the terminal if Flatseal has no such feature), Can I remove an app’s permission to access specific files (like for example allow --filesystem=home but exclude ~/.bashrc or exclude important partitions)?

I think so? I’m afraid I have never tried.

[bonjour540 (Bonjour Bonjour)]

Thanks for your detailed answer, I truly appreciate it! Also, I have quite liked your article!

[nickeecoco (Nick Karpowicz)]

I’d like to add some detail regarding permissions changing in updates, since an application I develop is on Flathub and I changed the permissions once (actually removing permissions, after I made better use of XDG portals instead).

If there’s a change in permissions, Flathub holds the update for manual review. So there is a check in place; if a maintainer tried to escalate an existing app in terms of –filesystem it would stand out.

[mulanka (Shaun Sutton)]

I would have to say that even if everything is in a sand box environment that of course there could be ways to crack into the sandbox environment to change things. I would have to say though in due to the constraints of the sandbox environment chances of it being tampered with would be allot more lower than if there wasn’t a sandbox environment.