When Flatpak’s Sandbox Cracks: Real‑Life Security Issues Beyond the Ideal | Linux Journal
Flatpak promises a secure runtime for Linux applications through container-like isolation, relying on bubblewrap namespaces, syscall filtering, and portal interfaces. In theory, each app should operate inside a strong sandbox, disconnected from the host system. But in reality, experience shows gaps, tiny cracks through which apps may escape with serious consequences.
Flatpak applications begin life in a highly-restricted environment: no network by default, no access to host files beyond the runtime and a private data directory, limited syscalls, and restricted access to session or system services. Portals provide a controlled channel for granting specific capabilities (e.g. file dialogs, screenshot, printing) without broad privileges.
Yet, many Flatpak packages declare broad permissions like filesystem=home, filesystem=host, or device=all. That effectively grants full read-write access to the user's home directory or even system devices, defeating the purpose of the sandbox in practice. Users often assume that 'sandboxed' means locked-down, but blanket permissions expose them to risk.
Security researcher Gergo Koteles uncovered a high-severity vulnerability where malicious Flatpak apps could craft a .desktop file via the org.freedesktop.portal.Background.RequestBackground interface. That tricked Flatpak’s --command= parsing into injecting bwrap arguments (e.g. --bind). This allowed arbitrary host commands to execute outside the sandbox boundary. Versions before 1.10.9, 1.12.9, 1.14.6, and 1.15.8 were affected. Patched in the listed versions and mitigated in xdg-desktop-portal 1.18.4 and newer.
