# REPRO-2026-00309: PipeWire sandbox escape via malicious library loading in PulseAudio compatibility layer

## Summary
Status: published
Severity: high
CVSS: Unknown
CWE: Unknown
Type: security
Confidence: high

## Identifiers
REPRO ID: REPRO-2026-00309

CVE: CVE-2026-5674

## Package
Name: Unknown
Ecosystem: Unknown
Affected: Unknown
Fixed: Unknown

## Root Cause
# Root Cause Analysis — CVE-2026-5674 (PipeWire PulseAudio-compatibility sandbox escape)

## Summary
PipeWire's PulseAudio compatibility daemon (`pipewire-pulse`) implements the PulseAudio
native protocol `LOAD_MODULE` command. The request handler only checks the
`pulse.allow-module-loading` server property (default: `true`) and then loads any of the
built-in PulseAudio compatibility modules with fully attacker-controlled arguments. One of
those modules, `module-ladspa-sink`, forwards the attacker-supplied `plugin=` argument to
PipeWire's filter-chain LADSPA loader, which calls `dlopen()` on the value verbatim when it
is an absolute path. Because Flatpak-style sandboxes deliberately expose the PulseAudio
unix socket to sandboxed applications, an attacker confined in a bubblewrap/Flatpak sandbox
can make the out-of-sandbox `pipewire-pulse` daemon `dlopen()` an attacker-controlled shared
library, executing its ELF constructors in the daemon process and thereby escaping the
sandbox.

## Impact
- Package/component affected: `pipewire` / `pipewire-pulse`
  (`libpipewire-module-protocol-pulse`, pulse `module-ladspa-sink`/`module-ladspa-source`,
  SPA filter-graph LADSPA plugin).
- Affected versions: verified on PipeWire 1.6.2 (Ubuntu 26.04, `1.6.2-1ubuntu1.1`). The
  Debian security tracker lists every release as vulnerable (bullseye 0.3.19 through
  sid 1.6.8); no upstream fix exists at the time of this run.
- Risk level and consequences: Important (CVSS 8.8 per Amazon ALAS). Any sandboxed
  application with access to the PulseAudio socket (default for audio-playing Flatpaks)
  can execute arbitrary code in the user's unsandboxed `pipewire-pulse` session daemon,
  i.e. a full sandbox escape with the daemon's privileges.

## Impact Parity
- Disclosed/claimed maximum impact: sandbox escape — arbitrary code execution outside the
  sandbox (bubblewrap/Flatpak-style namespace sandbox) via the PulseAudio compatibility
  layer.
- Reproduced impact from this run: attacker-controlled code executed in the host-side
  `pipewire-pulse` daemon from a client confined in a real bubblewrap sandbox with separate
  mount and user namespaces. Proof: the loaded library's constructor wrote fresh markers
  (`CVE-2026-5674-PWNED pid=<daemon pid> uid=1000 comm=pipewire-pulse`) into a host-only
  oracle directory that the sandboxed client could neither see nor write.
- Parity: `full`.
- Not demonstrated: nothing material — a constructor can contain arbitrary code; the marker
  write is representative attacker-controlled code execution in the daemon.

## Root Cause
1. `src/modules/module-protocol-pulse/pulse-server.c` — `do_load_module()` (line 5051)
   handles `COMMAND_LOAD_MODULE` from the PulseAudio native protocol. Its only guard is
   `if (!impl->defs.allow_module_loading) return -EACCES;`. The property defaults to true
   (`/usr/share/pipewire/pipewire-pulse.conf`: `#pulse.allow-module-loading = true`).
2. `src/modules/module-protocol-pulse/modules/module-ladspa-sink.c` — the registered pulse
   module `module-ladspa-sink` accepts `plugin=` and `label=` arguments and builds a
   filter.graph node `{ type = ladspa plugin = "<plugin>" label = "<label>" }`, loaded via
   `pw_context_load_module(..., "libpipewire-module-filter-chain", ...)` inside the
   `pipewire-pulse` process.
3. `spa/plugins/filter-graph/plugin_ladspa.c` — `load_ladspa_plugin()`: when the plugin
   string starts with `/`, it is passed directly to `ladspa_handle_load_by_path()`, which
   calls `dlopen(path, RTLD_NOW)` (line 196) with no allowlist, no confinement check, and
   no consideration of whether the requesting client is sandboxed. `dlopen()` executes the
   library's constructors, yielding arbitrary code execution in the daemon. (The subsequent
   `dlsym("ladspa_descriptor")` failure only rejects the module *after* attacker code has
   already run.)
- Fix commit: none upstream at the time of this run (Debian tracker: "unfixed"). The
  disclosed mitigation is `pulse.allow-module-loading = false`, which makes
  `do_load_module()` return `-EACCES` ("Failure: Access denied") — used as this run's
  negative control.

