Flatpak – An Insecurity Nightmare

Flatpak applies container-style isolation to the Linux desktop, pairing Portals and the Freedesktop SDK to give developers a consistent, confined platform and a single delivery channel via Flathub. Critics often point to decades-old or unconfined applications to claim Flatpak is insecure, but those examples show insecure application design or reliance on APIs that predate sandboxing rather than a failure of the sandbox itself. Many modern apps can and do restrict permissions far more than legacy packages; where static permissions are used it reflects either immature APIs or compatibility tradeoffs. A concrete mitigation example is the PrismLauncher/“fractureiser” case: running inside a Flatpak sandbox prevented access to the host ~/.config paths, redirected writes to ephemeral tmpfs, and blocked systemd execution, so malware that assumed an unsandboxed environment failed to operate.

Outdated bundled libraries are not a fatal flaw because runtimes receive security updates (even ABI-breaking ones when necessary) and some components, like GPU drivers, can be updated independently of an app’s runtime. The sandbox further limits the impact of lingering vulnerabilities while maintainers fix builds. The path forward is wider adoption of sandbox-friendly tooling - Wayland, PipeWire, Portals - and continued improvement of permission APIs rather than reverting to traditional packaging models that discourage developers and degrade user experience.