SURIQ
The sandbox is supposed to be the wall. On a modern Linux desktop, when you install an app as a Flatpak or a Snap, the promise is that a bad app stays boxed in: it sees only what you grant it and cannot touch the rest of your files or run code as you. CVE-2026-5674 puts a hole in that wall, and it does so through a component almost every desktop grants without a second thought: audio.
Red Hat published the flaw on July 16, 2026, rated it 8.8 on the 10-point severity scale, and classed it as an uncontrolled search path problem (CWE-427). The mechanism is a sandboxed app abusing PipeWire's PulseAudio compatibility layer to load a library of the attacker's choosing and execute it outside the sandbox. One caveat sets the priority: this is a local flaw, not a remote one. The attacker already needs code running inside a sandboxed application. What the bug gives them is the way out.
How the audio server becomes the escape hatch
PipeWire replaced the older PulseAudio server on most Linux desktops but kept a compatibility layer so PulseAudio-era software keeps working. That layer accepts a command to load audio modules at runtime. One of those modules, the LADSPA sink (a plugin format for audio filters), takes a path to a plugin library and loads it with dlopen(). PipeWire does not constrain where that library can live.
According to Red Hat's report, a sandboxed process that holds two things can chain them into a full escape: access to the PulseAudio socket, and the ability to write a file somewhere the host-side PipeWire process can read. The app drops a small shared library, then asks the compatibility layer to load it as an audio filter. PipeWire calls dlopen() on the attacker's file, and the library's initializer runs immediately, in the user's full context, with none of the sandbox's restrictions. No memory-corruption trick, no race. The server does exactly what it was asked to do, on a file it should never have trusted.
Both preconditions are ones people grant casually. The PulseAudio socket is one of the most common sandbox permissions, because an app without sound looks broken. A writable host-visible directory is routine for apps that open or save your documents. Neither looks dangerous alone. Together they are an exit.
Who is exposed
The researcher who reported it confirmed the escape on Ubuntu 24.04 and Debian 13, and noted it likely affects every PipeWire build since the PulseAudio compatibility layer was introduced. Red Hat marks its Red Hat Enterprise Linux (RHEL) 9 and 10 builds of the pipewire package as vulnerable, and the older RHEL 8 build as safe.
| Platform / package | Status |
|---|---|
| RHEL 9 (pipewire) | Affected |
| RHEL 10 (pipewire) | Affected |
| RHEL 8 (pipewire) | Not affected |
| PipeWire 1.0.5 and older, upstream | Affected |
| Ubuntu 24.04, Debian 13 | Confirmed vulnerable |
The practical exposure is anyone who relies on Flatpak, Snap, or similar isolation to run software they do not fully trust: a single-purpose kiosk, a shared workstation, a developer running a random utility, a distro that ships everything as sandboxed packages by default. The whole point of putting an app in a sandbox is to survive it turning hostile. This flaw undercuts that assumption for the audio-enabled majority. In MITRE ATT&CK terms it is an escape to host (T1611): the containment boundary, not the application, is what fails.
Close the audio escape hatch
There is a direct mitigation that does not wait on a package update. PipeWire's PulseAudio server supports a setting, pulse.allow-module-loading, that turns off runtime module loading entirely. Set it to false and the load-a-library path is gone. The option has existed since May 2024, which is the uncomfortable part: the fix was available long before the flaw was public, and almost no one set it. The real exposure here is behavioral, not version-bound.
Beyond the toggle, two moves matter. Audit your sandbox permissions for apps that hold both the PulseAudio socket and a writable host path, and tighten either one where the app does not genuinely need it. And apply your distribution's PipeWire updates as they land: Red Hat is tracking fixes for the affected RHEL packages, and the upstream project has been hardening the PulseAudio server across its recent 1.6.x releases. Treat the config change as today's work and the package update as this week's.
How you would know
Patching closes the hole. It does not tell you whether something already walked through it. This flaw leaves a distinctive trace: the pipewire-pulse process loading a shared object from a user-writable path such as a temporary or home directory, rather than from the system plugin directories where legitimate audio filters live. That is not normal behavior for an audio server, and it is exactly the kind of host-level anomaly worth alerting on. Managed detection that watches process and library-load events, and maps them to ATT&CK, turns this from an invisible escape into a signal. If you run endpoint monitoring on your Linux fleet, add a watch for module loads outside the trusted plugin paths.
The wider lesson is where the trusted computing base actually sits on a Linux desktop. We keep finding the isolation break outside the kernel: a kernel bug that turns a sandboxed process into root, an editor sandbox escape, a memory flaw in the graphics stack, and now the audio server. The sandbox is only as strong as every service it is allowed to talk to. Audio was on that list the whole time.