Flatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.14.0 and 1.15.10, a malicious or compromised Flatpak app using persistent directories could access and write files outside of what it would otherwise have access to, which is an attack on integrity and confidentiality.

When persistent=subdir is used in the application permissions (represented as --persist=subdir in the command-line interface), that means that an application which otherwise doesn't have access to the real user home directory will see an empty home directory with a writeable subdirectory subdir. Behind the scenes, this directory is actually a bind mount and the data is stored in the per-application directory as ~/.var/app/$APPID/subdir. This allows existing apps that are not aware of the per-application directory to still work as intended without general home directory access.

However, the application does have write access to the application directory ~/.var/app/$APPID where this directory is stored. If the source directory for the persistent/--persist option is replaced by a symlink, then the next time the application is started, the bind mount will follow the symlink and mount whatever it points to into the sandbox.

Partial protection against this vulnerability can be provided by patching Flatpak using the patches in commits ceec2ffc and 98f79773. However, this leaves a race condition that could be exploited by two instances of a malicious app running in parallel. Closing the race condition requires updating or patching the version of bubblewrap that is used by Flatpak to add the new --bind-fd option using the patch and then patching Flatpak to use it. If Flatpak has been configured at build-time with -Dsystembubblewrap=bwrap (1.15.x) or --with-system-bubblewrap=bwrap (1.14.x or older), or a similar option, then the version of bubblewrap that needs to be patched is a system copy that is distributed separately, typically /usr/bin/bwrap. This configuration is the one that is typically used in Linux distributions. If Flatpak has been configured at build-time with -Dsystembubblewrap= (1.15.x) or with --without-system-bubblewrap (1.14.x or older), then it is the bundled version of bubblewrap that is included with Flatpak that must be patched. This is typically installed as /usr/libexec/flatpak-bwrap. This configuration is the default when building from source code.

For the 1.14.x stable branch, these changes are included in Flatpak 1.14.10. The bundled version of bubblewrap included in this release has been updated to 0.6.3. For the 1.15.x development branch, these changes are included in Flatpak 1.15.10. The bundled version of bubblewrap in this release is a Meson "wrap" subproject, which has been updated to 0.10.0. The 1.12.x and 1.10.x branches will not be updated for this vulnerability. Long-term support OS distributions should backport the individual changes into their versions of Flatpak and bubblewrap, or update to newer versions if their stability policy allows it. As a workaround, avoid using applications using the persistent (--persist) permission.

Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. Versions prior to 1.10.8, 1.12.8, 1.14.4, and 1.15.4 contain a vulnerability similar to CVE-2017-5226, but using the TIOCLINUX ioctl command instead of TIOCSTI. If a Flatpak app is run on a Linux virtual console such as /dev/tty1, it can copy text from the virtual console and paste it into the command buffer, from which the command might be run after the Flatpak app has exited. Ordinary graphical terminal emulators like xterm, gnome-terminal and Konsole are unaffected. This vulnerability is specific to the Linux virtual consoles /dev/tty1, /dev/tty2 and so on. A patch is available in versions 1.10.8, 1.12.8, 1.14.4, and 1.15.4. As a workaround, don't run Flatpak on a Linux virtual console. Flatpak is primarily designed to be used in a Wayland or X11 graphical environment.

If a malicious SDK container declares an extension point with a crafted directory path, and a developer runs flatpak build-init --writable-sdk --sdk-extension with that SDK, attacker-chosen files could be written outside the working directory, since the target path is resolved via a function that allows .. traversal.

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.

Flatpak before 1.0.8, 1.1.x and 1.2.x before 1.2.4, and 1.3.x before 1.3.1 allows a sandbox bypass. Flatpak versions since 0.8.1 address CVE-2017-5226 by using a seccomp filter to prevent sandboxed apps from using the TIOCSTI ioctl, which could otherwise be used to inject commands into the controlling terminal so that they would be executed outside the sandbox after the sandboxed app exits. This fix was incomplete: on 64-bit platforms, the seccomp filter could be bypassed by an ioctl request number that has TIOCSTI in its 32 least significant bits and an arbitrary nonzero value in its 32 most significant bits, which the Linux kernel would treat as equivalent to TIOCSTI.

