CVE-2026-5674 est le genre de faille qui donne envie de relire les permissions Flatpak avec une lampe torche. Une application confinée pouvait exploiter la couche de compatibilité PulseAudio de PipeWire pour charger une bibliothèque malveillante et exécuter du code dans la session complète de l’utilisateur. Pas besoin de devenir root : sortir du bac à sable suffit déjà à récupérer des fichiers, lancer des programmes et fouiller un poste.
Le problème a été divulgué par le chercheur Johann Rehberger et suivi par Red Hat sous l’identifiant CVE-2026-5674. La fiche NVD lui attribue un score CVSS de 8,8, avec un impact qui change de périmètre : le point de départ est local et peu privilégié, mais le code s’exécute ensuite hors de la sandbox. Red Hat a publié un correctif pour RHEL 10 le 28 juillet ; les autres distributions doivent appliquer leurs propres mises à jour.
Une permission audio qui ouvre une porte
PipeWire est devenu le serveur audio et vidéo de nombreuses distributions Linux. Pour conserver la compatibilité avec les applications prévues pour PulseAudio, il expose une couche qui comprend le protocole historique et accepte notamment la permission Flatpak pulseaudio. Sur le papier, cette autorisation permet à une application de jouer du son. En pratique, elle lui donne aussi un accès à un socket pris en charge par un service qui tourne en dehors de son confinement.
C’est là que la frontière se brouille. Une sandbox n’est pas un mur magique : elle dépend des interfaces que le système lui laisse utiliser. Un socket audio peut sembler inoffensif, mais il devient une surface d’attaque si le service situé derrière accepte des commandes capables de charger du code. La permission n’est donc pas dangereuse seule ; c’est la combinaison entre le socket, un chemin d’écriture visible par l’hôte et une compatibilité trop permissive qui pose problème.
Le chercheur a confirmé le scénario avec une application Flatpak minimale. Selon son analyse, le programme ne disposait pas d’un accès direct au dossier personnel, à l’affichage ou au réseau. Il lui suffisait pourtant d’avoir accès à PulseAudio et à un emplacement accessible par le service hôte, comme /tmp, pour transformer une capacité audio en exécution dans la session de l’utilisateur.
Visuel : schéma de la chaîne d’évasion PipeWire depuis une application confinée. Source : Johann Rehberger, « Escaping Linux Sandboxes via PipeWire (CVE-2026-5674) » — https://embracethered.com/blog/posts/2026/pipewire-flatpak-linux-sandbox-escape-cve-2026-5674/
Trois erreurs qui s’empilent
La première faiblesse concerne l’authentification de la couche PulseAudio. Le protocole prévoit un cookie de 256 octets stocké dans ~/.config/pulse/cookie. Le client doit normalement présenter cette valeur au serveur. Dans l’implémentation examinée par Rehberger, PipeWire vérifiait surtout la longueur reçue, puis marquait la connexion comme authentifiée sans comparer le contenu au véritable cookie. Une serrure qui vérifie que la clé est longue, mais pas qu’elle ouvre la bonne porte.
La deuxième erreur est une option de chargement de modules activée par défaut. Une fois la connexion considérée comme authentifiée, le client peut demander à PipeWire de charger un module. Cette possibilité peut avoir une utilité légitime pour l’audio, mais elle devient beaucoup moins raisonnable quand n’importe quel processus disposant du socket peut franchir l’étape d’authentification avec 256 octets choisis au hasard.
La troisième pièce est le chargement de bibliothèque du module LADSPA. La fonction dlopen recevait un chemin fourni par le client sans restriction suffisante sur le répertoire. Une bibliothèque partagée déposée dans un emplacement visible par PipeWire pouvait alors être chargée par le service. Son constructeur s’exécute immédiatement, avec les droits de la session utilisateur et non ceux, beaucoup plus limités, de l’application Flatpak.
Ce n’est pas une escalade de privilèges vers root. PipeWire fonctionne généralement comme service de l’utilisateur. Mais un compte utilisateur contient déjà les documents, les jetons de session, les clés SSH, les navigateurs et les logiciels ouverts de la victime. Pour une application qui était censée ne faire que jouer un son, le saut est suffisamment grand pour être qualifié de sortie de bac à sable avec exécution de code arbitraire.
Un correctif qui ferme le dernier maillon
La recommandation principale est évidemment de mettre à jour PipeWire via les dépôts de la distribution. L’avis RHSA-2026:47083 classe la correction dans les mises à jour de sécurité importantes de RHEL 10 et fournit les paquets pipewire 1.4.11-1.el10_2. Il ne faut pas transposer ce numéro de version à Ubuntu, Debian, Fedora ou une autre distribution : les correctifs et les versions de paquet sont gérés séparément.
Le correctif décrit par Rehberger bloque le chargement de bibliothèques depuis des chemins absolus arbitraires. Cela casse la chaîne d’exploitation au dernier maillon, même si l’authentification et le chargement de modules ne sont pas encore réécrits partout. La fiche NVD classe le problème en CWE-427, « élément de chemin de recherche non contrôlé », et confirme le score CVSS 3.1 de 8,8 attribué par Red Hat.
En attendant le paquet corrigé, Red Hat et les analyses techniques recommandent de désactiver le chargement de modules dans la configuration PulseAudio de PipeWire avec pulse.allow-module-loading = false. Il faut aussi revoir les permissions Flatpak : une application qui n’a pas réellement besoin du socket audio ne devrait pas l’obtenir, et l’association entre ce socket et un chemin d’écriture visible par l’hôte mérite une attention immédiate. Ces mesures peuvent casser certaines applications audio ; c’est précisément le compromis à tester avant de les déployer largement.
Le correctif ne remplace pas l’audit
Mettre à jour ne répond pas à une autre question : la faille a-t-elle déjà été utilisée ? Aucun scénario d’exploitation généralisé n’est signalé dans les sources consultées, et la vulnérabilité nécessite d’abord qu’un attaquant fasse exécuter du code dans une application confinée. Mais les postes Linux installent souvent des applications communautaires et accordent des permissions au fil des besoins. Une faille locale n’est pas une faille imaginaire ; elle peut devenir la deuxième étape d’une compromission commencée ailleurs.
Sur un poste concerné, surveille les chargements de bibliothèques par pipewire ou pipewire-pulse depuis des répertoires inhabituels comme /tmp, le dossier personnel ou un répertoire propre à une application. Ce signal n’est pas une preuve à lui seul, mais il mérite d’être rapproché des journaux Flatpak, des installations récentes et des connexions à des services sensibles. Une bibliothèque audio qui arrive d’un dossier temporaire n’est pas exactement le comportement attendu d’un lecteur de musique.
Il faut également inventorier les permissions réelles plutôt que se fier au nom de l’application. Les paquets Flatpak peuvent évoluer, et une mise à jour peut modifier leurs besoins. Cherche les applications disposant à la fois de pulseaudio et d’un accès à un emplacement hôte inscriptible. Pour les conteneurs qui montent un socket PulseAudio, applique la même logique : un conteneur n’est pas isolé si tu lui donnes une interface vers un service utilisateur puissant sans contrôler ce qu’il peut lui demander.
La compatibilité, ce vieux tiroir à surprises
Cette faille rappelle pourquoi les couches de compatibilité sont des zones sensibles. Elles existent pour éviter de casser les applications anciennes, donc elles acceptent des comportements et des protocoles conçus dans un autre contexte de menace. Le serveur moderne peut être correctement cloisonné, mais une interface historique lui demande parfois de charger un module ou de faire confiance à un client de manière beaucoup trop généreuse.
La leçon dépasse PipeWire. Toute permission qui relie une sandbox à un service privilégié ou durable doit être examinée comme une API, pas comme une case pratique dans un manifeste. Audio, impression, accélération graphique, système de fichiers et périphériques ont tous leurs propres protocoles et leurs propres hypothèses. Le confinement est seulement aussi solide que la commande la plus dangereuse acceptée derrière le socket.
CVE-2026-5674 n’annonce pas la mort de Flatpak ni de PipeWire. Elle montre plutôt qu’un modèle de sécurité peut perdre toute sa finesse quand trois petits choix raisonnables se combinent : une authentification mal vérifiée, un chargement de module permis par défaut et un chemin de bibliothèque insuffisamment contraint. Mets à jour, réduis les permissions et regarde les traces. Le son doit sortir du bac à sable ; le code, beaucoup moins.
Sources
Red Hat, « RHSA-2026:47083 — Security Advisory » — https://access.redhat.com/errata/RHSA-2026:47083 — avis de sécurité, portée RHEL 10 et paquets corrigés.
NVD, « CVE-2026-5674 » — https://nvd.nist.gov/vuln/detail/CVE-2026-5674 — description, CWE-427, score CVSS et références Red Hat.
Johann Rehberger, « Escaping Linux Sandboxes via PipeWire (CVE-2026-5674) » — https://embracethered.com/blog/posts/2026/pipewire-flatpak-linux-sandbox-escape-cve-2026-5674/ — analyse technique, démonstration et recommandations.
Latest Hacking News, « A Skipped Cookie Check Let Flatpak Apps Escape PipeWire’s Sandbox Entirely » — https://latesthackingnews.com/2026/08/02/pipewire-sandbox-escape-cve-2026-5674/ — synthèse indépendante publiée le 2 août 2026 et contexte de déploiement.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet