通过 PipeWire 逃逸 Linux 沙箱（CVE-2026-5674）

This post walks through a sandbox escape from a Flatpak application via PipeWire. The vulnerability was discovered using my automated research pipeline with Claude Code and Opus 4.6 back in April 2026. It was an exciting find, as this was the first bug I submitted to Red Hat.

Claude Code was also excited finding this:

Once discovered, I repro’d it manually to make sure it’s legit and then submitted it to Red Hat.

Let’s dive into it.

PipeWire and PulseAudio

PipeWire is the default audio server on all modern Linux desktops now. Fedora, Ubuntu 24.04+, Debian 13,… It replaced PulseAudio but maintains backward compatibility.

Flatpak apps that need audio request --socket=pulseaudio.

At the core, a basic “Hello World” app with standard audio permission breaks out of the sandbox and gets full access to the user’s desktop, files, and credentials. The same attack applies to other Linux sandbox tech that connects a socket to PipeWire (e.g. Docker, etc..).

Let’s look at the vulns and exploit.

The Vulnerabilities

The escape relies on three separate issues.

1. Authentication Cookie Is Never Validated

PulseAudio code contains cookie-based authentication. This is not a typical web cookie, just a name for an authentication token. It’s a 256-byte random value that lives at ~/.config/pulse/cookie, and clients must present it to connect. PipeWire reads the cookie from the client, checks the length is 256 bytes, and then just… throws it away.

The relevant code in pulse-server.c:

The cookie variable is never referenced again after being read. Any 256 bytes of garbage will do. No comments in the code explain why the value is set to true. The original PulseAudio validates the cookie, however PipeWire does not.

I looked through the git history. This has been the behavior since the PulseAudio compatibility layer was first implemented.

2. Module Loading Is Enabled by Default

Any “authenticated” client can send LOAD_MODULE to load arbitrary PipeWire modules. A config option (pulse.allow-module-loading) was added in May 2024, but it defaults to true.

Since authentication is broken, this means any process with socket access can load modules.

3. dlopen() With No Path Validation

When module-ladspa-sink is loaded, it takes a plugin= parameter and calls dlopen() on it directly:

There is no path validation or directory allowlist. So, we can load arbitrary libraries.

ELF constructors (__attribute__((constructor))) run immediately on dlopen().

This is the same pattern as CVE-2025-60616 in FFmpeg’s LADSPA loader.

Oh, and if you are wondering what LADSPA means, it stands for Linux Audio Developer's Simple Plugin API. That’s something new I learned along the way.

The Sandbox Escape

Flatpak’s --socket=pulseaudio grants access to the PulseAudio socket. Combined with any host-writable path (like --filesystem=/tmp in the demo), an app can escape the sandbox.

The exploit chain:

Write a malicious .so to a host-visible path (e.g. /tmp); Connect to the PulseAudio socket; Send PA_COMMAND_AUTH with 256 bytes of garbage; Send PA_COMMAND_LOAD_MODULE module-ladspa-sink plugin=/tmp/payload.so; PipeWire, running outside the sandbox, calls dlopen() on the .so; The constructor executes in the user’s full context (outside the sandbox)

The app has no home directory access, no display access, no network. Yet after the exploit it can read your files, launch apps on your desktop, and access your credentials.

Note that PipeWire runs as a user-level service, not root. This is a sandbox escape, not privilege escalation. But the attacker goes from “sandboxed, can only play audio” to “full, unrestricted user context.”

Proof of Concept

I built a Flatpak app called net.wuzzi.Hello that demonstrates this. It looks completely harmless:

Two permissions. PulseAudio and write to temp directory. That’s it.

Running it:

Looks innocent, but it also did this:

The app also launches gnome-calculator on the host desktop.

I also verified the negative case with --socket=pulseaudio removed, to make sure the exploit fails. Since this was AI discovered, and I have a healthy scepticism for AI output, I double-checked to not submit any slop.

Real-World Scope

I was wondering how common pulseaudio access is in sandboxed apps, and quickly found one on Flathub:

Discord has --socket=pulseaudio + --filesystem=xdg-download

Any Flatpak app with audio permission and any host-writable path is exploitable.

The same attack also works from Docker containers with the PulseAudio socket mounted, which is a standard setup for containerized audio.

Mitigations

These were the mitigations and recommendations I provided. Any one of these breaks the chain:

Validate the cookie. Compare against ~/.config/pulse/cookie, like PulseAudio does; Default allow-module-loading to false. The option exists since May 2024; Restrict LADSPA plugin paths. Only dlopen() from /usr/lib/ladspa/ and /usr/lib64/ladspa/, not arbitrary paths

To my understanding, locking down (3) is what was implemented to mitigate the issue.

Disclosure Timeline

2026-04-03: Vulnerability discovered using Claude Code and confirmed on PipeWire 1.0.5; 2026-04-04: Reproduced on Debian 13 (aarch64); 2026-04-05: Also confirmed POC on Ubuntu 24.04 (x86_64) and Debian 13 (aarch64); 2026-04-05: Report submitted to Red Hat Product Security. A day or two later Red Hat assigned CVE-2026-5674 for later publication. CVSS Score High 8.8; 2026-04-06: Initial hardening patches landed in the PipeWire repository; 2026-07-28: Red Hat Enterprise Linux 10 Patch Available: RHSA-2026:47083

Also, I got a shout out from Red Hat in the official CVE-2026-5674.

Cool.

Conclusion

PipeWire’s PulseAudio compatibility never validates the authentication cookie. Module loading is enabled by default, and dlopen() loads whatever path you give it.

Together a sandboxed Flatpak app (or other sandbox with audio socket access), and you get full user-context code execution. A “Hello World” app with audio permission writes to your home directory and pops calculator on your desktop.

In short --socket=pulseaudio should mean “this app can play audio.”, but it actually meant “this app can execute arbitrary code as you.”

As far as I can tell the fix was for dlopen() to prevent loading libraries from arbitrary absolute paths.

Red Hat has released a fix. If you’re affected (e.g. PipeWire applies to most distros) update.

Cheers, Johann.

References

PipeWire GitLab; https://www.cve.org/CVERecord?id=CVE-2026-5674; CVE-2025-60616 - FFmpeg LADSPA dlopen(); PipeWire Issue #847 - Auth Support; Fix. Prevent dlopen of absolute paths; Flatpak Sandbox Permissions; Flatpak Audio Portal Discussion

Newer →; Contact me; ← Older