Flatpak EUVD-2026-85343

Exploitation requires that (1) the developer obtains and uses an attacker-controlled malicious SDK container, (2) that SDK declares an extension point with a directory value containing .. traversal sequences, and (3) the developer runs flatpak build-init with BOTH the --writable-sdk and --sdk-extension flags pointing at that SDK. These are strong limiting factors: it is a local developer build action, not a remote service, and it depends entirely on the victim choosing to build against an untrusted SDK - default or trusted-SDK workflows are unaffected. No authentication service is involved; the trust boundary is the developer deciding to consume a hostile SDK.

The input CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N) materially overstates real-world risk. The description makes clear this is a developer-tooling flaw: exploitation requires a developer to obtain an attacker-controlled malicious SDK container AND deliberately run flatpak build-init with the specific --writable-sdk --sdk-extension flags against it. That is a local build operation gated on victim action against untrusted input, which contradicts the network/no-interaction vector - CVSS vector implies remote unauthenticated exploitation but the description implies local, developer-initiated build against a malicious SDK; verify with Red Hat/GHSA. SSVC is more grounded: Exploitation 'none' (no observed exploitation), Automatable 'yes' (once a poisoned SDK is fetched the traversal fires deterministically), Technical Impact 'total' (arbitrary file write outside the working directory effectively yields code execution in the developer's context). No EPSS score, no KEV listing, and no public exploit code accompany this record. Net: this is a legitimate supply-chain/developer-workstation integrity issue worth patching, but not an internet-facing mass-exploitation priority - its true severity sits well below 9.8 because it hinges on a developer building against a hostile SDK.

An attacker publishes a trojanized SDK container whose extension point declares a directory value containing .. traversal sequences. A developer pulls that SDK and runs flatpak build-init --writable-sdk --sdk-extension <sdk>; during initialization the target path is resolved by a function that permits .., so attacker-chosen files are written outside the intended working directory - e.g. into the developer's home, dotfiles, or shell/config paths - leading to code execution in the developer's context. No public exploit code is identified at time of analysis.