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.

On 5/20/26 05:51, Simon McVittie wrote: On Tue, 19 May 2026 at 19:30:42 -0400, Aaron Rainbolt wrote: I wonder if it would be worth proposing a change to whatever system component handles opening files (probably something in Glib, or xdg-utils, haven't researched that deeply yet) It's a general-purpose specification that is designed to be implemented by an unlimited number of packages, some of them desktop-specific:

GLib, and via that, gio(1), xdg-desktop-portal and flatpak-xdg-utils' xdg-open(1) reimplementation some Qt/KDE library (I'm less familiar with the KDE world, so I don't know whether this is done in the Qt layer or somewhere in kdelibs) xdg-utils' xdg-open(1) (the reference implementation of that name) Debian's mailcap package, which translates fd.o MIME handlers into traditional mailcap(5) handlers web browsers like Firefox and Chromium might reimplement it? not sure ...

so any change to how the spec is to be implemented would have to be fd.o consensus and spread across all of those. Honestly, I think the open-ended nature makes it inherently insecure.

Sandboxes should only allow allowlist of file types and make everything else fall back to a safe default. This could be a simple text editor (no IDE support!) for text files, and a hex editor (or an error) for binary files. -- Sincerely, Demi Marie Obenour (she/her/hers)

On Tue, 19 May 2026 at 19:30:42 -0400, Aaron Rainbolt wrote: I wonder if it would be worth proposing a change to whatever system component handles opening files (probably something in Glib, or xdg-utils, haven't researched that deeply yet)

GLib, and via that, gio(1), xdg-desktop-portal and flatpak-xdg-utils' xdg-open(1) reimplementation some Qt/KDE library (I'm less familiar with the KDE world, so I don't know whether this is done in the Qt layer or somewhere in kdelibs) xdg-utils' xdg-open(1) (the reference implementation of that name) Debian's mailcap package, which translates fd.o MIME handlers into traditional mailcap(5) handlers web browsers like Firefox and Chromium might reimplement it? not sure ...

so that handlers cannot be registered for certain "dangerous" file types (i.e. ELF/PE/Mach-O executables, scripts in various languages, etc.)? The only real downside I can see to that is the inability to text editors to register themselves as handlers for script MIME types, and in those instances, the editor can register itself as the handler for another applicable, more generic MIME type (i.e. text/plain), then change its behavior based on the more detailed MIME type of the file after it opens it.

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

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.

https://github.com/flatpak/xdg-dbus-proxy/security/advisories/GHSA-vjp5-hjfm-7677

xdg-desktop-portal's Trash portal is designed to allow sandboxed apps to ask for a file or directory accessible to the app to be moved to the trash.

Similar to CVE-2026-34078 in Flatpak (but less serious), Codean Labs reported that a malicious or compromised Flatpak app could ask the portal to trash a file that it owns, then replace that file with a symlink, exploit a time-of-check/time-of-use mismatch and make the portal trash the target of the symlink on the host system instead.

This is fixed in stable release 1.20.4 and development prerelease 1.21.1.

https://github.com/flatpak/xdg-desktop-portal/security/advisories/GHSA-rqr9-jwwf-wxgj

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.

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

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

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 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 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 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.

Last updated 27 May 2026

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.

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

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 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 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.

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.

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 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 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.

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.

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 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

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

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.