CVE-2026-90616

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.

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.

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.