Flatpak: Technical Review and Current Assessment

Review date:April 5, 2026

Evidence base:the uploaded review, current Flatpak documentation, the Flatpak, flatpak-builder, and xdg-desktop-portal release repositories, and the current command references. This is a source and architecture audit, not a fresh penetration test or cross-distribution performance benchmark.

Executive assessment

Flatpak is best understood as a versioned desktop-application platform for Linux rather than merely a universal package format. It combines a declared application runtime, an application-specific/applayer, a Bubblewrap-created sandbox, brokered desktop integration through portals, and repository-based distribution. The uploaded draft correctly centered that layered design and correctly rejected the idea that Flatpak is simply "Docker for desktop apps."[1][2]

Its strongest engineering property is the combination of a predictable application userspace with explicit host-access boundaries. A Flatpak can rely on a distribution-independent runtime instead of whichever library versions happen to be installed by the host distribution. At the same time, filesystem, network, device, display-server, and D-Bus access are represented as permissions rather than being inherited automatically from an ordinary desktop process.[1][3]

Two qualifications are essential.

First, a runtime branch is not an immutable dependency lock. A manifest such asruntime-version: '25.08'selects a branch that receives updates. Two builds made months apart against the same branch can use different runtime commits. Exact reproduction therefore requires recording the application commit, source digests, the runtime and SDK refs, and the exact runtime and SDK commits used for the build.

Second, "runs as a Flatpak" is not itself a security rating. Effective confinement depends on the package's static permissions, permissions inherited from its runtime, user overrides, dynamic portal grants, portal-backend behavior, the versions of Flatpak and xdg-desktop-portal, and the application's own security. Broad home-directory, host-filesystem, device, or full D-Bus permissions can materially weaken isolation.[3][4]

The current security state also changed on the date of this review. GitHub marksFlatpak 1.18.1, released August 11, 2026, as the latest stable release and1.19.0as a prerelease. Version 1.18.1 contains a substantial group of security fixes, including fixes for sandbox escape, local privilege escalation, arbitrary root or host-file access, path traversal, and anti-downgrade bypasses. The latest listed flatpak-builder release is1.4.10, and the latest xdg-desktop-portal release is1.22.1, which also contains portal security fixes. Users should obtain patched packages through their Linux distribution rather than relying only on an application manifest that appears restrictive.[5][6][7]

The resulting conclusion is conditional but favorable:

>Flatpak is one of the strongest general architectures for distributing Linux desktop applications when the package targets a maintained runtime, pins its own inputs, minimizes bundled libraries, uses portals where possible, requests narrow static permissions, and remains on supported Flatpak and portal security updates.

1. Product boundary: platform, package, sandbox, and repository

A conventional distribution package normally installs files into the host filesystem and resolves dependencies against the host distribution. Flatpak moves most application userspace dependencies behind a different boundary:

Linux host

|

+-- host kernel and hardware

+-- Flatpak and Bubblewrap

+-- portal service and desktop-specific portal backend

+-- graphics, audio, and selected host services

|

v

Flatpak sandbox

|

+-- /usr selected runtime

+-- /app application and bundled dependencies

+-- private writable XDG directories

+-- explicitly granted host resources

Every application is built against a runtime, and the required runtime can be installed alongside it. Multiple runtime branches can coexist. Dependencies that are absent from the runtime, need a different version, or require a patch can be bundled into/app.[1]

This is not a complete operating-system image. The application still depends on the host kernel, CPU architecture, graphics integration, portal implementation, display server, selected host services, and Flatpak itself. "Distribution independent" therefore means that the application does not depend directly on the host distribution's ordinary userspace library set. It does not mean that every Linux computer becomes identical.

Flatpak should also be separated from Flathub. Flatpak is the packaging, sandbox, installation, and repository technology. Flathub is the principal public hosting and publishing service built around that technology. Organizations can host their own repositories, and users can configure multiple remotes.[8]

The distinction matters because software-store policy, publisher verification, review practices, and repository governance are not properties of the Flatpak sandbox format itself.

2. Runtime, SDK, and application layers

Runtime and SDK

