Flatpak CVE-2026-96807

Requires a malicious application already installed and running inside a Flatpak sandbox on the local host running Flatpak before 1.18.1; the app must be able to replace its per-app ~/.var/app/$appid/.ld.so file with a symlink and then trigger (or wait for) regenerate_ld_cache to follow it. Exploitation is strongly LIMITED by: local access only (AV:L); high complexity (AC:H) due to timing/state control; and the vendor-confirmed constraint that written filenames and content are NOT attacker-controlled, preventing arbitrary code delivery. The realistic precondition is that a user was induced to install an untrusted Flatpak app, so despite the vector's PR:N/UI:N this is not remotely reachable and depends on prior malicious-app installation.

This is a LOW real-world priority despite being a genuine flaw. All exploitation signals point to marginal risk: the CVSS 3.1 vector (AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L, base 4.0) already reflects local-only access, high attack complexity, and only partial integrity/availability impact with no confidentiality loss. The vendor advisory (GHSA-99wv-m8rp-g58x) explicitly states the attack is 'hard to exploit' because neither the filenames nor the content written by regenerate_ld_cache are attacker-controlled - so an attacker can force writes to an arbitrary location but cannot choose what lands there, sharply limiting weaponization. Exploitation status: no public exploit identified at time of analysis (no KEV listing, no EPSS score supplied, no POC referenced). No SSVC decision points were provided in the input. Note a metadata inconsistency: the CVSS vector uses PR:N (no privileges), yet the attack requires a malicious sandboxed Flatpak app to already be installed and running, which in practice implies the user was tricked into installing untrusted software (UI:R) - the published vector does not capture that, so raw PR:N/UI:N slightly overstates ease of access.

A user installs a malicious Flatpak application; from inside its sandbox the app replaces its own ~/.var/app/$appid/.ld.so with a symlink pointing elsewhere on the filesystem. When Flatpak next runs regenerate_ld_cache, it follows the symlink and writes the ld cache to that arbitrary target location. Because the written filenames and content are fixed (not attacker-controlled), the practical impact is limited to file clobbering/denial rather than reliable code execution, and no public POC is known.