A malicious or compromised Flatpak repository can write attacker-controlled content to arbitrary locations on the host filesystem via extractextradata(). On system installs, the write happens as root. Two issues combine: files/extra is resolved via path operations that follow symlinks, and blob names from xa.extra-data-sources are not sanitized against .. traversal.

Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. A bug was discovered in the flatpak-portal service that can allow sandboxed applications to execute arbitrary code on the host system (a sandbox escape). This sandbox-escape bug is present in versions from 0.11.4 and before fixed versions 1.8.5 and 1.10.0. The Flatpak portal D-Bus service (flatpak-portal, also known by its D-Bus service name org.freedesktop.portal.Flatpak) allows apps in a Flatpak sandbox to launch their own subprocesses in a new sandbox instance, either with the same security settings as the caller or with more restrictive security settings. For example, this is used in Flatpak-packaged web browsers such as Chromium to launch subprocesses that will process untrusted web content, and give those subprocesses a more restrictive sandbox than the browser itself. In vulnerable versions, the Flatpak portal service passes caller-specified environment variables to non-sandboxed processes on the host system, and in particular to the flatpak run command that is used to launch the new sandbox instance. A malicious or compromised Flatpak app could set environment variables that are trusted by the flatpak run command, and use them to execute arbitrary code that is not in a sandbox. As a workaround, this vulnerability can be mitigated by preventing the flatpak-portal service from starting, but that mitigation will prevent many Flatpak apps from working correctly. This is fixed in versions 1.8.5 and 1.10.0.

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 Linux application sandboxing and distribution framework. Prior to versions 1.12.3 and 1.10.6, Flatpak doesn't properly validate that the permissions displayed to the user for an app at install time match the actual permissions granted to the app at runtime, in the case that there's a null byte in the metadata file of an app. Therefore apps can grant themselves permissions without the consent of the user. Flatpak shows permissions to the user during install by reading them from the "xa.metadata" key in the commit metadata. This cannot contain a null terminator, because it is an untrusted GVariant. Flatpak compares these permissions to the actual metadata, from the "metadata" file to ensure it wasn't lied to. However, the actual metadata contents are loaded in several places where they are read as simple C-style strings. That means that, if the metadata file includes a null terminator, only the content of the file from before the terminator gets compared to xa.metadata. Thus, any permissions that appear in the metadata file after a null terminator are applied at runtime but not shown to the user. So maliciously crafted apps can give themselves hidden permissions. Users who have Flatpaks installed from untrusted sources are at risk in case the Flatpak has a maliciously crafted metadata file, either initially or in an update. This issue is patched in versions 1.12.3 and 1.10.6. As a workaround, users can manually check the permissions of installed apps by checking the metadata file or the xa.metadata key on the commit metadata.

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 system for building, distributing, and running sandboxed desktop applications on Linux. In Flatpack since version 0.9.4 and before version 1.10.2 has a vulnerability in the "file forwarding" feature which can be used by an attacker to gain access to files that would not ordinarily be allowed by the app's permissions. By putting the special tokens @@ and/or @@u in the Exec field of a Flatpak app's .desktop file, a malicious app publisher can trick flatpak into behaving as though the user had chosen to open a target file with their Flatpak app, which automatically makes that file available to the Flatpak app. This is fixed in version 1.10.2. A minimal solution is the first commit "Disallow @@ and @@U usage in desktop files". The follow-up commits "dir: Reserve the whole @@ prefix" and "dir: Refuse to export .desktop files with suspicious uses of @@ tokens" are recommended, but not strictly required. As a workaround, avoid installing Flatpak apps from untrusted sources, or check the contents of the exported .desktop files in exports/share/applications/.desktop (typically ~/.local/share/flatpak/exports/share/applications/.desktop and /var/lib/flatpak/exports/share/applications/.desktop) to make sure that literal filenames do not follow @@ or @@u.

A flaw was discovered that may allow an attacker to escape from the flatpak sandbox via /proc/self/exe.

Upstream Commit: https://github.com/flatpak/flatpak/commit/cd2142888fc4c199723a0dfca1f15ea8788a5483

In Flatpak before 0.8.7, a third-party app repository could include malicious apps that contain files with inappropriate permissions, for example setuid or world-writable. The files are deployed with those permissions, which would let a local attacker run the setuid executable or write to the world-writable location. In the case of the "system helper" component, files deployed as part of the app are owned by root, so in the worst case they could be setuid root.