The runtime contains libraries and data required when the application executes. The matching SDK normally contains the runtime plus compilers, headers, debuggers, build tools, and other development material.flatpak run --develand builder debugging workflows can use the SDK environment without requiring ordinary users to install a complete development stack.[1][9]

Inside the sandbox, the runtime is mounted at/usr, while application-owned files are mounted at/app. Application builds install to/app; runtime builds install to/usr. The separation is structural, not merely conventional.[10]

A runtime branch is not an immutable lockfile

The draft described a runtime as a form of versioned platform pinning. That is useful shorthand, but it needs a precise boundary.

runtime:org.freedesktop.Platform

runtime-version:'25.08'

selects a named branch. That branch can receive security fixes and other updates. The runtime branch is stable relative to arbitrary host distributions, but it is not a promise that every build sees the same object forever. For exact reproducibility, record at least:

-runtime ref and commit;

-SDK ref and commit;

-architecture;

-flatpak-builder version;

-manifest commit;

-all source commits and archive hashes;

-build options and environment;

-resulting application commit or digest.

This is similar to the distinction between depending on an LTS release line and pinning one exact artifact. Both are useful, but they solve different problems.

Bundled libraries

Bundling gives the application developer control, but it also transfers maintenance responsibility. A vulnerability fixed in a shared runtime does not fix a private copy under/app/lib. The package maintainer must inventory bundled dependencies and rebuild when those copies require updates. Flatpak's documentation recommends using runtime libraries when they are suitable rather than bundling redundant private versions.[1]

BaseApps and extensions

BaseApps provide a reusable application base for framework-heavy stacks such as Electron. Extensions can separate locales, debug symbols, plugins, codecs, drivers, and optional features from the main application object. These mechanisms reduce unnecessary installation and rebuild costs, but they add versioning relationships that should be included in provenance.[11][12]

A high-quality package should therefore describe not only its primary runtime but also its BaseApp, SDK extensions, runtime extensions, and application extensions where relevant.

3. Filesystem layout, application identity, and writable state

The application ID is a structural namespace. It participates in the manifest name, repository ref, exported desktop files and icons, D-Bus naming, and private data directories. Reverse-DNS-style IDs reduce collisions among independently distributed applications.[13]

The main runtime filesystem layout is:

/usr runtime, read-only to the application

/app application and bundled dependencies, read-only at runtime

Writable application state normally follows XDG conventions under:

~/.var/app/<APP_ID>/config

~/.var/app/<APP_ID>/data

~/.var/app/<APP_ID>/cache

~/.var/app/<APP_ID>/.local/state

Applications that useXDG_CONFIG_HOME,XDG_DATA_HOME,XDG_CACHE_HOME, andXDG_STATE_HOMEadapt cleanly to this model. Programs that hard-code paths such as~/.myappoften need persistence mappings or application changes.

The private application directory should not be described as a complete security vault. A compromised application can read and modify its own stored data. If the same application stores credentials, imported documents, or long-lived tokens there, those assets remain inside the application's trust boundary.

Some resources must be exported to the host desktop, including.desktopfiles, icons, and AppStream metadata. Exported filenames generally need to be prefixed by the application ID. This exposes only desktop-integration artifacts rather than the complete/apptree.[13]

4. How the sandbox is constructed

Flatpak uses Bubblewrap and Linux kernel facilities such as namespaces, bind mounts, and seccomp to construct an application-specific view of the system. D-Bus traffic is filtered, and selected resources are connected into the sandbox according to package metadata and runtime policy. OSTree is central to normal installation and repository deployment, while OCI is also supported in parts of the architecture and can be used as an alternative format in some infrastructure and bundle paths.[2]

This corrects two common oversimplifications:

1.Flatpak is not merely a filesystem chroot. It coordinates process, mount, syscall, D-Bus, and resource boundaries.

2.The distribution architecture is not exclusively an OSTree-only universe. OSTree remains the normal and most visible model, but official documentation also identifies OCI support.

The default application sandbox is intentionally restrictive. The application does not automatically receive broad host filesystem access, network access, arbitrary devices, full session-bus access, or visibility into unrelated host processes. Resources must be granted explicitly or accessed through a portal.[1][3]

