Veille CVE

Mercredi 23 septembre 2026

4 CVE

Critique 0 Élevée 2 Moyenne 2 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « flatpak » ✕
  1. CVE-2026-96808 7.4 Élevée

    Flatpak

    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.

  2. CVE-2026-96807 4.0 Moyenne

    Flatpak

    In Flatpak before 1.18.1, a malicious sandboxed app can replace ~/.var/app/$appid/.ld.so with a symlink, causing regenerate_ld_cache to write files at an arbitrary location. The filenames and content are not attacker controlled, making this hard to exploit.

  3. CVE-2026-96276 6.5 Moyenne

    Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 7 · Red Hat Enterprise Linux 8 · Red Hat Enterprise Linux 9

    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.

  4. CVE-2026-96275 8.8 Élevée

    Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 8 · Red Hat Enterprise Linux 9 · Red Hat Enterprise Linux 7

    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.