Flatpak is a Linux application sandboxing and distribution framework. A path traversal vulnerability affects versions of Flatpak prior to 1.12.3 and 1.10.6. flatpak-builder applies finish-args last in the build. At this point the build directory will have the full access that is specified in the manifest, so running flatpak build against it will gain those permissions. Normally this will not be done, so this is not problem. However, if --mirror-screenshots-url is specified, then flatpak-builder will launch flatpak build --nofilesystem=host appstream-utils mirror-screenshots after finalization, which can lead to issues even with the --nofilesystem=host protection. In normal use, the only issue is that these empty directories can be created wherever the user has write permissions. However, a malicious application could replace the appstream-util binary and potentially do something more hostile. This has been resolved in Flatpak 1.12.3 and 1.10.6 by changing the behaviour of --nofilesystem=home and --nofilesystem=host.

In Flatpak before 1.18.1, a malicious sandboxed app can obtain arbitrary read and write access to files on the host, which can be escalated to arbitrary code execution on the host, a different vulnerability than CVE-2026-76925. Flatpak creates a few app data directories (e.g., /var/cache, /var/data, /var/config, and /var/tmp) in every sandbox on every app launch where, in some cases, components of the path are attacker-controlled. Missing symlink protection can redirect the directories. Some of these directories are bind-mounted by Flatpak by passing the path (e.g., /home/user/.var/app/APPID/cache/tmp), which contains attacker-controlled directories (tmp) to bwrap --bind SRC DST. bwrap passes the path on to the kernel, which then follows symlinks. A malicious symlink can point to arbitrary locations on the host and it will become mounted inside the sandbox.

In Flatpak before 1.18.1, the revokefs writer, used by the flatpak-system-helper to receive repository data from unprivileged callers, validated file paths by rejecting literal .. components but did not prevent symlink traversal. A malicious local user in an active local session could obtain two revokefs sessions via the system helper, create a symlink in one session pointing into the other session's directory, and retain a file descriptor through that symlink. This allowed the attacker to modify files belonging to a different revokefs session after they had been validated and imported by the system helper. In particular, an attacker could use this to tamper with ostree commit objects in the system repository after they passed signature verification, enabling root-controlled file writes to attacker-chosen paths and local root privilege escalation.

flatpak-builder is a tool to build flatpaks from source. From 1.4.5 to before 1.4.8, the license-files manifest key takes an array of paths to user defined licence files relative to the source directory of the module. The paths from that array are resolved using gfileresolverelativepath() and validated to stay inside the source directory using two checks - gfilegetrelativepath() which does not resolve symlinks and gfilequeryfiletype() with GFILEQUERYINFONOFOLLOWSYMLINKS which only applies to the final path component. The copy operation runs on host. This can be exploited by using a crafted manifest and/or source to read arbitrary files from the host and capture them into the build output. This vulnerability is fixed in 1.4.8.

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.