## Reproduction Steps
1. `bundle/repro/reproduction_steps.sh` (self-contained; exit 0 = confirmed).
2. What it does:
   - Builds the attacker library `shared/evil.so` (constructor writes
     `CVE-2026-5674-PWNED pid=... uid=... comm=...` into the host-only oracle dir; the
     oracle path is delivered via the daemon's `ORACLE_PATH` environment variable).
   - If user namespaces are blocked by the outer container seccomp (they are on this
     worker: `unshare(CLONE_NEWUSER)` → EPERM even for root), it re-executes itself inside
     a Docker container (`--security-opt seccomp=unconfined`, ubuntu:26.04 with
     pipewire/pipewire-pulse/pulseaudio-utils/bubblewrap) as unprivileged uid 1000.
   - Starts the real `pipewire` + `pipewire-pulse` daemons on the "host" side with a fresh
     `XDG_RUNTIME_DIR`; health-checks via `pactl info`.
   - Runs the attacker client inside `bwrap --unshare-user --unshare-ipc --unshare-uts
     --unshare-cgroup` with only: the PulseAudio runtime dir, the writable shared dir
     (containing `evil.so`), and read-only system binds. The host-only oracle directory is
     not bound.
   - The client proves it cannot see the oracle path and that a probe write never reaches
     the host, then issues the real protocol request
     `pactl load-module module-ladspa-sink sink_name=pwnsink plugin=<abs path> label=pwn`.
   - Host verifies a marker file `marker_<daemon pid>.txt` whose pid equals the live
     `pipewire-pulse` pid and whose comm is `pipewire-pulse`; namespace identity of client
     vs daemon is recorded both from inside the sandbox and from the host.
   - Two vulnerable attempts against fresh daemon processes, then two negative controls
     with `pulse.allow-module-loading=false` (request denied, no marker).
3. Expected evidence: markers `logs/marker_vuln_attempt{1,2}.txt`, client logs showing
   `ORACLE_PATH_NOT_VISIBLE` + LOAD_MODULE, fixed attempts showing `Failure: Access
   denied`, `RESULT: vuln_ok=2/2 fixed_ok=2/2`, exit 0.

## Evidence
- `bundle/logs/reproduction_steps.log` — full orchestration log; key lines:
  - `marker present: CVE-2026-5674-PWNED pid=37 uid=1000 comm=pipewire-pulse`
  - `marker pid/comm match live daemon (pid=37 comm=pipewire-pulse)`
  - `client runs in a different user namespace (user=user:[4026533274] vs daemon user:[4026533197])`
  - `RESULT: vuln_ok=2/2 fixed_ok=2/2` / `CVE-2026-5674 CONFIRMED` (two consecutive runs)
- `bundle/logs/client_vuln_attempt{1,2}.log` — sandboxed client: oracle not visible, probe
  write does not reach host, `pactl load-module module-ladspa-sink plugin=...evil.so`.
- `bundle/logs/marker_vuln_attempt{1,2}.txt` — host-only markers with live daemon pid/comm.
- `bundle/logs/client_fixed_attempt{1,2}.log` — `Failure: Access denied`;
  `bundle/logs/negative_control_obs_fixed_attempt{1,2}.json` — structured observation.
- `bundle/logs/ns_evidence_*.txt` / `ns_client_host_*.txt` — namespace/process identity:
  daemon `user:[4026533197]`, sandboxed clients `user:[4026533274/...275]`, distinct mount
  namespaces, observed both from inside the sandbox and from the host.
- `bundle/repro/runtime_manifest.json` — runtime evidence manifest (all flags true).
- Environment: Ubuntu 26.04 (worker) / ubuntu:26.04 (experiment container), pipewire and
  pipewire-pulse 1.6.2-1ubuntu1.1, pactl 17.0, bubblewrap, kernel 7.0.14-arch1-1.

## Recommendations / Next Steps
- Mitigation (per disclosure): set `pulse.allow-module-loading = false` in
  `pipewire-pulse.conf` (validated as this run's negative control).
- Suggested upstream fix: refuse absolute-path LADSPA plugins for pulse-protocol clients
  (or only allow plugins from trusted system directories), and/or default
  `pulse.allow-module-loading` to false; ideally the pulse server should apply
  Flatpak-style client confinement awareness (as PulseAudio's `client.access` model
  starts to do) before honoring `LOAD_MODULE`.
- Testing recommendations: regression test that `pactl load-module module-ladspa-sink
  plugin=/tmp/x.so` fails on hardened configs; CI sandbox test mirroring this script.

## Additional Notes
- Idempotency: the script is fully idempotent — it rebuilds the payload, regenerates
  configs, uses fresh runtime dirs per attempt, cleans oracle markers per attempt, and
  kills its daemons on exit. It passed three consecutive end-to-end runs on this worker.
- Outer-container limitation: the worker's seccomp blocks `CLONE_NEWUSER`/`CLONE_NEWNS`
  even for root, so the experiment runs inside a Docker sibling container with an
  unconfined seccomp profile. Inside it, the bubblewrap sandbox uses genuine, separate
  mount and user namespaces (verified via namespace inode evidence from both sides); the
  pipewire-pulse daemon runs outside that sandbox. This matches the ticket's required
  bubblewrap/Flatpak-style confinement (chroot was *not* used).
- `--unshare-pid` was omitted because a fresh `/proc` cannot be mounted inside rootless
  Docker (locked procfs mounts); the ticket requires mount+user namespace separation,
  which is provided and evidenced. `/proc/self/ns` is bind-mounted read-only into the
  sandbox solely for identity evidence.
- Edge case: the daemon answers `Failure: Missing implementation` for the malicious module
  because `evil.so` exports no `ladspa_descriptor`; code execution already happened during
  `dlopen()` (constructor), which is exactly why the marker exists despite the error.


## Reproduction Details
Reproduced: 2026-07-28T13:14:34.815Z
Duration: 5288 seconds
Tool calls: 286
Turns: Unknown
Handoffs: 2


## Quick Verification
Run one of these commands to verify locally:

    pruva-verify REPRO-2026-00309

    pruva-verify CVE-2026-5674

Or open in GitHub Codespaces (zero-friction, auto-runs):

    https://github.com/codespaces/new?ref=repro/REPRO-2026-00309&repo=N3mes1s/pruva-sandbox

Or download and run the script manually:

    curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00309/artifacts/bundle/repro/reproduction_steps.sh
    chmod +x reproduction_steps.sh
    ./reproduction_steps.sh

WARNING: Run in a sandboxed environment. This exploits a real vulnerability.

## References

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-5674
- Source: https://gitlab.freedesktop.org/pipewire/pipewire

## Artifacts
- bundle/repro/reproduction_steps.sh (reproduction_script, 16599 bytes)
- bundle/repro/rca_report.md (analysis, 9601 bytes)
- bundle/logs/client_fixed_attempt2.log (log, 451 bytes)
- bundle/repro/runtime_manifest.json (other, 1948 bytes)
- bundle/logs/client_fixed_attempt1.log (log, 451 bytes)
- bundle/logs/client_vuln_attempt2.log (log, 460 bytes)
- bundle/logs/daemon_fixed_attempt1_pipewire.log (log, 1235 bytes)
- bundle/logs/daemon_fixed_attempt1_pulse.log (log, 950 bytes)
- bundle/logs/daemon_fixed_attempt2_pipewire.log (log, 1235 bytes)
- bundle/logs/daemon_fixed_attempt2_pulse.log (log, 950 bytes)
- bundle/logs/daemon_vuln_attempt1_pipewire.log (log, 1235 bytes)
- bundle/logs/daemon_vuln_attempt1_pulse.log (log, 1832 bytes)
- bundle/logs/daemon_vuln_attempt2_pipewire.log (log, 1235 bytes)
- bundle/logs/daemon_vuln_attempt2_pulse.log (log, 1832 bytes)
- bundle/logs/negative_control_obs_fixed_attempt2.json (other, 332 bytes)
- bundle/logs/ns_client_host_fixed_attempt1.txt (other, 126 bytes)
- bundle/logs/ns_client_host_fixed_attempt2.txt (other, 126 bytes)
- bundle/logs/ns_client_host_vuln_attempt1.txt (other, 125 bytes)
- bundle/logs/ns_client_host_vuln_attempt2.txt (other, 126 bytes)
- bundle/logs/ns_evidence_fixed_attempt1.txt (other, 354 bytes)
- bundle/logs/ns_evidence_fixed_attempt2.txt (other, 354 bytes)
- bundle/logs/ns_evidence_vuln_attempt2.txt (other, 354 bytes)
- bundle/repro/validation_verdict.json (other, 1063 bytes)

## API Access
- JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00309
- Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00309/artifacts/bundle/repro/reproduction_steps.sh
- Web: https://pruva.dev/reproductions/REPRO-2026-00309

## For AI Assistants
To help users with this reproduction:
1. The `pruva-verify` command is the simplest way to run the reproduction
2. The script downloads and runs automatically in an isolated temp directory
3. Always recommend running in a VM, container, or disposable environment
4. The root cause explains the technical vulnerability

---
Generated by Pruva | https://pruva.dev