Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. Prior to version 1.18.1, on systems where at least one OCI remote is configured (most common on Fedora systems), a malicious local user in an active local session could use a crafted architecture name to trick the flatpak-system-helper process into creating a root-owned directory tree with contents determined by the OCI remote, plus a root-owned lock file and icons directory, outside the intended root directory. If this vulnerability is combined with other vulnerabilities also fixed in 1.18.1, the combination can lead to local root privilege escalation. This particular vulnerability is not believed to be exploitable if there are no OCI remotes configured (common on non-Fedora systems). Version 1.18.1 patches the issue.

Flatpak's process ID namespace separation does not prevent a sandboxed app's kill(0, signal) or killpg(0, signal) calls from reaching processes outside the sandbox that share the same process group. A malicious or compromised Flatpak app can use this to cause denial of service by terminating processes outside its sandbox, such as the desktop shell.

GHSA-f3p8-vr7v-gxf2 (https://github.com/flatpak/flatpak/security/advisories/GHSA-f3p8-vr7v-gxf2)

Description: If a sandboxed app calls kill(0, signal) or killpg(0, signal), process ID namespace separation does not prevent the signal from being received by every process in the current process group, even though some of those processes are outside the process ID namespace. A malicious or compromised Flatpak app can cause denial of service by terminating processes outside its sandbox. For example, when running under GNOME Shell, the Flatpak app can terminate the shell, causing the desktop session to end. If processes in the same process group take an unsafe action on receiving a signal (e.g. SIGUSR1 puts them into a mode that exposes additional attack surface), a malicious or compromised app could trigger this.

Mitigation: Run Flatpak apps in a new session (setsid flatpak run ...) or a new process group (setpgid(0, 0) in the parent), or avoid running untrusted Flatpak apps. Patched in 1.18.4 by commit a3cf27b5 ("common: Put each bubblewrap child process in its own process group"). Credit: Reported by Guthrie Armstrong, Coalition, Inc.

Flatpak passes through arbitrary vendor-extension keys unmodified when exporting an application's Desktop Entry (.desktop) and D-Bus Service (.service) files, instead of validating against an allowlist. A malicious Flatpak app can use this to cause denial of service (e.g. forced application restart loops) or to influence host D-Bus/systemd activation behavior beyond what the sandbox is intended to permit.

GHSA-v64f-hrwr-j4vh (https://github.com/flatpak/flatpak/security/advisories/GHSA-v64f-hrwr-j4vh)

Description: A malicious Flatpak application can influence host system behavior beyond its sandbox by including arbitrary keys in its exported Desktop Entry (.desktop) or D-Bus Service (.service) files. This can lead to denial of service (e.g. X-GNOME-AutoRestart causing unconditional application restarts) or unintended interaction with host services (e.g. SystemdService directing the D-Bus daemon to activate a host systemd unit instead of the sandboxed wrapper). When Flatpak exports these files, it rewrites Exec= to go through the flatpak run wrapper and removes a small denylist of known-dangerous keys, but passes all other keys through unmodified. The fix switches from a denylist to an allowlist, exporting only keys from a curated list of known-safe entries.

Mitigation: Only install applications from trusted sources. Patched in 1.18.4 by commit 33931025 ("dir: Validate Desktop Entry and D-Bus Service"). Credit: Reported by Markus Göllnitz.

Flatpak creates temporary child repository directories under the user cache with world-writable permissions (0777). On multi-user systems with a permissive umask, other local users could read or modify the temporary directory used while installing apps or runtimes, potentially causing installation failures (denial of service); tampered content would fail signature/digest verification rather than being trusted.

GHSA-r9w3-qx54-qvc8 (https://github.com/flatpak/flatpak/security/advisories/GHSA-r9w3-qx54-qvc8)

Description: The child temporary directories allocated under the user cache (/var/tmp/flatpak-cache-) are created with mode 0777. On multi-user systems this could allow other local users to modify the app as it is being installed. This is related to GHSA-7rvf-rqr3-43j4 (CVE-2026-97025) but with a different impact. This is mitigated by a restrictive umask; it is believed to be a denial-of-service risk rather than an integrity threat, because a modified app/runtime would fail its signature or digest check. The flatpak(1) CLI, GNOME Software, and KDE Plasma Discover are believed unaffected since they set umask 022; other software using libflatpak with a permissive umask might be indirectly vulnerable.

Mitigation: Set a umask that does not allow other users to write to the cache directory (e.g. umask 022). Patched in 1.18.4 by commit 011dfae2 ("common: Restrict tmpdir permissions from 0777 to 0755"). Credit: Found by AISLE in cooperation with Red Hat.

Flatpak writes the OCI repository authentication token with world-readable permissions (0644) in the system-helper's cache directory, allowing other local users on a multi-user system to read the token and impersonate the authenticated user against the OCI repository. Only OCI-based sources (e.g. as used by Fedora) are affected; libostree-based sources such as Flathub are not.

GHSA-7rvf-rqr3-43j4 (https://github.com/flatpak/flatpak/security/advisories/GHSA-7rvf-rqr3-43j4)

Description: When downloading apps or runtimes from an OCI repository that requires authentication, the OCI authentication token is written with the default permissions 0644. On multi-user systems this allows other local users to read the token file. This is related to GHSA-r9w3-qx54-qvc8 but with a different impact: unlike that issue, this one is not mitigated by a restrictive umask. libostree repositories such as Flathub are not affected; this only applies to apps, runtimes, or extensions downloaded from an OCI repository (such as those used by Fedora).

Mitigation: No known mitigation other than updating, or using libostree repositories (e.g. Flathub) or unauthenticated/public OCI repositories instead. Patched in 1.18.4 by commit f911bbf0 ("oci: Stop persisting bearer token to child repo on disk"). Credit: Found by AISLE in cooperation with Red Hat.

GHSA-8xgq-v545-vgvf (https://github.com/flatpak/flatpak/security/advisories/GHSA-8xgq-v545-vgvf)

Description: A path traversal vulnerability during app installation could be used by an attacker to overwrite system files. A malicious Flatpak app could arrange for files named "passwd", "group", or "machine-id" on the host system (e.g. /etc/passwd) to be emptied when the app is upgraded, resulting in data loss and loss of access to the system. When installing Flatpak apps system-wide, the file write is done by root. It is not believed to be possible to replace these files with attacker-chosen content. Similarly, a malicious app could arrange for files named "resolv.conf" to be replaced by a symbolic link to /run/host/monitor/resolv.conf, which is unlikely to exist on the host system.

Mitigation: No known mitigation other than updating. Patched in 1.18.4 by commits 01cd7c4b ("dir: Add fd-relative helpers for accessing deploy directories") and cc3ab6ab ("dir: Use fd-relative operations for files/etc during runtime deploy"). The changes overlap with those for GHSA-5p67-xh8x-rq54 (CVE-2026-97023).

A path traversal vulnerability in Flatpak's handling of the files/etc directory during app deployment allows a malicious Flatpak app to cause certain host system files (such as passwd, group, machine-id, or resolv.conf) to be emptied or replaced with a symlink when the app is installed or upgraded. In system-wide installations, the write is performed as root.

A path traversal vulnerability in Flatpak's handling of the export/bin directory during app deployment allows a malicious Flatpak app to cause deletion of attacker-chosen files outside the deployment directory when the app is installed or upgraded. In system-wide installations, the deletion is performed as root.

Flatpak 1.18.4 fixes several security vulnerabilties. <https://github.com/flatpak/flatpak/releases/tag/1.18.4> All older releases should be assumed to be vulnerable. Prevent privileged overwrite of arbitrary files with an empty file or a symlink to /run/host/monitor/resolv.conf when a malicious app is installed (CVE-2026-97024, GHSA-8xgq-v545-vgvf; thanks to Sebastian Wick)

Prevent privileged deletion of arbitrary files when a malicious app is installed (CVE-2026-97023, GHSA-5p67-xh8x-rq54; thanks to Sebastian Wick)

When downloading apps or runtimes from an OCI repository that requires authentication, don't make the authentication token visible to other users (CVE-2026-97025, GHSA-7rvf-rqr3-43j4; thanks to AISLE in cooperation with Red Hat)

Restrict permissions on temporary repository directories in /var/tmp/flatpak-cache- (CVE-2026-97026, GHSA-r9w3-qx54-qvc8; thanks to AISLE in cooperation with Red Hat)

Filter .desktop and D-Bus .service files against an allowlist of fields, preventing denial of service and unintended interactions with host services (CVE-2026-97027, GHSA-v64f-hrwr-j4vh; thanks to Markus Göllnitz)

Prevent apps from sending signals to a process group that includes a parent process outside the app, causing denial of service by killing the desktop environment (CVE-2026-97029, GHSA-f3p8-vr7v-gxf2; thanks to Guthrie Armstrong, Coalition, Inc.)

Older LTS operating system distributions might prefer to backport fixes to an older stable-branch. The 1.16.x branch is no longer supported by upstream and is unlikely to receive new formal releases, but backports of the applicable vulnerability fixes are included in the upstream git repository in the flatpak-1.16.x branch, https://github.com/flatpak/flatpak/commits/flatpak-1.16.x/ (for example those changes should appear in a Debian 13 security update soon).

-- Simon McVittie, Collabora Ltd. / Debian

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)

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.

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 malicious Flatpak extension can probe the host filesystem to determine what files and directories exist at arbitrary paths, and host directory listings can be disclosed to sandboxed applications using the extension. Additionally, unvalidated extension metadata can cause extension content to be mounted at unintended locations inside the sandbox.

By calling org.freedesktop.Flatpak.SystemHelper.CancelPull on another user's pull, the pull is not actually cancelled but removed from internal tracking, making it impossible for the owning user to stop it. Ongoing pulls cannot be stopped.

GHSA-89xm-3m96-w3jg (https://github.com/flatpak/flatpak/security/advisories/GHSA-89xm-3m96-w3jg)

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.

Mitigation: No known mitigation other than updating. Patched in 1.16.4 and 1.18.0. Credit: Asim Viladi Oglu Manizada.

GHSA-w69g-9x8j-7p8f (https://github.com/flatpak/flatpak/security/advisories/GHSA-w69g-9x8j-7p8f)

Description: When Flatpak launches an application, it performs host-side file operations inside extension content directories to set up bind mounts and symlinks, using path-based APIs that follow symlinks without confinement. Since an extension's files directory is entirely controlled by the extension developer, a malicious extension can place symlinks pointing at arbitrary host paths. Flatpak follows symlinks in the extension content when checking for the .ref lock marker file and when iterating mergedirs directories; for mergedirs, the host-side directory listing is reflected into the sandbox as symlinks the application can enumerate, disclosing filenames from arbitrary host directories. Separately, extension metadata fields (directory, subdirsuffix, addldpath, mergedirs) were not validated for path traversal, allowing extension content to be mounted at unintended sandbox locations.

Mitigation: Avoid installing Flatpak extensions from untrusted sources; there is no configuration to disable extension processing without removing the extensions. Fixed in 1.18.1 (backports available for 1.16.x). Reported by @swick.

A malicious user can get read-access to files in the flatpak-system-helper context if a system OCI repository is configured, because the OCI code paths in the system helper follow symlinks when importing OCI images that are under the user's control.

GHSA-2fxp-43j9-pwvc (https://github.com/flatpak/flatpak/security/advisories/GHSA-2fxp-43j9-pwvc)

Description: The OCI code paths in the system helper will follow symlinks when importing OCI images which are under the user's control, allowing a malicious user to get read-access to files in the system-helper context if a system OCI repository is configured.

Mitigation: Remove all OCI system remotes. Patched in 1.16.4 and 1.18.0. Credit: @smcv.

GHSA-q4gr-vc25-57m5 (https://github.com/flatpak/flatpak/security/advisories/GHSA-q4gr-vc25-57m5)

Description: By using the system helper's unprivileged RemoveLocalRef method, an attacker was able to remove the remote ref of the app or runtime. The anti-downgrade check would fail to find the remote ref, and with it the date to check against, allowing an attacker to bypass the check and downgrade apps.

Mitigation: Ensure that Flatpak apps installed system-wide are fully updated before running them. Fixed in 1.18.1 (backports available for 1.16.x). Discovered and reported by BreachX Zero Day Labs, using Typhon AI Mil v2. Contributing Researcher: Vivek Parikh.

GHSA-q4gr-vc25-57m5 (https://github.com/flatpak/flatpak/security/advisories/GHSA-q4gr-vc25-57m5)

Description: By using the system helper's unprivileged RemoveLocalRef method, an attacker was able to remove the remote ref of the app or runtime. The anti-downgrade check would fail to find the remote ref, and with it the date to check against, allowing an attacker to bypass the check and downgrade apps.

Mitigation: Ensure that Flatpak apps installed system-wide are fully updated before running them. Fixed in 1.18.1 (backports available for 1.16.x). Discovered and reported by BreachX Zero Day Labs, using Typhon AI Mil v2. Contributing Researcher: Vivek Parikh.

GHSA-8qxj-x646-phcm (https://github.com/flatpak/flatpak/security/advisories/GHSA-8qxj-x646-phcm)

Impact: If a malicious SDK container declares an extension point with a crafted 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.

Description: flatpak build-init with --sdk-extensions or --base-extensions copies extension files into the build directory. The target path comes from the directory key in the extension point metadata and is resolved using gfileresolverelativepath, which resolves .. components. A malicious extension with directory=../../<path> causes its files to be written outside the build tree. Before copying, the target path is cleaned with flatpakrmrf, so existing files at the traversed path are deleted and replaced with the extension's content.

Related to GHSA-fqx6-vh4p-42cg (CVE-2026-96275); solutions share code. Fixed in 1.18.1 (backports available for 1.16.x). Reported by @swick.

GHSA-jr92-2v97-wgvc (https://github.com/flatpak/flatpak/security/advisories/GHSA-jr92-2v97-wgvc)

Description: The OCI delta stream parser read sizes as guint64 but passed them to GLib I/O and allocation functions expecting gsize (32 bits on 32-bit systems). The silent truncation causes undersized allocations while subsequent operations use the original 64-bit size, leading to heap buffer overflows. On 64-bit systems, gsize and guint64 are the same width, so the truncation does not occur and the issue is not practically exploitable.

Mitigation: Only install applications from trusted OCI registries. Flatpak remotes using the default OSTree transport are not affected. Fixed in 1.18.1 (backports available for 1.16.x). Reported by @swick.

GHSA-jr92-2v97-wgvc (https://github.com/flatpak/flatpak/security/advisories/GHSA-jr92-2v97-wgvc)

Description: The OCI delta stream parser read sizes as guint64 but passed them to GLib I/O and allocation functions expecting gsize (32 bits on 32-bit systems). The silent truncation causes undersized allocations while subsequent operations use the original 64-bit size, leading to heap buffer overflows. On 64-bit systems, gsize and guint64 are the same width, so the truncation does not occur and the issue is not practically exploitable.

Mitigation: Only install applications from trusted OCI registries. Flatpak remotes using the default OSTree transport are not affected. Fixed in 1.18.1 (backports available for 1.16.x). Reported by @swick.

GHSA-8qxj-x646-phcm (https://github.com/flatpak/flatpak/security/advisories/GHSA-8qxj-x646-phcm)

Impact: If a malicious SDK container declares an extension point with a crafted 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.

Description: flatpak build-init with --sdk-extensions or --base-extensions copies extension files into the build directory. The target path comes from the directory key in the extension point metadata and is resolved using gfileresolverelativepath, which resolves .. components. A malicious extension with directory=../../<path> causes its files to be written outside the build tree. Before copying, the target path is cleaned with flatpakrmrf, so existing files at the traversed path are deleted and replaced with the extension's content.

Related to GHSA-fqx6-vh4p-42cg (CVE-2026-96275); solutions share code. Fixed in 1.18.1 (backports available for 1.16.x). Reported by @swick.

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.

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.