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.
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, 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.
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 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 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.
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 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.
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 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.
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.
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.
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.
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.
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-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.
A malicious OCI registry can hardlink arbitrary host files into the extraction directory when a user installs or updates a Flatpak application from an OCI remote, allowing disclosure of arbitrary host file contents. For system-wide installs running as root, this includes sensitive files such as /etc/shadow.
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'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-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.
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.
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.
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.
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.
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.