REDHAT-BUG-2539418: Medium severity Flatpak Flatpak vulnerability
GHSA-8qxj-x646-phcm (https://github.com/flatpak/flatpak/security/advisories/GHSA-8qxj-x646-phcm)
Impact: If a malicious SDK container declares an extension point with a crafted path, and a developer runs flatpak build-init --writable-sdk --sdk-extension with that SDK, attacker-chosen files could be written outside the working directory.
Description: flatpak build-init with --sdk-extensions or --base-extensions copies extension files into the build directory. The target path comes from the directory key in the extension point metadata and is resolved using gfileresolverelativepath, which resolves .. components. A malicious extension with directory=../../<path> causes its files to be written outside the build tree. Before copying, the target path is cleaned with flatpakrmrf, so existing files at the traversed path are deleted and replaced with the extension's content.
Related to GHSA-fqx6-vh4p-42cg (CVE-2026-96275); solutions share code. Fixed in 1.18.1 (backports available for 1.16.x). Reported by @swick.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
flatpakto a version that resolves this vulnerability.Fixed in 1.18.1
Event History
Frequently Asked Questions
Who is exposed to this issue?
Developers who run flatpak build-init with --writable-sdk and --sdk-extension using a malicious SDK container are exposed. The issue also affects extension copying performed through --sdk-extensions or --base-extensions when extension metadata supplies a crafted directory path.
What does an attacker need to exploit it?
An attacker needs to provide an SDK or extension whose extension-point metadata contains a directory value with path traversal components such as ../../<path>. A developer must then use that SDK or extension during flatpak build-init.
What can happen if exploitation succeeds?
Files chosen by the attacker can be written outside the intended build directory. Existing files at the traversed target path can first be deleted by flatpak_rm_rf and then replaced with the extension content.
What should be done if an update cannot be applied immediately?
Avoid running flatpak build-init with --writable-sdk, --sdk-extension, --sdk-extensions, or --base-extensions against untrusted SDK containers or extensions. Review extension-point metadata for directory paths containing traversal components before use.
Which versions contain fixes?
The issue is fixed in Flatpak 1.18.1. Backports are available for the 1.16.x series.