A flaw was found in PipeWire, a multimedia server. This vulnerability allows an attacker to escape sandboxed applications, such as Flatpak, by exploiting PipeWire's PulseAudio compatibility layer. An attacker with minimal permissions within a sandboxed environment can load a malicious library, leading to arbitrary code execution outside the sandbox and potential compromise of the user's system.

Summary: An attacker can exploit PipeWire load library vulnerability to escape sandboxed processes.

Requirements To Exploit: A Flatpak app (or Docker container, Snap, etc..) with minimal permissions, like:

--socket=pulseaudio and

--filesystem=/tmp/share/ (basically write access to any host-visible path to drop the malicious library)

Component Affected: gitlab.freedesktop.org/pipewire/pipewire

module-protocol-pulse (pulse-server.c) and module-ladspa-sink (pluginladspa.c)

Version Affected: <= 1.0.5 (likely all versions since the PulseAudio compatibility layer was introduced)

Patch Available: no

Version Fixed: N/A

Cvss: 8.8 High

AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — Local vector, low complexity, low privileges, no user interaction, changed scope (sandbox escape). High CIA impact on user session. Since a Flatpak are remotely retrieved one could also claim RCE with arbitrary local code execution, but I don’t think it’s a critical class issue.

Impact: I’d say Important (sandbox escape with minimal permissions)

Steps To Reproduce: Build a Flatpak app with --socket=pulseaudio and --filesystem=/tmp/wuzzi:create

From the app, write a .so with an ELF constructor to /tmp/wuzzi/payload.so

Connect to the PulseAudio socket, send PACOMMANDAUTH with 256 arbitrary bytes

Send PACOMMANDLOADMODULE module-ladspa-sink plugin=/tmp/wuzzi/payload.so

PipeWire (outside sandbox) calls dlopen() — constructor executes in full user context

Confirmed on Ubuntu 24.04 (x8664) and Debian 13 (aarch64), PipeWire 1.0.5

Mitigation: Don’t install Flatpaks with audio, or allow any sandbox’d process to connect to pulseaudio socket.

Recommended mitigations from product side. Any one breaks the attack chain:

(1) Validate the cookie against ~/.config/pulse/cookie;

(2) Set pulse.allow-module-loading = false (option exists since May 2024);

(3) Restrict dlopen() paths in module-ladspa-sink to /usr/lib/ladspa/ and /usr/lib64/ladspa/.