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.

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.

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.

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.

On Tue, 22 Sep 2026 at 22:48:19 +0100, Simon McVittie wrote: On Tue, 11 Aug 2026 at 17:38:45 +0100, Simon McVittie wrote: Fix local root privilege escalation via revokefs symlink path traversal and commit tampering (https://github.com/flatpak/flatpak/security/advisories/GHSA-qrwq-7qwx-q9rp, thanks to Ee Yang) CVE-2026-96808 was allocated for GHSA-qrwq-7qwx-q9rp. Fix fixed-filename writes to arbitrary locations via symlink attack on .ld.so (https://github.com/flatpak/flatpak/security/advisories/GHSA-99wv-m8rp-g58x, thanks to Sebastian Wick) CVE-2026-96807 was allocated for GHSA-99wv-m8rp-g58x.

(Thanks to MITRE CNA-LR for these)

xdg-dbus-proxy 0.1.9 fixes a security vulnerability, CVE-2026-94422: <https://github.com/flatpak/xdg-dbus-proxy/security/advisories/GHSA-2cgv-pwcq-wvpq> <https://github.com/flatpak/xdg-dbus-proxy/releases/tag/0.1.9>

All versions older than 0.1.9 are vulnerable. An incorrect implementation of message filtering in xdg-dbus-proxy versions before 0.1.9 allows an attacker to bypass the intended message filtering on the D-Bus session bus by setting a reply serial number on non-reply messages.

xdg-dbus-proxy was designed to be part of the sandbox boundary for Flatpak, but it is released as a separate project and is sometimes used by other app frameworks such as Firejail.

Impact ======

A malicious or compromised Flatpak app could achieve arbitrary code execution outside its sandbox.

If other app frameworks rely on xdg-dbus-proxy in the same way that Flatpak does, then they will have an equivalent vulnerability until xdg-dbus-proxy is updated.

Patches =======

Fixed in 0.1.9 by commits:

e5702fc "proxy: Don't assume that only returns and errors have a reply-serial" fc027f7 "proxy: Make it clearer which direction messages are going in" e4465a0 "proxy: Only allow replies to go to the correct destination"

Test coverage is provided by commits

4427d5d "tests: Add basic test coverage for reply handling" e7f2f89 "tests: Assert that "replies" of inappropriate types aren't accepted" 78045ce "tests: Assert that forged replies cannot be sent to wrong destination"

Workarounds ===========

Avoid running untrusted Flatpak apps.

Avoid running untrusted apps via other frameworks that use xdg-dbus-proxy.

Credits =======

Reported by @refi64. -- Simon McVittie, Collabora Ltd. / Debian

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.

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)

On Tue, 11 Aug 2026 at 17:52:36 +0100, Simon McVittie wrote: https://github.com/flatpak/xdg-dbus-proxy/security/advisories/GHSA-r7hp-698j-2h6c CVE-2026-93676 has been assigned.

smcv

On Tue, 11 Aug 2026 at 17:38:45 +0100, Simon McVittie wrote: Today's Flatpak 1.18.1 release fixes multiple vulnerabilities.

Fix sandbox escape with full host filesystem read/write access via symlink attack on app data directories (https://github.com/flatpak/flatpak/security/advisories/GHSA-8688-9x26-hhxj, thanks to Ee Yang) CVE-2026-90616 Fix local root privilege escalation via revokefs symlink path traversal and commit tampering (https://github.com/flatpak/flatpak/security/advisories/GHSA-qrwq-7qwx-q9rp, thanks to Ee Yang) CVE ID requested from MITRE, pending request ref. CAN-2026-2052453 Fix arbitrary root write via symlink and path traversal in extra-data extraction (https://github.com/flatpak/flatpak/security/advisories/GHSA-fqx6-vh4p-42cg, thanks to AISLE in cooperation with Red Hat) CVE-2026-96275 Fix arbitrary root write via path traversal in flatpak build-init (https://github.com/flatpak/flatpak/security/advisories/GHSA-8qxj-x646-phcm, thanks to Sebastian Wick) CVE-2026-96276 Fix arbitrary host file read via hardlink path traversal in OCI archive extraction (https://github.com/flatpak/flatpak/security/advisories/GHSA-9rww-v4mm-x4jg, thanks to Sebastian Wick) CVE-2026-96279 Fix path traversal via unvalidated architecture parameter in DeployAppstream (https://github.com/flatpak/flatpak/security/advisories/GHSA-v2gw-v9h5-9q4x, thanks to Yehia Ali Mohamed Ezzat) CVE-2026-92162 Fix buffer overflow in OCI delta stream path names on 32-bit systems (https://github.com/flatpak/flatpak/security/advisories/GHSA-jr92-2v97-wgvc, thanks to Sebastian Wick) CVE-2026-96280 Fix fixed-filename writes to arbitrary locations via symlink attack on .ld.so (https://github.com/flatpak/flatpak/security/advisories/GHSA-99wv-m8rp-g58x, thanks to Sebastian Wick) CVE ID requested from MITRE, pending request ref. CAN-2026-2052452 Fix extension metadata path traversal allowing host filesystem probing and unintended mount locations (https://github.com/flatpak/flatpak/security/advisories/GHSA-w69g-9x8j-7p8f, thanks to Sebastian Wick) CVE-2026-96282 Fix anti-downgrade bypass allowing unprivileged users to downgrade system apps (https://github.com/flatpak/flatpak/security/advisories/GHSA-q4gr-vc25-57m5, thanks to BreachX Zero Day Labs) CVE-2026-96281

Arbitrary read access to files readable by the flatpak or flatpak system user (https://github.com/flatpak/flatpak/security/advisories/GHSA-2fxp-43j9-pwvc) is CVE-2026-96284

Ability to prevent another user's flatpak-system-helper pull from being cancelled (https://github.com/flatpak/flatpak/security/advisories/GHSA-89xm-3m96-w3jg) is CVE-2026-96283 smcv

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.

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.

Last updated 27 May 2026

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

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

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.

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.

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

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