However, the practical sandbox is theeffective permission set, not the theoretical default. Effective access can include:

-applicationfinish-args;

-permissions inherited from the runtime unless inheritance is disabled;

-command-line or persistent user overrides;

-dynamic permissions stored by portal infrastructure;

-resources provided by portals;

-special integration supplied by the desktop, graphics stack, or host services.

A security review should therefore inspect the running package and its overrides rather than judging only the manifest checked into source control.

5. Static permissions and their scientific meaning

Filesystem access

Flatpak supports narrow XDG directory access, arbitrary path grants, read-only access, create semantics, home-directory access, and broad host access. The official guidance recommends portals where possible, read-only access where sufficient, narrow XDG directories, and avoiding full home access.[3]

The difference between:

--filesystem=home

and a user-mediated FileChooser portal is substantial. The first permanently exposes a broad namespace. The second can grant access to resources the user selects.

D-Bus access

Full session-bus or system-bus socket access disables important filtering and is explicitly identified as a security risk. Packages should normally request only the names they need through--talk-name,--own-name, or related narrow declarations.[3]

This is not merely policy tidiness. D-Bus services can expose privileged desktop operations, credentials, session state, system management, or interfaces with their own vulnerabilities.

Network access

--share=networkprovides broad network capability. It is not a hostname-level outbound firewall. A package cannot express "allow only api.example.com" through this flag. Application-level TLS validation, endpoint policy, proxy configuration, and secret handling remain application responsibilities.

Network namespaces also interact with Unix-socket behavior in ways that are less visible than ordinary TCP access. Security review should not treat the singlenetworkflag as a complete network threat model.

Devices

Device permissions include DRI, KVM, shared memory, input, USB, and all devices, depending on the Flatpak version. The USB portal can provide narrower, user-authorized access to enumerated devices. Conditional permissions can reduce broad fallback grants on systems that support newer mechanisms.[3]

The meaning of a permission can evolve. Flatpak 1.18.0 added access to AMD's/dev/kfdcompute interface through the DRI device permission. A manifest that requests DRI for graphics therefore needs to be evaluated against the behavior of the Flatpak version actually deployed.[5]

Conditional permissions

Conditional permission metadata, introduced in the 1.17 development line and carried into the current stable architecture, can express policies such as preferring Wayland and permitting X11 only when Wayland is unavailable. It can also react to newer input, USB, or portal capabilities.[3][5]

This is a useful least-privilege improvement, but it makes effective permissions host-dependent. Reproducibility and security testing should include the conditions that evaluated true on each target system.

6. Portals: brokered access, not magic isolation

Portals are separate host services exposed through standardized D-Bus interfaces. They allow sandboxed applications to request operations such as opening or saving files, opening URIs, printing, sending notifications, taking screenshots, selecting devices, or accessing desktop settings. Toolkits such as GTK and Qt can use many portals transparently.[4][14]

The architectural benefit is clear:

sandboxed app

-> portal request

-> trusted host-side portal implementation

-> optional user choice or policy decision

-> selected result or capability

This can replace broad permanent permissions with a narrower operation.

Several qualifications matter.

Portal behavior depends on more than Flatpak

xdg-desktop-portalis a separate project, and desktop-specific backends implement user-interface and environment integration. Behavior can differ across GNOME, KDE, wlroots-based desktops, and other environments. A package that works through one portal backend should be tested on every supported desktop family.[4]

Portal grants are not always one-time or ephemeral

The document portal can expose selected files through a controlled FUSE-based namespace, and some dynamic permissions can be persisted in a permission store. The exact lifetime depends on the portal and operation. It is therefore too simple to describe portals only as temporary access granted at the instant a chooser closes.

Applications and users can inspect or revoke some stored portal permissions. Security and privacy testing should include permission persistence, revocation, file replacement, and application reinstallation.

Portals are security-sensitive software

The latest listed xdg-desktop-portal release, 1.22.1, fixed issues involving FileTransfer redirection, arbitrary writes through SaveFiles, and application-ID validation in the document portal. This demonstrates that the broker itself is part of the trusted computing base and must be updated.[7]

Not every host interaction has a portal

Network, graphics, audio, display-server, and some hardware capabilities still commonly require static permissions. The realistic model is:

portal where a suitable portal exists

+

minimal static permission where it does not

not "portals eliminate all permissions."

7. flatpak-builder and the build pipeline

flatpak-builder takes a JSON or YAML manifest describing the application ID, runtime, SDK, command, modules, sources, build systems, cleanup, and final permissions. Each module is built in declaration order, and builder caching can reuse unchanged earlier stages. Module order therefore affects CI cost: stable dependencies should normally appear before frequently changing application source.[8][10]

The build environment mounts the SDK read-only at/usr, makes/appwritable as the application destination, and uses stable build paths such as/run/build/<module>to reduce path-dependent output.[10]

The build is not automatically fully offline

The draft correctly praised the network-restricted module build sandbox but stated the property too absolutely. flatpak-builder has a distinct source-download phase. It can download missing sources before compilation, and manifests can override build restrictions throughbuild-args. Starting builder with--sandboxprevents those overrides. The--disable-downloadoption is the explicit way to guarantee that no network I/O is performed, provided every required source is already available locally.[10]

A strong reproducible build process is therefore:

1.pin every archive by cryptographic digest;

2.pin version-control sources to immutable commits;

3.prefetch all generated dependency sources;

4.run with network disabled or--disable-downloadafter confirming local availability;

5.use--sandboxwhen the policy requires preventing manifest build-argument escapes;

6.preserve the resolved manifest and build log;

7.record runtime and SDK commits;

8.compare resulting application commits or file digests.

Flatpak provides strong mechanisms for this process, but it does not turn a moving Git branch, nondeterministic compiler, timestamp-sensitive archive, or unlocked npm/Python/Rust dependency graph into a reproducible artifact automatically.

Language ecosystems require generated source inventories

Python, Node.js, Rust, .NET, and similar ecosystems often assume that a package manager can contact a registry during the build. Flatpak packaging commonly converts those dependencies into manifest sources before the restricted build phase. This adds maintainer work, but it makes remote inputs reviewable and cacheable.

Cleanup, locales, and debug information

Manifest cleanup removes development files not needed at runtime. Locale and debug extensions keep large optional content out of the ordinary application installation. Excessive cleanup should not substitute for configuring upstream builds to avoid generating unnecessary artifacts in the first place.[8][12]

8. Repository, signature, update, and rollback architecture

Flatpak repositories are the primary publishing mechanism. They store versioned application, runtime, and extension refs and allow clients to update from configured remotes..flatpakreffiles provide an installation description that can include the repository URL, runtime repository, branch, and GPG key.[8]

Refs and branches are mutable names

A ref such as:

app/org.example.App/x86_64/stable

identifies an application, architecture, and branch. The branch normally advances to newer commits. It is not itself an immutable version number. Provenance should therefore preserve the commit in addition to the ref.

Efficient updates

OSTree object reuse means clients can fetch changed content rather than treating every version as an unrelated installer. Static deltas can reduce request count and improve update performance further, but they must be generated and hosted; they are not a universal property of every repository update. Shared runtimes and local object deduplication can reduce duplicate storage.[1][15]

Signatures establish repository trust, not complete upstream identity

Repository signing allows a client to verify that content came from a repository trusted under a particular key. It does not by itself prove that the package was built by the upstream application developer, that every bundled dependency is safe, or that the store's review policy is sufficient for a particular organization.

For auditability, preserve:

-repository URL;

-collection ID where used;

-signing-key fingerprint;

-application ref and commit;

-runtime ref and commit;

-verification policy;

-publisher or maintainer identity separately from the repository key.

Rollback and downgrade

Versioned objects make rollback possible, but the target commit must still be available locally or from an accessible repository history. System-wide downgrade also has authorization requirements. The 1.18.1/1.19.0 release cycle changed downgrade authorization and fixed an anti-downgrade bypass, illustrating that rollback is both an operational and security function.[5]

Single-file bundles

A.flatpakbundle can support direct download, transfer, testing, or limited offline installation. It does not necessarily include the required runtime or AppStream metadata. Official documentation recommendsflatpak create-usbfor complete offline distribution because it can carry applications and dependencies in a sideload repository.[16]

