Flatpak 1.18.1 was released on August 11 as a stable patch closing ten CVEs. The severity range runs from full host filesystem sandbox escapes to arbitrary root privilege escalation, which is roughly the worst thing a sandboxing framework can be told about itself.

What a sandbox escape means here

Flatpak’s entire value proposition is that an application you do not fully trust runs inside a confinement boundary, with access only to what its manifest declares and what you grant. A sandbox escape means that boundary did not hold.

The headline issue, tracked as CVE-2026-34078, is a symlink attack on application data directories that yielded read and write access to the full host filesystem. An application that could trigger it was, for practical purposes, not sandboxed at all.

The full list

The ten CVEs cover several distinct attack paths:

• A sandbox escape giving full host filesystem read and write via symlink attack on app data directories
• Local root privilege escalation via revokefs symlink path traversal and commit tampering
• Arbitrary root write via symlink and path traversal in extra-data extraction
• Arbitrary root write via path traversal in flatpak build-init
• Arbitrary host file read via hardlink path traversal in OCI archive extraction
• Path traversal via an unvalidated architecture parameter in DeployAppstream
• A buffer overflow in OCI delta stream path names on 32-bit systems
• An anti-downgrade policy bypass

The recurring theme is the same one that produced rsync’s 33-issue release two days later: path traversal and symlink handling at a trust boundary. Any code that unpacks an archive controlled by someone else and writes the results to disk has to decide what to do about .. and about symlinks pointing outward, and getting that wrong is easy in ways that are not visible in a code review.

Who is most exposed

If you install Flatpaks exclusively from Flathub’s verified publishers and never touch OCI images, your practical risk was lower, because exploiting most of these requires you to install something hostile in the first place.

If you install from third-party remotes, sideload OCI bundles, or run applications you have not vetted, the update is urgent rather than routine.

# What remotes do you actually have configured?
flatpak remotes --show-details

# What is installed, and from where?
flatpak list --app --columns=application,origin

Upgrading

# Check your version
flatpak --version

# Debian and Ubuntu
sudo apt update && sudo apt install --only-upgrade flatpak

# Fedora
sudo dnf upgrade flatpak

# Arch
sudo pacman -Syu flatpak

Distributions have been shipping the update quickly given the severity. A 1.19.0 pre-release carrying the same fixes is also available for anyone tracking the development branch.

Note that upgrading the Flatpak runtime is what matters here. Updating your installed applications does not help, because the vulnerable code is in Flatpak itself, not in the apps.

Context on the sandbox conversation

Flatpak has taken sustained criticism over the years for sandboxes that are weaker in practice than they look, largely because many popular applications request broad permissions like --filesystem=home and users grant them without much thought. That critique is about configuration, and it is a fair one.

This release is a different category of problem. These are bugs where the confinement failed regardless of how carefully the permissions were set. That is worth separating from the usual argument, because the fix is also different: you cannot tighten your way out of a symlink bug, you can only patch it.

Our comparison of Snap, Flatpak, and AppImage covers how the three sandboxing models differ, and why “sandboxed” means noticeably different things across them.