CVE-2026-34078 is a critical (CVSS 10.0) sandbox escape in Flatpak before 1.16.4. A Flatpak app can use symlinks in the portal's sandbox-expose options to reach host files and gain code execution on the host. Update to 1.16.4 or your distribution's patched build.
What's affected
The project's advisory (GHSA-cc2q-qc34-jprg) lists Flatpak versions below 1.16.4 as affected and says the issue is patched in 1.16.4. It adds that the fix will also come in the upcoming 1.18.0 release.
The advisory's impact statement is blunt: every Flatpak app can read and write arbitrary files on the host and execute code in the host context. The cause is in the Flatpak portal, which accepts paths in the sandbox-expose options. Those paths can be symlinks that an app controls and that point anywhere. When flatpak run mounts the resolved host path into the sandbox, the app gets access to files it was never meant to see.
Red Hat lists errata for this CVE, including RHSA-2026:21755. Linux distributions often backport fixes without moving to a new upstream number, so a distribution package that reads as older than 1.16.4 may still be fixed. Check the distribution advisory for your release.
How to check if you're exposed
Read the installed version:
flatpak --version
If it reads 1.16.4 or higher, you have the upstream fix. If it reads lower, look at the package changelog for the CVE id, since a backport is common:
rpm -q --changelog flatpak | grep CVE-2026-34078
On Debian or Ubuntu use apt changelog flatpak and search for the same id.
To see how much is at stake, list the apps installed on the machine and where they come from:
flatpak list --app --columns=application,origin
The risk comes from running apps you do not fully trust. An app from a verified, well-known publisher is less likely to try the escape than one from an unknown source, though the advisory does not draw that line for you.
On shared desktops and developer laptops, ask your endpoint inventory which machines have Flatpak at all. Many are installed by default on desktop Linux distributions, and people forget they are there.
To see which apps could attempt an escape, look at where they come from and what they ask for:
flatpak remotes
flatpak info --show-permissions org.example.App
Replace the app id with one from your list. Apps that ask for broad filesystem access already hold wide rights, so the escape adds less for them, but it matters a lot for apps that were supposed to be tightly confined.
If you applied the advisory's mitigation, check that the portal service is masked and stopped:
systemctl --user status flatpak-portal.service
Then open the apps your users depend on and confirm they still work. The advisory warns that disabling the portal can leave some apps misbehaving, so test before you roll it out widely.
What to do now
- Find the Linux desktops and servers that have Flatpak installed.
- Update Flatpak to 1.16.4 or later, or install your distribution's patched package.
- Check the package changelog to confirm the CVE id is listed if the version number is lower than 1.16.4.
- Remove Flatpak apps you do not use or recognize.
- If you cannot update at once, consider the advisory's mitigation below, and test that your required apps still work.
- Restrict installation of apps from unverified remotes on managed machines.
- Review which Flatpak remotes are configured on managed machines and remove those you do not recognize.
Why it matters
The record lists CWE-59 (improper link resolution before file access) and CWE-61 (UNIX symbolic link following). The idea is old and well understood: a privileged component trusts a path from a less trusted party, follows a symlink the party controls, and ends up operating on a file the party should not reach.
What makes this one serious is where it happens. A sandbox exists to contain an app that turns out to be hostile or compromised. When the sandbox boundary leaks, every app on the machine becomes a way into the host user's files and, per the advisory, a path to code execution there. The CVSS vector shows changed scope for that reason.
The advisory also describes a mitigation: disable the Flatpak portal. It warns that this can leave some apps misbehaving. The commands given are:
sudo systemctl --global mask flatpak-portal.service && systemctl --user stop flatpak-portal.service
Use it as a stopgap, and plan to update. The record does not mark this CVE as exploited, and it is not on the CISA KEV list.
There is a practical way to think about priority. The flaw does not let a remote stranger in by itself. It lets a program that already runs on the machine, inside a sandbox, step outside it. So the people most at risk are those who install apps from sources they do not know, and machines where several users or teams install their own apps.
That reads as less urgent than a remote bug, but the CVSS score of 10.0 reflects how complete the escape is: host files, read and write, and code execution in the host context. A sandbox is a promise to the user that an app cannot do certain things. When the promise breaks across every app at once, the fix is worth doing quickly.
Linux desktop teams should also use this moment to look at their app sources. Allow apps from the vetted remotes you choose, remove stale apps, and keep the update channel working. Sandboxing is one layer, and the other layers are who you let install what.
Quick check
My distribution ships Flatpak 1.14. Am I exposed?
The version number alone does not tell you. Distributions backport fixes, so check the package changelog or the vendor advisory for CVE-2026-34078.
Sources
Last reviewed: 19 October 2026.
