Corriger la faille PixelSmash (CVE-2026-8461) de FFmpeg sur Jellyfin, Nextcloud et Immich

PixelSmash (CVE-2026-8461) : ce que fait la faille

PixelSmash est le nom donné par les chercheurs de JFrog à la vulnérabilité CVE-2026-8461 : une écriture hors limites dans le tas (heap out-of-bounds write, le tas étant la zone de mémoire vive, la RAM, que le programme réserve à la volée) du décodeur MagicYUV de libavcodec, la bibliothèque de décodage de FFmpeg. Son score CVSS 3.1 est de 8.8 (élevé), avec un vecteur réseau, sans authentification, mais qui demande qu'un fichier piégé soit traité. MagicYUV est un codec vidéo sans perte. Son décodeur est compilé par défaut dans FFmpeg et dans les paquets des grandes distributions Linux : tout programme qui confie un fichier vidéo à FFmpeg peut donc déclencher la faille, même si vous n'avez jamais manipulé de MagicYUV.

Le déclencheur est un fichier vidéo piégé dans un conteneur AVI, MKV ou MOV (le décodeur n'accepte pas le MP4). La cause est une incohérence d'arrondi : quand l'en-tête du flux annonce une hauteur de tranche impaire, le calcul de la hauteur des plans de chrominance dépasse la mémoire réservée, et le décodeur écrit une ligne de pixels au-delà du tampon. Cette hauteur est lue dans le fichier lui-même, donc l'attaquant la choisit.

Pour qui administre un serveur, le point critique est l'absence de clic. Un serveur multimédia ou un cloud personnel analyse chaque nouvelle vidéo tout seul : extraction des métadonnées avec ffprobe, génération de miniatures, transcodage. Le fichier piégé est décodé dès qu'il arrive sur le disque, que ce soit par un envoi d'utilisateur ou par une chaîne de téléchargement automatisée. Ce tutoriel s'adresse aux admins qui hébergent Jellyfin, Nextcloud ou Immich sur un VPS Linux ou un serveur dédié. Il couvre aussi les cas moins visibles : un FFmpeg installé à la main depuis une archive, un serveur Jellyfin sous Windows ou sur un Raspberry Pi, et le poste de travail sous Windows, macOS ou Linux depuis lequel vous ouvrez les fichiers suspects.

Le calendrier de la divulgation, d'après le rapport de JFrog :

• 13 mai 2026 : signalement à l'équipe sécurité de FFmpeg ;
• 24 au 26 mai 2026 : signalement à Jellyfin, puis à Immich, Nextcloud (par son programme de bug bounty), mpv, OBS Studio et PhotoPrism ;
• 17 juin 2026 : sortie de FFmpeg 8.1.2, première version corrigée de la branche 8.1 ;
• 18 juin 2026 : publication de la CVE ;
• 22 juin 2026 : publication du rapport technique de JFrog.

Quel risque réel : RCE démontrée, déni de service partout

JFrog a démontré une exécution de code à distance (RCE) sur deux logiciels auto-hébergés. Sur Jellyfin 10.11.9, avec son FFmpeg maison jellyfin-ffmpeg 7.1.3, le code s'exécute pendant le scan automatique de la bibliothèque, avec les droits de l'utilisateur système jellyfin. Sur Nextcloud, il s'exécute sous www-data quand le fournisseur d'aperçus vidéo est activé. Ce compte lit config/config.php, qui contient les identifiants de la base MySQL, MariaDB ou PostgreSQL de l'instance : une prise de contrôle de ce processus donne donc accès aux données de tous les utilisateurs. Le scénario décrit pour Jellyfin parle à tous ceux qui alimentent leur médiathèque automatiquement : un fichier piégé récupéré par Sonarr ou Radarr puis déposé dans un dossier surveillé suffit.

Le rapport pose une limite qu'il faut citer : ces RCE ont été obtenues avec l'ASLR désactivé. L'exploit repose sur des adresses fixes et ne fonctionne pas avec la randomisation de l'espace d'adressage, active par défaut sur Linux. Le déni de service, lui, ne dépend pas de l'ASLR : le processus qui décode le fichier plante ou corrompt sa mémoire sur tous les logiciels testés. Jellyfin et Emby ont même terminé l'analyse avec un code de sortie 0 et sans message d'erreur, malgré la corruption du tas. Un serveur qui n'a pas planté n'est donc pas forcément un serveur sain.

Ce tableau montre aussi pourquoi la correction n'est pas uniforme. Jellyfin et Immich apportent leur propre FFmpeg : mettre à jour le paquet ffmpeg du système ne les corrige pas. Nextcloud appelle le binaire du système : c'est la distribution qui livre le correctif, pas Nextcloud. JFrog rapporte d'ailleurs que l'équipe de Nextcloud a classé le signalement comme hors de son périmètre, puisque le défaut se trouve dans FFmpeg. Le rapport cite enfin VLC parmi les lecteurs de bureau qui embarquent FFmpeg, sans publier de résultat de test pour lui : nous y revenons dans la partie consacrée aux postes de travail.

Diagnostic : votre serveur est-il exposé ?

Un même serveur contient souvent plusieurs copies de FFmpeg : celle de la distribution, celle de Jellyfin dans /usr/lib/jellyfin-ffmpeg/, et une par conteneur Docker. Il faut les inventorier toutes. Connectez-vous au serveur en SSH : tous les contrôles de ce tutoriel se font dans un terminal, en ligne de commande. Commencez par l'hôte :

command -v ffmpeg && ffmpeg -version | head -n 1
ls -l /usr/lib/jellyfin-ffmpeg/ffmpeg 2>/dev/null
dpkg -l | grep -E 'ffmpeg|libavcodec'

Le gestionnaire de paquets ne connaît que ce qu'il a installé. Un binaire copié depuis une archive statique, ou déposé par un script d'installation, lui échappe : listez tous les ffmpeg présents dans le PATH et sur le disque.

type -a ffmpeg ffprobe
sudo find / -xdev -type f \( -name ffmpeg -o -name ffprobe \) 2>/dev/null

Vérifiez ensuite que le décodeur vulnérable est bien compilé dans chaque binaire trouvé. C'est la commande proposée par JFrog :

ffmpeg -decoders 2>/dev/null | grep magicyuv
/usr/lib/jellyfin-ffmpeg/ffmpeg -decoders 2>/dev/null | grep magicyuv

Une ligne VFS..D magicyuv signifie que le décodeur est présent : c'est alors la version qui décide (section suivante). Aucune ligne : ce binaire n'est pas concerné par PixelSmash. Faites de même dans les conteneurs. Listez-les, puis interrogez le FFmpeg de chacun (les noms jellyfin et immich_server sont ceux des fichiers Compose courants, adaptez-les) :

docker ps --format '{{.Names}}\t{{.Image}}'
docker exec jellyfin /usr/lib/jellyfin-ffmpeg/ffmpeg -version | head -n 1
docker exec immich_server ffmpeg -version | head -n 1

Dernier contrôle, l'ASLR, dont dépend la différence entre un plantage et une prise de contrôle :

sysctl kernel.randomize_va_space

La valeur 2 correspond à la randomisation complète, réglage par défaut des noyaux Debian et Ubuntu. La valeur 0 désactive l'ASLR, la condition des RCE démontrées : cherchez la ligne responsable dans /etc/sysctl.conf et /etc/sysctl.d/ (les fichiers de ce dossier sont appliqués à chaque boot) et supprimez-la. Un ASLR actif ne dispense pas du correctif, il ne fait que limiter l'impact au déni de service connu à ce jour.

Versions corrigées : FFmpeg, jellyfin-ffmpeg, Debian et Ubuntu

Le correctif amont est un contrôle ajouté dans le décodage des tranches MagicYUV (commit c23d4da3, demande de fusion 23159). La page sécurité de FFmpeg et le suivi de sécurité Debian le rattachent aux versions suivantes. État au 12 novembre 2026 :

Une précision sur jellyfin-ffmpeg : ses notes de version ne mentionnent ni MagicYUV ni la CVE. Nous avons donc comparé le fichier libavcodec/magicyuv.c des tags publiés. La modification du commit c23d4da3 est absente de v7.1.3-6 et présente dans v7.1.4-1, v7.1.4-3 et v8.1.1-1. Les paquets jellyfin-ffmpeg sortis depuis fin mai 2026 contiennent donc le correctif.

Pour qui installe FFmpeg directement depuis l'amont, les dernières versions stables publiées sur la page de téléchargement de FFmpeg sont la 9.0.2 (18 septembre 2026) et la 8.1.3 (21 septembre 2026). Les deux branches contiennent le correctif : inutile de passer en 9.0 si votre outillage dépend de la 8.1.

Côté distributions, FFmpeg est un paquet de la section universe chez Ubuntu : les correctifs des anciennes LTS passent par ESM Apps, réservé aux machines rattachées à Ubuntu Pro. Canonical classe la faille en priorité moyenne et n'a pas encore publié de paquet pour 24.04 et 26.04. Sur ces versions comme sur Debian 12, la seule protection immédiate pour Nextcloud est de couper l'appel à FFmpeg (voir plus bas). Jellyfin et Immich, qui embarquent leur propre FFmpeg, ne dépendent pas de ce calendrier.

Corriger Jellyfin : mettre à jour jellyfin-ffmpeg

Jellyfin n'utilise jamais le FFmpeg de la distribution : il appelle le binaire /usr/lib/jellyfin-ffmpeg/ffmpeg, livré par le paquet jellyfin-ffmpeg. Le paquet s'appelle jellyfin-ffmpeg7 sur la branche 10.11 et jellyfin-ffmpeg8 depuis Jellyfin 12.0, publié le 8 septembre 2026 et passé à FFmpeg 8.1. La version actuelle est Jellyfin 12.4, du 26 octobre 2026.

Installation par le dépôt apt de Jellyfin

Sur une installation faite avec le script install-debuntu.sh, le dépôt de Jellyfin fournit le serveur et son FFmpeg. Une mise à jour par le gestionnaire de paquets apt suffit, suivie d'un contrôle de la version et d'un redémarrage du service :

dpkg -l | grep jellyfin
sudo apt update
sudo apt upgrade
/usr/lib/jellyfin-ffmpeg/ffmpeg -version | head -n 1
sudo systemctl restart jellyfin

La première ligne doit annoncer une version 7.1.4 ou plus récente sur la branche 7, ou une version 8.1. Avant de passer de 10.11 à 12.x, sauvegardez le répertoire de données (/var/lib/jellyfin) : les notes de version de la 12.0 le recommandent fortement, acceptent la mise à jour directe depuis 10.10.7 et 10.11.x, et préviennent que les plugins doivent être recompilés pour .NET 10. Ne cédez pas à la tentation de pointer Jellyfin vers le FFmpeg de la distribution pour aller plus vite : la documentation de Jellyfin prévient qu'un FFmpeg venu d'ailleurs ne donne qu'une accélération matérielle partielle, et vous perdriez le suivi des correctifs de jellyfin-ffmpeg. Pour une installation dans un conteneur LXC Proxmox, la procédure de snapshot et de mise à jour est détaillée dans notre guide Jellyfin en LXC sur Proxmox.

Installation Docker

L'image officielle jellyfin/jellyfin embarque jellyfin-ffmpeg. Si votre docker-compose.yml épingle un ancien tag, l'image garde le FFmpeg de l'époque : changez le tag avant de tirer la nouvelle image.

cd /opt/jellyfin
docker compose pull
docker compose up -d
docker exec jellyfin /usr/lib/jellyfin-ffmpeg/ffmpeg -version | head -n 1

Remplacez /opt/jellyfin par le dossier de votre fichier Compose et jellyfin par le nom du conteneur. Le déploiement complet (volumes, reverse proxy, transcodage matériel) est décrit dans notre guide Jellyfin avec Docker sur un VPS Linux.

Jellyfin sous Windows ou sur un Raspberry Pi

La documentation de Jellyfin indique que jellyfin-ffmpeg est livré avec le paquet deb, les images Docker officielles et l'installeur Windows. Sous Windows, la mise à jour consiste donc à réinstaller par-dessus : arrêtez Jellyfin depuis son icône dans la zone de notification, téléchargez l'installeur de la nouvelle version sur le site du projet, puis lancez-le. Une installation portable (archive zip décompressée à la main) fait exception : elle n'embarque pas FFmpeg, et c'est à vous de remplacer ffmpeg.exe et ffprobe.exe par ceux d'une version corrigée de jellyfin-ffmpeg.

Sur un Raspberry Pi sous Raspberry Pi OS, le script install-debuntu.sh est pris en charge et installe le même dépôt apt : la procédure de la section précédente s'applique telle quelle, contrôle de /usr/lib/jellyfin-ffmpeg/ffmpeg -version compris. Seule différence notable, l'accélération matérielle V4L2 du Raspberry Pi est dépréciée par Jellyfin : ne comptez pas sur elle pour décharger le processeur après la mise à jour.

Repérer un fichier MagicYUV dans la médiathèque

MagicYUV est un codec sans perte destiné à la capture et au montage : il n'a guère de raison d'apparaître dans une bibliothèque de films et de séries. Une fois jellyfin-ffmpeg à jour, et seulement à ce moment (lancer ffprobe vulnérable sur un fichier piégé, c'est déclencher la faille), ce petit script shell liste les vidéos dont le premier flux est en MagicYUV :

find /srv/media -type f \( -iname '*.mkv' -o -iname '*.avi' -o -iname '*.mov' \) \
  -exec sh -c '/usr/lib/jellyfin-ffmpeg/ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of csv=p=0 "$1" | grep -q magicyuv && echo "$1"' _ {} \;

Un résultat n'est pas forcément malveillant. D'après son éditeur, MagicYUV sert surtout à l'enregistrement de jeux (Dxtory, MSI Afterburner) et au montage (Premiere Pro, DaVinci Resolve Studio), avec un codec Video for Windows sous Windows, un composant QuickTime sous macOS et un plugin VLC. Un enregistrement de partie déposé par un membre de votre communauté peut donc légitimement en contenir. Un fichier trouvé là sans explication mérite en revanche d'être mis de côté, avec son historique de téléchargement, avant d'être supprimé.

Corriger Nextcloud : aperçus vidéo et FFmpeg du système

Nextcloud ne livre pas FFmpeg. Les aperçus vidéo passent par le fournisseur OC\Preview\Movie, qui appelle le binaire ffmpeg trouvé dans le PATH, ou celui indiqué par le paramètre preview_ffmpeg_path. Ce fournisseur fait partie de ceux que la documentation de Nextcloud désactive par défaut, pour des raisons de performance et de confidentialité. Et l'image Docker officielle nextcloud n'installe pas FFmpeg (nous avons vérifié les Dockerfile Apache des branches 32 et 35). Votre instance n'est donc exposée que si deux conditions sont réunies : OC\Preview\Movie ajouté à la configuration, et un FFmpeg vulnérable installé.

Ces deux conditions sont pourtant réunies sur beaucoup d'instances, à cause d'une extension très répandue : Memories, l'application de galerie photo de Nextcloud. Sa documentation demande d'ajouter OC\Preview\Movie à enabledPreviewProviders pour afficher les vidéos, et d'installer ffmpeg et ffprobe. Memories a aussi ses propres chemins vers ces binaires, les clés memories.vod.ffmpeg et memories.vod.ffprobe, utilisés par son serveur de transcodage (désactivé par défaut, activable depuis le panneau d'administration). Si Memories est installé, contrôlez donc trois chemins, pas un. L'outil de métadonnées qu'il embarque, exiftool, est écrit en Perl et lit les en-têtes sans décoder l'image : il n'est pas concerné par PixelSmash.

Vérifiez les deux, sur une installation classique :

sudo -u www-data php /var/www/nextcloud/occ config:system:get enabledPreviewProviders
sudo -u www-data php /var/www/nextcloud/occ config:system:get preview_ffmpeg_path
sudo -u www-data php /var/www/nextcloud/occ config:system:get memories.vod.ffmpeg
command -v ffmpeg && ffmpeg -version | head -n 1

Ou dans un déploiement Docker Compose, comme celui de notre guide Nextcloud avec Docker Compose sur un VPS Linux :

docker compose exec --user www-data app php occ config:system:get enabledPreviewProviders
docker compose exec app sh -c 'command -v ffmpeg || echo "pas de ffmpeg"'

Une sortie vide pour enabledPreviewProviders signifie que la liste par défaut s'applique, sans aperçu vidéo. Si OC\Preview\Movie apparaît et qu'un FFmpeg est présent, appliquez la solution qui correspond à votre système :

• Debian 13 : sudo apt update && sudo apt upgrade, puis vérifiez avec dpkg -l | grep -E 'ffmpeg|libavcodec' que la version installée est 7:7.1.5-0+deb13u1 ou plus récente ;
• Ubuntu 22.04 avec Ubuntu Pro : activez le service avec sudo pro enable esm-apps, puis mettez à jour par apt ;
• Ubuntu 24.04, Ubuntu 26.04, Debian 12, ou image Docker dérivée : aucun paquet corrigé n'est disponible à ce jour, retirez le fournisseur vidéo jusqu'à sa publication.

Pour retirer le fournisseur, éditez config/config.php et supprimez la ligne 'OC\Preview\Movie', du tableau enabledPreviewProviders. Si vous voulez simplement revenir à la configuration d'origine, voici la liste par défaut documentée :

'enabledPreviewProviders' => [
  'OC\Preview\PNG',
  'OC\Preview\JPEG',
  'OC\Preview\GIF',
  'OC\Preview\BMP',
  'OC\Preview\XBitmap',
  'OC\Preview\Krita',
  'OC\Preview\WebP',
  'OC\Preview\AVIF',
  'OC\Preview\MarkDown',
  'OC\Preview\TXT',
  'OC\Preview\OpenDocument',
],

Relancez la commande config:system:get pour confirmer la prise en compte. Les vidéos n'auront plus de miniature, les autres aperçus continuent de fonctionner. Si vous tenez aux aperçus vidéo, preview_ffmpeg_path permet de pointer vers un binaire FFmpeg 8.1.2 ou plus récent que vous maintenez vous-même, à condition de le mettre à jour aussi sérieusement que le reste. Pensez enfin aux liens de partage publics qui autorisent le dépôt de fichiers : ils permettent à n'importe qui de faire traiter une vidéo par votre serveur. Pour une autre faille récente touchant un environnement Nextcloud, voir notre article sur la faille Collabora CODE.

Corriger Immich : mettre à jour l'image Docker

Immich s'installe avec Docker Compose et son image serveur, ghcr.io/immich-app/immich-server, embarque jellyfin-ffmpeg 7. Le script de construction des images de base d'Immich installe le paquet jellyfin-ffmpeg7 et crée les liens /usr/bin/ffmpeg et /usr/bin/ffprobe vers /usr/lib/jellyfin-ffmpeg/. La version épinglée aujourd'hui dans ce dépôt est la 7.1.4-3, qui contient le correctif. Comme pour Jellyfin, le FFmpeg de l'hôte ne joue aucun rôle.

Mettez à jour depuis le dossier qui contient le docker-compose.yml et le fichier .env d'Immich, puis contrôlez la version embarquée :

cd /opt/immich
docker compose pull
docker compose up -d
docker exec immich_server ffmpeg -version | head -n 1

La version affichée doit être 7.1.4 ou plus récente. Si la variable IMMICH_VERSION de votre .env fige une ancienne version, l'image ne bouge pas : la valeur par défaut du fichier Compose officiel est release, qui suit la dernière version publiée (Immich 3.4.1, sortie le 11 novembre 2026). Lisez les notes de version avant tout saut de version majeure et sauvegardez la base PostgreSQL d'Immich avant de tirer la nouvelle image. Immich fonctionne sur les plateformes amd64 et arm64 : la procédure est la même sur un Raspberry Pi 64 bits, à condition qu'il dispose des 6 Go de RAM minimum (8 Go recommandés) demandés par la documentation. Sous Windows ou macOS avec Docker Desktop, configuration que la documentation d'Immich déconseille, les mêmes commandes se lancent dans le terminal du système. Notre guide installer Immich sur un VPS Linux avec Docker reprend l'installation et la procédure de mise à jour.

Sur Immich, JFrog n'a observé qu'un déni de service : le processus FFmpeg lancé pour le transcodage s'arrête sur un SIGABRT. La surface d'attaque, ce sont les comptes et les liens partagés qui autorisent l'envoi de vidéos : n'en donnez qu'à des personnes de confiance.

FFmpeg installé à la main : archive statique, scripts Python et shell

Beaucoup d'admins installent FFmpeg sans passer par la distribution, pour avoir une version plus récente que celle de Debian ou d'Ubuntu. La page de téléchargement de FFmpeg renvoie pour Linux vers des builds statiques et partagés distribués en archive. Un binaire installé ainsi, en général dans /usr/local/bin ou dans /opt, ne reçoit aucune mise à jour automatique : ni apt upgrade ni les mises à jour de sécurité sans surveillance ne le touchent. S'il apparaît dans la sortie de type -a ffmpeg et que ffmpeg -version annonce une version antérieure aux versions corrigées, remplacez-le.

Pour installer la nouvelle version, téléchargez l'archive d'une version stable corrigée, décompressez-la, puis copiez les deux binaires à la place des anciens (le chemin des fichiers dans l'archive varie selon le fournisseur du build, adaptez-le) :

tar -xf ffmpeg-*.tar.xz
sudo install -m 755 chemin/vers/ffmpeg chemin/vers/ffprobe /usr/local/bin/
ffmpeg -version | head -n 1
ffmpeg -decoders 2>/dev/null | grep magicyuv

Pensez aussi aux outils qui appellent FFmpeg sans que vous le voyiez. Un script Python comme yt-dlp, un script shell de conversion lancé par cron ou un outil de la chaîne de téléchargement utilisent le premier ffmpeg trouvé dans le PATH de l'utilisateur qui les exécute. Si un vieux binaire statique traîne dans /usr/local/bin, il passe devant celui de la distribution, même corrigé. Après la mise à jour, supprimez les copies devenues inutiles plutôt que de les laisser dormir.

Sur les postes de travail : Windows, macOS, Linux Desktop et VLC

Le fichier piégé ne vise pas que le serveur. L'admin qui récupère une vidéo suspecte pour l'examiner l'ouvre souvent sur son propre poste, et JFrog rappelle que sur un bureau Linux, il suffit d'afficher le dossier qui la contient : le générateur de miniatures du gestionnaire de fichiers décode le fichier tout seul. Avant de toucher à un échantillon douteux, mettez donc à jour votre poste.

• Linux Desktop (Ubuntu Desktop, Debian avec GNOME, KDE ou XFCE) : la libavcodec du système sert aux miniatures, à mpv, à Kodi et au VLC de la distribution. Les versions corrigées sont celles du tableau plus haut ; tant que votre distribution n'a pas publié de paquet, n'ouvrez pas de fichier suspect sur ce poste.
• VLC sous Windows et sur macOS : ces versions embarquent leur propre copie de FFmpeg. VLC 3.0.24, publié en septembre 2026, met à jour les bibliothèques intégrées, dont FFmpeg, mais le bulletin de sécurité de VideoLAN ne cite pas CVE-2026-8461 nommément. Installez la dernière version stable de VLC et considérez toute version plus ancienne comme exposée.
• FFmpeg sur macOS avec Homebrew : brew update && brew upgrade ffmpeg. La formule ffmpeg de Homebrew est en version 9.0.2 au 12 novembre 2026, une version corrigée.
• FFmpeg sous Windows : le projet ne publie pas d'installeur officiel pour Windows, sa page de téléchargement renvoie vers des builds tiers distribués en archive. Remplacez le dossier par celui d'une version corrigée, puis vérifiez avec ffmpeg -version dans un terminal PowerShell.

Le codec MagicYUV officiel (codec Video for Windows, composant QuickTime, plugin VLC) est un logiciel distinct du décodeur de FFmpeg : la CVE ne le vise pas. Pour analyser un fichier suspect, le plus sûr reste une machine jetable, par exemple un petit VPS dédié à cet usage et détruit ensuite, plutôt que le poste qui détient vos accès SSH.

Réduire la surface d'attaque au-delà du correctif

PixelSmash ne sera pas le dernier bug d'un décodeur vidéo : FFmpeg embarque des centaines de décodeurs, écrits en C pour la vitesse, et chacun lit des données fournies par le fichier. Dans le même rapport, JFrog signale une fuite d'informations distincte dans le décodeur FlashSV, non corrigée au 22 juin 2026 et jugée de faible portée, en notant qu'une fuite de ce type pourrait un jour servir à contourner l'ASLR ; ce chaînage n'a pas été démontré. Quelques réglages limitent les dégâts d'un fichier piégé, quel que soit le défaut exploité :

• Garder l'ASLR actif : si kernel.randomize_va_space n'est pas à 2, fixez-le durablement avec echo 'kernel.randomize_va_space = 2' | sudo tee /etc/sysctl.d/99-aslr.conf puis sudo sysctl --system ;
• Faire tourner chaque service sous un utilisateur dédié, jamais en root : jellyfin, www-data, ou une directive user: dans le fichier Compose. Notre guide Docker Compose sur VPS Linux détaille la syntaxe ;
• Monter la médiathèque en lecture seule dans le conteneur Jellyfin (/srv/media:/media:ro) : un processus compromis ne peut alors ni modifier ni chiffrer vos fichiers. Hors Docker, des permissions Unix qui ne donnent à l'utilisateur jellyfin que la lecture produisent le même effet ;
• Séparer la chaîne de téléchargement de la médiathèque : un dossier de transit, puis un déplacement vers la bibliothèque une fois le fichier contrôlé. Même règle pour un dossier alimenté par FTP, SFTP ou un client de synchronisation : tout ce qui y arrive sans relecture humaine est une porte d'entrée ;
• Compiler FFmpeg sans le décodeur si vous maintenez votre propre build : ./configure --disable-decoder=magicyuv, ou mieux une liste blanche des seuls décodeurs utiles ;
• Surveiller les plantages : journalctl -k | grep -i segfault révèle les erreurs de segmentation de ffmpeg ou ffprobe. Une journalisation d'audit, comme celle de notre guide auditd sur VPS Linux, garde la trace des exécutions suspectes lancées par ces utilisateurs.

Pour que les correctifs de la distribution arrivent sans attendre une intervention manuelle, configurez les mises à jour de sécurité automatiques décrites dans notre guide automatiser les mises à jour de sécurité. Si votre serveur tourne encore sous Debian 12, PixelSmash est un bon argument pour migrer vers Debian 13, qui a reçu son paquet corrigé dès le 22 juin.

Récapitulatif : quoi mettre à jour selon votre installation

Conclusion

PixelSmash touche le maillon que tous les serveurs multimédias partagent : le décodeur vidéo de FFmpeg. Le correctif tient en trois gestes, selon l'application. Pour Jellyfin, mettez à jour jellyfin-ffmpeg en 7.1.4-1 ou plus récent, ou passez à Jellyfin 12 et jellyfin-ffmpeg8. Pour Immich, tirez une image récente et vérifiez la version de son FFmpeg. Pour Nextcloud, mettez à jour le paquet ffmpeg de la distribution quand il existe, sinon retirez OC\Preview\Movie en attendant, sans oublier les chemins propres à l'extension Memories. Dans tous les cas, contrôlez chaque copie de FFmpeg présente sur la machine, dans les conteneurs et sur votre poste de travail, remplacez les binaires statiques oubliés, et vérifiez que l'ASLR est actif. Avant d'exposer un service à des fichiers venus d'ailleurs, les premiers réglages de sécurité d'un serveur dédié restent la base.