GHSA-fqx6-vh4p-42cg (https://github.com/flatpak/flatpak/security/advisories/GHSA-fqx6-vh4p-42cg)

Impact: A malicious or compromised Flatpak repository can write attacker-controlled content to arbitrary locations on the host filesystem. On system installs, the write happens as root.

Description: There are two vulnerabilities in extractextradata. It resolves files/extra inside the checked-out commit tree using GFile path operations, which follow symlinks. If the files entry in the OSTree commit is a symlink (e.g., files -> /tmp), the downloaded extra-data blobs are written at the symlink target instead. Additionally, extractextradata writes downloaded blobs to files/extra/<name> where <name> comes from xa.extra-data-sources in the commit metadata; gfilegetchild resolves .. components, so a name like ../metadata escapes the extra/ directory.

Fixed in 1.18.1 (backports available for 1.16.x). Found by @swick after investigating a report from AISLE in cooperation with Red Hat.

Last updated 27 May 2026

Flatpak xdg-desktop-portal before 1.20.4 and 1.21.x before 1.21.1 allows any Flatpak app to trash any file in the host context via a symlink attack on gfiletrash.

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 system for building, distributing, and running sandboxed desktop applications on Linux. In versions prior to 1.10.8, 1.12.8, 1.14.4, and 1.15.4, if an attacker publishes a Flatpak app with elevated permissions, they can hide those permissions from users of the flatpak(1) command-line interface by setting other permissions to crafted values that contain non-printable control characters such as ESC. A fix is available in versions 1.10.8, 1.12.8, 1.14.4, and 1.15.4. As a workaround, use a GUI like GNOME Software rather than the command-line interface, or only install apps whose maintainers you trust.

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.

In Flatpak before 1.18.1, a malicious sandboxed app can replace ~/.var/app/$appid/.ld.so with a symlink, causing regenerateldcache to write files at an arbitrary location. The filenames and content are not attacker controlled, making this hard to exploit.

A flaw was found in xdg-dbus-proxy. The filtering logic applied to D-Bus broadcast messages does not correctly enforce the configured path, interface, and member restrictions. As a result, a malicious or compromised Flatpak application can intercept broadcast signals on the D-Bus session bus and the AT-SPI bus that should have been filtered out, potentially exposing information from other applications on the bus to an unauthorized sandboxed application.

Upstream advisory: https://github.com/flatpak/xdg-dbus-proxy/security/advisories/GHSA-r7hp-698j-2h6c Affected versions: 0.1.6, 0.1.7 Fixed version: 0.1.8 Upstream CVSS: 3.2 (Low)

Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux.

Chris Williams discovered an issue with how Flatpak mounts persistent directories, which can allow an application using them to access host files.

Advisory: https://github.com/flatpak/flatpak/security/advisories/GHSA-7hgv-f2j8-xw87 Affected: all < 1.14.10, 1.15.x < 1.15.10 Fixed: 1.14.x >= 1.14.10, all >= 1.15.10

Impact ======

A malicious or compromised Flatpak app using persistent directories could read and write files in locations it would not normally have access to, which is an attack on integrity and confidentiality.

Description ===========

When persistent=subdir is used in the application permissions (represented as --persist=subdir in the command-line interface), that means that an application which otherwise doesn't have access to the real user home directory will see an empty home directory with a writeable subdirectory subdir. Behind the scenes, this directory is actually a bind mount and the data is stored in the per-application directory as ~/.var/app/$APPID/subdir. This allows existing apps that are not aware of the per-application directory to still work as intended without general home directory access.

However, the application does have write access to the application directory ~/.var/app/$APPID where this directory is stored. If the source directory for the persistent/--persist option is replaced by a symlink, then the next time the application is started, the bind mount will follow the symlink and mount whatever it points to into the sandbox.

For example, org.mozilla.Thunderbird has persistent=.thunderbird, and is not meant to be able to access ~/.ssh. In this example, % represents a shell prompt on the host system, and $ represents a shell prompt inside the app sandbox.

% flatpak run --command=sh org.mozilla.Thunderbird $ mv ~/.var/app/org.mozilla.Thunderbird/.thunderbird{,.save} $ ln -s ~/.ssh ~/.var/app/org.mozilla.Thunderbird/.thunderbird $ exit % flatpak run --command=sh org.mozilla.Thunderbird $ ls ~/.thunderbird {contents of ~/.ssh/}

Patches =======

This was fixed in Flatpak 1.14.10 (stable release branch) and 1.15.10 (development prerelease branch).

For details of backportable patches suitable for inclusion in LTS distributions, please see <https://github.com/flatpak/flatpak/security/advisories/GHSA-7hgv-f2j8-xw87>.

Fully resolving this vulnerability requires adding a new --bind-fd option to bubblewrap (a sandboxing component used by Flatpak) so that Flatpak can avoid a time-of-check/time-of-use race condition. This feature was added in bubblewrap 0.10.0, but can be backported. More details are available via the link above.

Depending how Flatpak was configured at build time, the version of bubblewrap that needs to be patched might either be separately installed into the PATH (typically /usr/bin/bwrap from an OS vendor package), or a bundled convenience copy that is private to Flatpak (typically installed as /usr/libexec/flatpak-bwrap). The convenience copies that are included in Flatpak versions 1.14.10 and 1.15.10 have been updated to include the necessary feature.

Mitigations ===========

If patching bubblewrap is logistically difficult, a mitigation is to apply only the patch "Don't follow symlinks when mounting persisted directories" to Flatpak, and then avoid running two instances of the same untrusted app at the same time; this should prevent the time-of-check/time-of-use issue from being exploited.

Another mitigation is to avoid installing untrusted apps that have the "persistent" sandboxing parameter set in their metadata, and also avoid using flatpak override --persist ... to add that parameter to untrusted apps.

-- Simon McVittie, Collabora Ltd. / Debian on behalf of the Flatpak maintainers