Flatpak is a Linux application sandboxing and distribution framework. Prior to 1.16.4, the Flatpak portal accepts paths in the sandbox-expose options which can be app-controlled symlinks pointing at arbitrary paths. Flatpak run mounts the resolved host path in the sandbox. This gives apps access to all host files and can be used as a primitive to gain code execution in the host context. This vulnerability is fixed in 1.16.4.
A flaw was found in dbus-proxy/flatpak-proxy.c in Flatpak before 0.8.9, and 0.9.x and 0.10.x before 0.10.3, crafted. D-Bus messages to the host can be used to break out of the sandbox, because whitespace handling in the proxy is not identical to whitespace handling in the daemon.
References: https://github.com/flatpak/flatpak/releases/tag/0.8.9 https://github.com/flatpak/flatpak/releases/tag/0.10.3
Patch: https://github.com/flatpak/flatpak/commit/52346bf187b5a7f1c0fe9075b328b7ad6abe78f6
Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. In versions prior to 1.10.4 and 1.12.0, Flatpak apps with direct access to AFUNIX sockets such as those used by Wayland, Pipewire or pipewire-pulse can trick portals and other host-OS services into treating the Flatpak app as though it was an ordinary, non-sandboxed host-OS process. They can do this by manipulating the VFS using recent mount-related syscalls that are not blocked by Flatpak's denylist seccomp filter, in order to substitute a crafted /.flatpak-info or make that file disappear entirely. Flatpak apps that act as clients for AFUNIX sockets such as those used by Wayland, Pipewire or pipewire-pulse can escalate the privileges that the corresponding services will believe the Flatpak app has. Note that protocols that operate entirely over the D-Bus session bus (user bus), system bus or accessibility bus are not affected by this. This is due to the use of a proxy process xdg-dbus-proxy, whose VFS cannot be manipulated by the Flatpak app, when interacting with these buses. Patches exist for versions 1.10.4 and 1.12.0, and as of time of publication, a patch for version 1.8.2 is being planned. There are no workarounds aside from upgrading to a patched version.
Flatpak is a Linux application sandboxing and distribution framework. Prior to 1.16.4, the caching for ld.so removes outdated cache files without properly checking that the app controlled path to the outdated cache is in the cache directory. This allows Flatpak apps to delete arbitrary files on the host. This vulnerability is fixed in 1.16.4.
Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. in versions before 1.10.9, 1.12.9, 1.14.6, and 1.15.8, a malicious or compromised Flatpak app could execute arbitrary code outside its sandbox. Normally, the --command argument of flatpak run expects to be given a command to run in the specified Flatpak app, optionally along with some arguments. However it is possible to instead pass bwrap arguments to --command=, such as --bind. It's possible to pass an arbitrary commandline to the portal interface org.freedesktop.portal.Background.RequestBackground from within a Flatpak app. When this is converted into a --command and arguments, it achieves the same effect of passing arguments directly to bwrap, and thus can be used for a sandbox escape. The solution is to pass the -- argument to bwrap, which makes it stop processing options. This has been supported since bubblewrap 0.3.0. All supported versions of Flatpak require at least that version of bubblewrap. xdg-desktop-portal version 1.18.4 will mitigate this vulnerability by only allowing Flatpak apps to create .desktop files for commands that do not start with --. The vulnerability is patched in 1.15.8, 1.10.9, 1.12.9, and 1.14.6.
Flatpak is a Linux application sandboxing and distribution framework. Prior to 1.16.4, the Flatpak portal accepts paths in the sandbox-expose options which can be app-controlled symlinks pointing at arbitrary paths. Flatpak run mounts the resolved host path in the sandbox. This gives apps access to all host files and can be used as a primitive to gain code execution in the host context. This vulnerability is fixed in 1.16.4.
A flaw was found in Flatpak. A Time-of-check to time-of-use (TOCTOU) race condition exists in the org.freedesktop.Flatpak.SystemHelper component. This vulnerability occurs because a privileged chmod operation executes before the OSTree repository validation within the Deploy() function. An attacker can exploit this timing window to redirect symlinks to arbitrary files, potentially leading to unauthorized file manipulation or information disclosure.
Flatpak is a Linux application sandboxing and distribution framework. Prior to 1.16.4, the caching for ld.so removes outdated cache files without properly checking that the app controlled path to the outdated cache is in the cache directory. This allows Flatpak apps to delete arbitrary files on the host. This vulnerability is fixed in 1.16.4.
Hi,
Flatpak releases 1.16.4 and 1.17.4 are documented to include 4 security fixes, including one for a critical severity issue. Flatpak releases 1.16.5 and 1.17.5 fix regressions caused by the critical security fix:
https://github.com/flatpak/flatpak/releases
The security page:
https://github.com/flatpak/flatpak/security
lists the 4 security issues as follows (I reversed the order here): CVE-2026-34078: Complete sandbox escape leading to host file access and code execution in the host context GHSA-cc2q-qc34-jprg published yesterday by swick Critical
CVE-2026-34079: Arbitrary file deletion on the host filesystem GHSA-p29x-r292-46pp published yesterday by swick Moderate
Arbitrary read-access to files in the system-helper context GHSA-2fxp-43j9-pwvc published yesterday by swick Low
flatpak-system-helper: cross-user CancelPull orphans another user's ongoing pull GHSA-89xm-3m96-w3jg published yesterday by swick Low Here they are individually:
https://github.com/flatpak/flatpak/security/advisories/GHSA-cc2q-qc34-jprg CVE-2026-34078: Complete sandbox escape leading to host file access and code execution in the host context Critical swick published GHSA-cc2q-qc34-jprg yesterday
Affected versions <1.16.4 Patched versions 1.16.4
Impact
Every Flatpak app is able to read and write arbitrary files on the host and execute code in the host context.
Description
The Flatpak portal accepts paths in the sandbox-expose options which can be app-controlled symlinks pointing at arbitrary paths. Flatpak run mounts the resolved host path in the sandbox. This gives apps access to all host files and can be used as a primitive to gain code execution in the host context.
Patches
The issue has been patched in version 1.16.4 and will be patched in the upcoming version 1.18.0.
Mitigations
Disabling the Flatpak Portal mitigates the issue but can result in misbehaving apps.
sudo systemctl --global mask flatpak-portal.service && systemctl --user stop flatpak-portal.service
Credits
Reported by Codean Labs https://github.com/flatpak/flatpak/security/advisories/GHSA-p29x-r292-46pp CVE-2026-34079: Arbitrary file deletion on the host filesystem Moderate swick published GHSA-p29x-r292-46pp yesterday
Affected versions <1.16.4 Patched versions 1.16.4
Impact
Every Flatpak app is able to delete arbitrary files on the host.
Description
The caching for ld.so removes outdated cache files without properly checking that the app controlled path to the outdated cache is in the cache directory.
Patches
The issue has been patched in version 1.16.4 and will be patched in the upcoming version 1.18.0.
Mitigations
No know mitigation other than updating
Credits
Reported by Codean Labs https://github.com/flatpak/flatpak/security/advisories/GHSA-2fxp-43j9-pwvc Arbitrary read-access to files in the system-helper context Low swick published GHSA-2fxp-43j9-pwvc yesterday
Affected versions <1.16.4 Patched versions 1.16.4
Impact
A malicious user can get read-access to files in the system-helper context if a system OCI repository is configured.
Description
The OCI code paths in the system helper will follow symlinks when importing OCI images which are under the user's control.
Patches
The issue has been patched in version 1.16.4 and will be patched in the upcoming version 1.18.0.
Mitigations
Remove all OCI system remotes.
Credits
@smcv https://github.com/flatpak/flatpak/security/advisories/GHSA-89xm-3m96-w3jg flatpak-system-helper: cross-user CancelPull orphans another user's ongoing pull Low swick published GHSA-89xm-3m96-w3jg yesterday
Affected versions <1.16.4 Patched versions 1.16.4
Impact
Ongoing pulls cannot be stopped.
Description
By calling org.freedesktop.Flatpak.SystemHelper.CancelPull on another user's pull, the pull does not get cancelled but removed from internal tracking, making it impossible to stop it.
Patches
The issue has been patched in version 1.16.4 and will be patched in the upcoming version 1.18.0.
Mitigations
No known mitigation other than updating.
Credits
Asim Viladi Oglu Manizada Alexander
On Thu, 09 Apr 2026 at 02:32:56 +0200, Solar Designer wrote: Arbitrary read-access to files in the system-helper context ... A malicious user can get read-access to files in the system-helper context if a system OCI repository is configured.
smcv
On Mon, 18 May 2026 at 22:01:16 -0400, Aaron Rainbolt wrote: Of these two, org.freedesktop.portal.OpenURI.OpenFile is probably more problematic. This is because access to the OpenURI portal seems to be implicitly allowed by Flatpak. Expanding on what Flatpak intends to allow here:
If all applications followed the xdg-mime manpage's advice to never execute code when opening a file, this wouldn't be that big of a problem. This is where Wine comes in; it ships a desktop file that registers Wine as a MIME handler for 'application/x-ms-dos-executable', 'application/x-msi', and 'application/x-bat'.
Unfortunately, I was able to find another program with an unsafe handler registered just while writing this email (which I intend on reporting privately once I've sent this). So while it seems like these kind of handlers aren't super common, they aren't that hard to find if you dig around for a while.
We're working on a sandboxing system (really a glorified systemd-nspawn frontend) that allows each sandbox to be self-sufficient enough to not need access to the host's D-Bus daemon. [9] That should prevent any possible way to leverage D-Bus as a sandbox escape mechanism.
smcv