The draft's statement that bundles are useful for offline transfer was directionally correct but needed this dependency qualification.

9. Security state and maintenance obligations

Flatpak's security boundary includes at least:

Linux kernel

Bubblewrap and Flatpak

D-Bus filtering

xdg-desktop-portal

portal backend

runtime libraries

bundled application libraries

application code

manifest permissions

user overrides and dynamic grants

A failure at any one layer can affect the result.

The draft correctly noted the April 2026 fixes for CVE-2026-34078 and CVE-2026-34079. It became outdated on the day of this review. Flatpak 1.18.1 was released on August 11, 2026 with a larger group of security fixes affecting sandbox directories, privileged helper paths, extra-data extraction, build initialization, OCI archive handling, appstream deployment, extension metadata, fixed-filename writes, and downgrade controls.[5]

This does not mean every distribution must ship the upstream version number 1.18.1. Stable distributions may backport fixes to an older supported branch. The operational requirement is to use the distribution's patched Flatpak packages and verify the advisory status, not merely compare a version string.

The portal layer requires the same discipline. xdg-desktop-portal 1.22.1 contains security fixes independent of Flatpak's own release.[7]

Runtime maintenance and bundled-dependency maintenance are separate:

-a runtime update can repair a common library for many applications;

-an application-bundled copy requires an application rebuild;

-an obsolete runtime branch can remain installable but should not be treated as indefinitely supported;

-BaseApps and extensions can have their own update schedules.

A package security review should report all of these layers rather than only the application's Flatpak ID.

10. Storage, startup, graphics, and portability

Flatpak normally spends more disk space than host-library packaging in exchange for dependency isolation and cross-distribution consistency. The cost is partly offset by shared runtimes, extensions, and OSTree deduplication.

One advertised installation size can be misleading. A first application may cause a runtime to be installed; a second application using the same runtime may add much less. Conversely, several runtime generations, BaseApps, locale data, debug extensions, GPU driver extensions, and application-local dependencies can accumulate.flatpak uninstall --unusedremoves no-longer-required runtime content, but administrators still need storage policy and monitoring.

The right storage benchmark measures:

-fresh installation cost;

-application layer size;

-runtime and extension size;

-incremental cost of another app on the same runtime;

-cost of another runtime generation;

-update bytes;

-actual disk growth after deduplication;

-removable content after uninstall.

Startup includes constructing namespaces, mounts, D-Bus policy, permissions, and the application process. For a large GUI program, this can be small relative to application initialization. For a tiny utility, it can be proportionally more visible. Assertions about Flatpak startup overhead should therefore be measured per application, host, and storage device.

Graphics are necessarily host-integrated. The sandbox can provide a controlled userspace, but GPU kernel drivers, device files, graphics extensions, Wayland/X11 behavior, and host display services remain outside that uniform application layer. Flatpak substantially reduces library variability; it does not eliminate hardware and desktop variability.

A portability benchmark should test one immutable application commit and runtime commit across multiple distributions, desktop environments, portal backends, GPU families, Wayland/X11 sessions, and kernel versions.

11. Appropriate and inappropriate use cases

Flatpak is particularly well matched to:

-graphical Linux desktop applications;

-applications needing one upstream-controlled dependency environment across distributions;

-scientific and creative applications with substantial userspace dependencies;

-applications that can use portals for files and desktop services;

-products distributed through Flathub or an organizational repository;

-parallel stable, beta, and nightly branches;

-applications whose maintainers can own runtime migration and bundled-dependency updates.

It is less naturally matched to:

-kernel modules;

-early-boot components;

-host system services and daemons;

-low-level package-management infrastructure;

-tiny command-line tools expected to operate transparently on arbitrary host paths and executables;

-development environments that require broad access to shells, toolchains, containers, agents, and host filesystems.

Developer tools can still be packaged, but their legitimate permission requirements may make the sandbox substantially less restrictive. Security claims must reflect application purpose.

Electron is a useful stress case. Flatpak can package Chromium/Node-based applications through a Freedesktop runtime and Electron BaseApp, but Electron's own sandbox, Node privileges, codecs, portals, and desktop integration remain separate concerns. Flatpak does not automatically repair an Electron application that disables its own renderer sandbox or exposes unsafe IPC.

