A PipeWire sandbox escape rated CVSS 8.8 shows how one skipped check can undo years of Linux desktop hardening. Tracked as CVE-2026-5674, the bug let a sandboxed Flatpak app climb out of its box and run code as the logged-in user. It took no exploit gymnastics, just three small, chainable mistakes in PipeWire’s PulseAudio compatibility layer.
Anatomy of the PipeWire sandbox escape
PipeWire is the audio and video server used on most Linux desktops. It ships a compatibility shim so old PulseAudio clients keep working. That shim expects a client to prove itself with a 256-byte cookie stored at ~/.config/pulse/cookie. Johann Rehberger at Embrace The Red found that PipeWire reads that cookie from the client but never actually compares it against the real one. The code marks the connection authenticated regardless of what bytes arrive.
That alone would be bad. It gets worse because a second setting, pulse.allow-module-loading, defaults to on. So an “authenticated” client, cookie or not, can ask PipeWire to load a module. One of those modules, module-ladspa-sink, takes a plugin= path. It calls dlopen() on that path without checking where it leads.
From audio permission to arbitrary code
Put the three pieces together and the PipeWire sandbox escape becomes straightforward. A Flatpak app that only asked for --socket=pulseaudio, ostensibly just enough to play sound, gained a path to full code execution outside its sandbox. Rehberger’s write-up lays out the chain:
- Write a malicious shared library to a location the sandbox can still reach, such as
/tmp. - Connect to PipeWire’s socket and send junk as the authentication cookie.
- Load the module, pointing it at that library.
Its constructor runs immediately, before any application logic, in the user’s own context. He demonstrated the technique against Discord’s Flathub package. It combines PulseAudio socket access with writable filesystem paths, the exact ingredients the chain needs. As he put it: “–socket=pulseaudio should mean ‘this app can play audio,’ but it actually meant ‘this app can execute arbitrary code as you.'”
Nothing about the chain requires elevated privileges or a race condition. An attacker only needs an app already installed with that one permission, or a way to convince a user to grant it. That makes this closer to a design flaw than a memory-safety bug. There is no public report of in-the-wild exploitation. Rehberger’s disclosure went through Red Hat rather than dropping unpatched, so the risk window was mostly closed before attackers had a reason to look.
Timeline: discovery to patch
Rehberger says the bug was found and confirmed against PipeWire 1.0.5 on April 3. He reproduced it on Debian 13 and Ubuntu 24.04 within two days. He reported it to Red Hat on April 5. A CVE was assigned soon after with a CVSS score of 8.8. Initial hardening patches landed in the PipeWire repository by April 6. The CVE record itself did not go public until July 16.
Distribution patches trailed further behind. Red Hat shipped RHSA-2026:47083 on July 28. It pushed pipewire-1.4.11 to Red Hat Enterprise Linux 10 and its Extended Update Support branch. Other distributions are working through their own update cycles. Anyone running PipeWire on a desktop or workstation should check for a build newer than 1.0.5, rather than assume a rolling-release system already has it.
What the fix changes
The mitigation stops dlopen() from loading libraries off arbitrary absolute paths. That closes the third link in the chain, even if the authentication bypass itself is not immediately fixed everywhere. It is a narrower fix than rewriting the cookie check properly, though it still closes the exploit path today.
The fix is also checkable without reading a changelog line by line. A build that still lets module-ladspa-sink load a plugin from an arbitrary path stays exposed to the practical exploit, whatever the version number claims. Distributions that backport fixes selectively should confirm the dlopen() restriction specifically. Bumping a package version is not proof every patch came along with it.
What defenders and researchers should do now
For sysadmins, the checklist is short but concrete. It applies equally to Linux workstations and VDI images. Patch PipeWire to a build after the April hardening commits. If you track Red Hat, confirm the July 28 fix in RHSA-2026:47083. Then inventory which Flatpak apps request --socket=pulseaudio alongside any filesystem access. That pairing is exactly what made Discord’s package exploitable. Strip permissions that are not load-bearing for the app’s actual function. Patching PipeWire may be one line on a longer Linux server hardening checklist. Treat this PipeWire sandbox escape as the prompt to work through the rest of it.
For researchers, the more interesting angle is methodology. Rehberger says he found the bug using an automated research pipeline built around Claude Code and Claude Opus 4.6. That detail is worth watching regardless of how you feel about AI-assisted bug hunting. The underlying flaw was a plain logic error, the kind static analysis or a careful manual review could also have caught. It sat in shipped code for a while before anyone looked closely at that specific compatibility path. It joins a busy year for Linux logic-error disclosures generally, alongside kernel privilege-escalation bugs like the Bad Epoll vulnerability. There too, the flaw was one missing check rather than a novel exploitation technique.
Flatpak’s permission model assumes each grant is isolated. This PipeWire sandbox escape is a reminder that compatibility layers can quietly link grants together in ways the sandbox was never designed to allow. Any protocol bridge, audio, printing, notifications, whatever comes next, deserves the same scrutiny.
