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 (plugin_ladspa.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 PA_COMMAND_AUTH with 256 arbitrary bytes

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

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

Confirmed on Ubuntu 24.04 (x86_64) 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/.