Security · Flatpak

Flatpak 1.18.4 closes six ways a malicious app could reach the host

One release, six CVEs: privileged overwrites and deletions of host files, an authentication token visible to other users, loose temporary-directory permissions, unfiltered desktop and D-Bus files, and a signal that could kill the desktop environment.

By BoneTuesday 29 September 20262 min readSecurity

entryread only

filedTuesday 29 September 2026

length2 min

sectionSecurity

subjectFlatpak

sourceson the page

Flatpak 1.18.4 is out, and its release notes are close to a pure security list: six CVEs in the tooling itself, all fixed, with the same fixes carried into the 1.19.2 series. The notes describe six ways a malicious app could step outside the boundaries Flatpak is supposed to hold. The reason to run Flatpak is that installing an app you do not fully trust should be survivable, and most desktops run at least a few Flatpak apps. These are six failures of exactly those guards.

What a hostile app could do

Two of the six are about host files. A malicious app could arrange a privileged overwrite of arbitrary files, dropping an empty file or a symlink over /run/host/monitor/resolv.conf, which is the host’s DNS configuration. It could also get a privileged deletion of arbitrary files. Both are credited to Sebastian Wick, and the release adds symlink-traversal hardening related to the same pair.

Two are about exposure to other users on the machine. When downloading from an OCI repository that requires authentication, the token is no longer visible to other users. The temporary repository directories under /var/tmp/flatpak-cache-* got restricted permissions. Both were found by AISLE working with Red Hat.

The last two are about the desktop sitting around the app. .desktop and D-Bus .service files are now filtered against an allowlist of fields, closing a path to denial of service and unintended interactions with host services, found by Markus Göllnitz. And an app could previously send signals to a process group including a parent process outside the app, which was enough to take down the desktop environment. Guthrie Armstrong of Coalition reported that one.

The wrap, and what to actually do

The release also bumps the xdg-dbus-proxy wrap to 0.1.9, which covers two more CVEs of its own, and tidies some internal notes. What it does not contain is any sign of active exploitation. Every scenario above needs a malicious app installed first, and the notes read as a hardening pass rather than a breach report.

Flatpak ships with the distribution rather than updating itself, so the practical step is to take your package manager’s version when it is offered. The fixes are in both the 1.18.x and 1.19.x lines, so stable distributions are not waiting on a series change. One distinction worth keeping: flatpak update refreshes your apps, while Flatpak itself comes from your distribution’s packages. If you want to know where you stand before the update lands, flatpak --version answers that in one line.

My read

Six holes, every one needing an installed app to matter, and all six the quiet kind: a token another user could read, permissions another user could reach, a signal that ends the session. What stands out is the sourcing, independent audits landing in one release, which is what a sandbox looks like while people are testing it. Take the update when your distribution offers it. A cheap version bump for six closed holes is the trade the sandbox asks.

Source: the 1.18.4 release notes.

SecurityPyPI's new Security tab says where a release came from, and that is not a verdictPyPI's redesigned project pages went live on 6 November with a Security tab that reports a release's provenance: full, none, incomplete, inconsistent, changed or lost. The post is explicit that no provenance does not mean malicious, that it means the file origin cannot be cryptographically verified, and that the states worth checking before you install are the warnings.

SecurityPwnEscape Part 2: from a Firecracker guest to root on the host, in a setup without the jailerThe researchers behind October's kernel bug have published the other half: using that host-memory primitive to find Firecracker in memory, take over a live vCPU thread and redirect its return from KVM to a call of their choosing, with the VM left running and reachable. Their test used Firecracker v1.16.1 with the VMM launched as root and no jailer, and they say a jailer-hardened deployment needs a separate assessment. No new CVE, no vendor advisory and no Firecracker fix appears in the source.

SecurityAlpine's sshd could be logged into without a password, and the upgrade alone does not close itAlpine's advisory of 5 November describes a password authentication bypass in sshd built without PAM on musl: an attacker who can reach the SSH port logs in with a very long password as an account whose password field is *, provided another account on the machine has a $5$ or $6$ hash. Upstream OpenSSH 10.6p2 calls it a critical security workaround and puts the root cause outside sshd. Alpine's fixed packages run from edge 10.6_p2-r0 back to 3.16 9.0_p1-r6, the upgrade is not complete until sshd is restarted, and no CVE had been assigned.