12. Recommended review and provenance checklist

A serious Flatpak artifact should preserve the following.

Build identity

-application ID and branch;

-application Git commit;

-resolved manifest;

-flatpak-builder version;

-source URLs, commits, and cryptographic hashes;

-generated language-package source inventories;

-build options, patches, and environment;

-architecture;

-application OSTree or OCI commit/digest.

Platform identity

-runtime ref and exact commit;

-SDK ref and exact commit;

-BaseApp and extension refs and commits;

-Flatpak package version and distribution patch level;

-xdg-desktop-portal and backend versions;

-host distribution, kernel, desktop, session type, and graphics stack.

Security identity

-declaredfinish-args;

-inherited runtime permissions;

-conditional-permission outcomes;

-user overrides;

-stored portal permissions;

-filesystem, D-Bus, network, device, audio, and display access;

-repository URL and signing-key fingerprint;

-bundled dependency inventory and vulnerability status.

Operational testing

-first launch and warm launch;

-file-open/save portal workflows;

-permission denial and revocation;

-Wayland and X11 behavior;

-multiple portal backends;

-offline and degraded-network behavior;

-update, rollback, and failed-update recovery;

-runtime migration;

-storage growth and cleanup;

-crash isolation and data recovery;

-security behavior with the least possible permissions.

Final assessment

Flatpak's central achievement is not one isolated feature. It is the integration of five related systems:

declared runtime

+

application layer

+

default-restrictive sandbox

+

portal-mediated desktop integration

+

versioned repository distribution

The runtime reduces distribution-specific userspace variance. The application layer gives upstream developers control over additional dependencies. Bubblewrap and permission metadata create an explicit host boundary. Portals make that boundary usable for ordinary desktop workflows. Repository versioning makes shared runtimes, updates, deduplication, and rollback operationally practical.

Its boundaries are equally important. A runtime branch can move. A portal grant can persist. A package can be over-permissioned. A bundled library can become vulnerable. A portal backend can behave differently across desktops. The host kernel and graphics stack remain part of execution. Flatpak itself and its portal layer require rapid security updates.

The defensible conclusion is therefore:

>Flatpak provides a mature and unusually coherent architecture for building, distributing, and confining Linux desktop applications. Its quality must be judged package by package, using exact runtime commits, source provenance, effective permissions, portal behavior, repository trust, bundled dependency maintenance, and current security patches - not from the word "Flatpak" alone.

References

1.Flatpak, "Basic concepts." https://docs.flatpak.org/en/latest/basic-concepts.html

2.Flatpak, "Under the Hood." https://docs.flatpak.org/en/latest/under-the-hood.html

3.Flatpak, "Sandbox Permissions." https://docs.flatpak.org/en/latest/sandbox-permissions.html

4.Flatpak, "Desktop Integration." https://docs.flatpak.org/en/latest/desktop-integration.html

5.Flatpak release history, including 1.18.1 and 1.19.0. https://github.com/flatpak/flatpak/releases

6.flatpak-builder release history. https://github.com/flatpak/flatpak-builder/releases

7.xdg-desktop-portal release history. https://github.com/flatpak/xdg-desktop-portal/releases

8.Flatpak, "Repositories." https://docs.flatpak.org/en/latest/repositories.html

9.Flatpak, "Debugging." https://docs.flatpak.org/en/latest/debugging.html

10.Flatpak, "Flatpak Builder Command Reference." https://docs.flatpak.org/en/latest/flatpak-builder-command-reference.html

11.Flatpak, "Electron." https://docs.flatpak.org/en/latest/electron.html

12.Flatpak, "Extensions." https://docs.flatpak.org/en/latest/extension.html

13.Flatpak, "Requirements and Conventions." https://docs.flatpak.org/en/latest/conventions.html

14.xdg-desktop-portal documentation. https://flatpak.github.io/xdg-desktop-portal/

15.Flatpak, "Hosting a repository." https://docs.flatpak.org/en/latest/hosting-a-repository.html

16.Flatpak, "Single-file bundles." https://docs.flatpak.org/en/latest/single-file-bundles.html