CVE-2026-76925

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 application can replace ~/.var/app/$appid/.ld.so with a symlink, causing regenerate_ld_cache to write files to an arbitrary location. The file names and content are not attacker-controlled, making this difficult to exploit.

A malicious or compromised Flatpak repository can write attacker-controlled content to arbitrary locations on the host filesystem via extract_extra_data(). 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.

In Flatpak before 0.8.7, third-party app repositories could include malicious apps with files having inappropriate permissions, such as setuid or world-writable. These files could be executed by a local attacker or allow writing to world-writable locations.

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

Flatpak prior to 1.16.4 contains a vulnerability where 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, giving apps access to all host files and can be used as a primitive to gain code execution in the host context.

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. Flatpak creates app data directories (e.g., /var/cache, /var/data, /var/config, /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, and a malicious symlink can point to arbitrary locations on the host and become mounted inside the sandbox.

In Flatpak prior to version 1.16.4, the ld.so caching mechanism removes outdated cache files without verifying that the app-controlled path is within the cache directory. This allows Flatpak apps to delete arbitrary files on the host.