REDHAT-BUG-2455341: High severity gitlab.freedesktop.org/pipewire/pipewire vulnerability
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/.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure the cookie used for PulseAudio authentication is validated against ~/.config/pulse/cookie.
PulseAudio (compatibility layer / pipewire-pulse) cookie validation = validate against ~/.config/pulse/cookie - Configuration
Set pulse.allow-module-loading = false (option exists since May 2024) to prevent loading of modules such as module-ladspa-sink.
PipeWire PulseAudio compatibility pulse.allow-module-loading = false - Configuration
Restrict dlopen() paths used by module-ladspa-sink to /usr/lib/ladspa/ and /usr/lib64/ladspa/.
module-ladspa-sink (plugin_ladspa.c) dlopen() paths restriction = /usr/lib/ladspa/ and /usr/lib64/ladspa/ - Compensating control
Do not install Flatpaks with audio permissions; avoid allowing any sandboxed process to connect to the PulseAudio socket (for Flatpak/Docker/Snap, prevent use of --socket=pulseaudio / access to the pulseaudio socket).
Event History
Frequently Asked Questions
Which sandboxed workloads are exposed?
Flatpak applications and other containers such as Docker or Snap can be exposed when they have access to the PulseAudio socket and write access to a host-visible path where a malicious shared library can be placed.
What access does an attacker need?
The attacker needs the ability to run code in a sandboxed application or container with minimal privileges, including access to the PulseAudio socket and a writable host-visible filesystem location. No user interaction is required.
Is a fixed version identified?
No fixed version is identified in the provided data, and patch availability is listed as no. The affected versions are listed as 1.0.5 and earlier, with the issue considered likely to affect versions since the PulseAudio compatibility layer was introduced.