FFmpeg corrige PixelSmash, une RCE qui menace Jellyfin

Une vulnérabilité surnommée PixelSmash a été corrigée dans FFmpeg, bibliothèque multimédia massivement intégrée dans des serveurs, applications de streaming, pipelines de transcodage et outils d’analyse vidéo. Le sujet dépasse largement le seul lecteur multimédia local : dès qu’un service web ou un serveur auto-hébergé s’appuie sur FFmpeg pour inspecter, indexer, transcoder ou générer des miniatures à partir de contenus fournis par des utilisateurs, une faille dans un décodeur vidéo devient un risque d’attaque à distance. C’est précisément ce qui rend le cas particulièrement sensible pour des déploiements comme Jellyfin, où le décodage peut être déclenché côté serveur sur des médias nouvellement importés.

Selon les éléments relayés par BleepingComputer à partir de l’annonce amont de l’écosystème FFmpeg, la faille concerne un décodeur vidéo largement utilisé et peut, dans certains scénarios, mener à une exécution de code à distance lors du traitement d’un fichier vidéo piégé. Le risque concret dépend fortement de l’architecture de déploiement : droits du processus, isolation des workers, exposition des fonctions d’import, automatisation des scans de bibliothèques, et présence ou non d’un transcodage serveur. À ce stade, l’important pour les équipes techniques est moins le nom marketing de la faille que sa nature : une faiblesse dans une bibliothèque de parsing média omniprésente, susceptible d’être atteinte indirectement via des applications web ou des serveurs de streaming.

Le point critique pour les développeurs, DevOps et RSSI est la dimension chaîne d’approvisionnement logicielle. Beaucoup d’instances n’installent pas FFmpeg comme composant métier visible : il arrive via le système d’exploitation, via une image conteneur, via un paquet embarqué par l’application, ou via une dépendance transitive dans une appliance logicielle. Dans un environnement auto-hébergé, notamment chez des hébergeurs et VPS fréquemment utilisés en France comme OVHcloud, Scaleway ou o2switch, il n’est pas rare que le service exposé sur Internet soit perçu comme “Jellyfin” ou “serveur média”, alors que la surface d’attaque réelle inclut aussi les parseurs et décodeurs natifs invoqués en arrière-plan.

La source citée par l’écosystème grand public est l’article de BleepingComputer, qui renvoie au correctif publié côté FFmpeg. En l’absence, dans le brief fourni, d’un identifiant CVE, d’un score CVSS confirmé, et d’une matrice de versions précisément documentée, il faut rester strictement factuel : une version corrigée a été publiée par l’éditeur amont, et des correctifs aval sont attendus ou déjà en cours de diffusion dans les distributions Linux et les applications qui embarquent la bibliothèque. Les équipes doivent donc raisonner en deux temps : identifier où FFmpeg est réellement utilisé, puis appliquer la mise à jour disponible depuis la source officielle ou via les paquets fournis par l’éditeur de la distribution ou de l’application.

Versions affectées

Les informations publiquement relayées dans le cadre de cette alerte indiquent que la vulnérabilité touche des versions de FFmpeg contenant le décodeur vidéo concerné, et qu’un correctif amont a été publié. En revanche, sans advisory détaillé listant explicitement toutes les branches vulnérables et la première version corrigée, il ne faut pas inventer une fenêtre de versions précise.

Sur une base strictement prudente, doivent être considérés comme potentiellement affectés :

• les déploiements utilisant une version de FFmpeg non encore mise à jour avec le correctif amont publié par le projet ;
• les applications qui embarquent leur propre build de FFmpeg plutôt que d’utiliser la bibliothèque système ;
• les images conteneur anciennes contenant une version de FFmpeg construite avant la publication du correctif ;
• les serveurs média comme Jellyfin lorsque des fonctions d’analyse, de génération de vignettes, d’extraction de métadonnées ou de transcodage invoquent le décodeur vulnérable.

Doivent être considérés comme corrigés uniquement :

• les systèmes sur lesquels l’éditeur ou la distribution a explicitement publié un paquet FFmpeg intégrant le correctif ;
• les applications ayant annoncé une mise à jour embarquant une version corrigée de FFmpeg ;
• les conteneurs reconstruits à partir d’une base mise à jour et redéployés en production.

Concrètement, il faut vérifier trois niveaux, car un seul peut donner un faux sentiment de sécurité :

• niveau système : paquet ffmpeg installé via apt, dnf, yum, apk ou équivalent ;
• niveau application : binaire embarqué par Jellyfin ou par un autre service multimédia ;
• niveau conteneur : version réellement présente dans l’image exécutée, qui peut différer de l’hôte.

Quelques commandes utiles pour inventorier l’exposition :

ffmpeg -version which ffmpeg dpkg -l | grep ffmpeg rpm -qa | grep ffmpeg apk info | grep ffmpeg docker exec -it <conteneur> ffmpeg -version

Dans un contexte Jellyfin, il est également utile de vérifier si l’application utilise le binaire système ou un composant embarqué, ainsi que les options de transcodage matériel et logiciel configurées. Une version corrigée du paquet système ne protège pas automatiquement une application qui appellerait un autre binaire.

Point de vigilance : l’absence d’identifiant CVE ou de score CVSS confirmé dans les informations disponibles ne réduit pas le risque opérationnel. Pour un serveur qui traite automatiquement des médias non approuvés, une faille de décodage exploitable à distance doit être traitée comme prioritaire.

Vecteur d'attaque

Le vecteur décrit est celui d’un fichier vidéo piégé qui déclenche la vulnérabilité lorsqu’il est décodé par FFmpeg. Le point essentiel est que l’utilisateur final n’a pas forcément besoin de “lire” la vidéo dans un lecteur interactif : dans un environnement serveur, le simple fait d’ingérer le média peut suffire à lancer un traitement vulnérable.

Les scénarios réalistes incluent notamment :

• import automatique d’un fichier dans une bibliothèque Jellyfin ;
• scan périodique d’un répertoire surveillé par le serveur média ;
• génération de miniature ou de prévisualisation à l’ajout d’un contenu ;
• lecture à distance par un utilisateur déclenchant un transcodage serveur ;
• analyse de métadonnées ou extraction d’informations techniques pour l’interface d’administration.

Autrement dit, l’attaque peut être pré-authentifiée dans certaines architectures, par exemple si un service synchronise automatiquement des fichiers déposés dans un espace partagé, ou si un utilisateur disposant d’un accès limité à l’upload peut faire traiter un média par le backend. Dans d’autres cas, elle sera post-authentifiée, mais avec un impact potentiellement très élevé si le rôle “uploader” ou “contributeur” peut alimenter le pipeline de décodage.

Le caractère crédible de la RCE dépend de plusieurs variables techniques :

• le type exact d’erreur mémoire corrigée dans le décodeur ;
• la possibilité de contrôler finement les structures parsées par FFmpeg ;
• les protections de compilation actives, comme ASLR, PIE, RELRO, stack canaries et durcissement du compilateur ;
• les privilèges du processus de transcodage ;
• la présence d’un sandboxing effectif, par exemple via systemd, seccomp, namespaces, conteneurs ou profils AppArmor/SELinux.

Il faut insister sur un point souvent mal compris : même si l’exécution de code n’est pas trivialement reproductible dans tous les environnements, une corruption mémoire dans un composant natif exposé à des données non fiables reste un risque majeur. Selon le contexte, l’impact peut aller du crash du worker à un déni de service, à la fuite mémoire, voire à l’exécution de code si les conditions sont favorables.

Pourquoi Jellyfin est particulièrement concerné

Jellyfin n’est pas “la cause” de la faille, mais il constitue un excellent exemple d’exposition indirecte. Le serveur média s’appuie sur FFmpeg pour de nombreuses opérations côté serveur. Dans un déploiement auto-hébergé, plusieurs habitudes augmentent la surface d’attaque :

• bibliothèques alimentées par des fichiers récupérés automatiquement depuis d’autres sources ;
• partages réseau montés en lecture/écriture ;
• comptes utilisateurs multiples avec droits d’ajout de médias ;
• exposition de l’interface d’administration ou des bibliothèques sur Internet ;
• exécution du service avec des permissions plus larges que nécessaire.

Dans ce modèle, l’attaquant n’a pas besoin de viser directement l’application web au sens classique du terme. Il lui suffit d’introduire un artefact malveillant dans un flux de traitement accepté par le backend. C’est exactement la logique des attaques de chaîne d’approvisionnement applicative côté média : la surface d’attaque n’est pas uniquement le code métier visible, mais aussi les bibliothèques natives qui interprètent des formats complexes.

Scénarios d’attaque concrets

Scénario 1 : serveur média familial exposé sur Internet. Un compte utilisateur autorisé à déposer des contenus ajoute une vidéo piégée. Le serveur lance automatiquement l’analyse et la génération de miniatures. Le décodeur vulnérable est invoqué avant même qu’un administrateur n’intervienne. Si la faille est exploitable dans cet environnement, le code s’exécute avec les droits du service Jellyfin ou du worker de transcodage.

Scénario 2 : bibliothèque synchronisée depuis un répertoire partagé. Un NAS, un partage NFS ou SMB, ou un outil de synchronisation dépose un nouveau média dans un dossier surveillé. Le serveur détecte le fichier et appelle FFmpeg. Ici, aucune interaction via l’interface web n’est nécessaire, ce qui rend l’exploitation plausible dans des environnements où plusieurs systèmes ou utilisateurs alimentent la bibliothèque.

Scénario 3 : service mutualisé ou associatif. Plusieurs utilisateurs disposent d’un accès à une médiathèque commune. Une compromission d’un compte peu privilégié peut devenir un point d’entrée vers le serveur lui-même si le pipeline média n’est pas isolé. C’est un cas classique de pivot vertical depuis une permission fonctionnelle légitime vers une compromission technique du backend.

Scénario 4 : conteneur non reconstruit. L’équipe met à jour l’hôte ou lit l’annonce de sécurité de l’application, mais le service tourne dans une image Docker plus ancienne contenant toujours la version vulnérable de FFmpeg. Le faux sentiment de remédiation est fréquent dans les stacks auto-hébergées.

Impact technique possible

Le brief mentionne une RCE possible dans certains scénarios. Sans détails techniques officiels complets, il faut rester prudent sur la portée exacte, mais les impacts à envisager dans un modèle de menace raisonnable sont les suivants :

• exécution de code à distance dans le contexte du processus appelant FFmpeg ;
• déni de service par crash du service ou d’un worker de transcodage ;
• interruption de service sur des environnements à forte dépendance au transcodage ;
• mouvement latéral local si le service compromis a accès à des partages, secrets, jetons API ou sockets Docker ;
• exposition de données si le processus peut lire des bibliothèques, métadonnées, chemins ou fichiers sensibles.

Le pire scénario n’est pas seulement la compromission du serveur média. Sur des hôtes auto-hébergés polyvalents, le même système exécute parfois reverse proxy, téléchargement, indexation, supervision, sauvegarde, voire d’autres applications web. Une compromission du service média peut donc devenir un point d’entrée transversal.

Comment patcher

La remédiation prioritaire consiste à déployer la version corrigée de FFmpeg publiée par l’éditeur amont, ou le paquet corrigé distribué par votre système d’exploitation, puis à redémarrer les services qui l’utilisent. Si votre application embarque sa propre copie de FFmpeg, il faut appliquer la mise à jour fournie par l’éditeur de l’application, en plus ou à la place du paquet système.

Mise à jour via Debian / Ubuntu

Sur les distributions de type Debian ou Ubuntu, commencez par rafraîchir l’index puis appliquez les mises à jour disponibles :

sudo apt update sudo apt install --only-upgrade ffmpeg

Si le serveur média ou l’application concernée est empaqueté séparément, mettez également à jour ce paquet :

sudo apt install --only-upgrade jellyfin

Vérifiez ensuite la version réellement installée :

ffmpeg -version

Enfin, redémarrez le service pour vous assurer qu’il charge bien les bibliothèques mises à jour :

sudo systemctl restart jellyfin

Si vous ne savez pas quel service invoque FFmpeg, un redémarrage ciblé des services multimédia et des workers associés est recommandé après mise à jour.

Mise à jour via RHEL / Rocky / AlmaLinux / Fedora

Sur les distributions utilisant dnf :

sudo dnf upgrade ffmpeg

Si l’application est fournie par un dépôt distinct, appliquez aussi sa mise à jour selon les instructions de l’éditeur :

sudo dnf upgrade jellyfin

Contrôlez la version installée :

ffmpeg -version

Puis redémarrez les services consommateurs.

Mise à jour via Alpine

Pour des conteneurs ou hôtes basés sur Alpine :

sudo apk update sudo apk upgrade ffmpeg

Là encore, une reconstruction de l’image et un redéploiement sont préférables à une modification manuelle d’un conteneur en production.

Cas Docker et conteneurs

Dans les environnements conteneurisés, la bonne pratique est de reconstruire l’image à partir d’une base mise à jour, puis de redéployer. Mettre à jour uniquement l’hôte ne corrige pas une image contenant déjà un binaire vulnérable.

Exemple de séquence générique :

docker compose pull docker compose build --no-cache docker compose up -d

Après redéploiement, vérifiez la version dans le conteneur :

docker exec -it <conteneur> ffmpeg -version

Si vous utilisez une image communautaire, vérifiez la date de rebuild et les notes de version. Une image “récente” n’implique pas automatiquement qu’elle embarque déjà le correctif si le mainteneur n’a pas reconstruit après publication de l’advisory amont.

Compilation ou build embarqué

Pour les équipes qui compilent FFmpeg depuis les sources, il faut récupérer la version corrigée publiée par le projet depuis la source officielle, reconstruire les binaires, déployer, puis redémarrer les services dépendants. En l’absence d’un numéro de version confirmé dans le brief, il est préférable de se référer explicitement à l’annonce amont plutôt que de figer ici une cible possiblement inexacte.

Vérifications post-correctif

Le patching n’est complet que si les vérifications suivantes sont positives :

• la version de FFmpeg en cours d’exécution correspond bien à un build corrigé annoncé par l’éditeur ou la distribution ;
• les services ont été redémarrés après mise à jour ;
• les conteneurs ont été reconstruits et non simplement redémarrés ;
• les nœuds secondaires, workers de transcodage et hôtes annexes ont été traités eux aussi ;
• les applications embarquant leur propre binaire ont reçu leur mise à jour spécifique.

Détection

En l’absence de signatures universelles ou d’IoC officiels détaillés dans le brief, la détection doit se concentrer sur les symptômes d’exploitation, l’inventaire d’exposition et la corrélation d’événements autour du traitement média.

Indicateurs d’exposition

• présence de FFmpeg sur l’hôte ou dans les conteneurs ;
• activation du transcodage, de l’analyse média ou de la génération de miniatures côté serveur ;
• existence de dossiers surveillés automatiquement ;
• possibilité pour des utilisateurs distants d’ajouter ou synchroniser des médias ;
• exécution du service avec des droits étendus sur le système de fichiers ou le réseau local.

IoC comportementaux à surveiller

Faute d’IoC éditeur précis, il est pertinent de surveiller les événements suivants :

• crashs anormaux de processus ffmpeg, jellyfin ou workers associés ;
• apparition de segmentation fault, core dumped ou erreurs mémoire dans journalctl, syslog ou les logs applicatifs ;
• pics CPU ou mémoire lors du scan d’un fichier vidéo particulier ;
• création de processus inattendus enfants de ffmpeg ou du service média ;
• connexions réseau sortantes anormales émises par le service de transcodage ;
• fichiers nouvellement créés dans /tmp, répertoires de cache ou chemins d’application à proximité temporelle d’un import média ;
• redémarrages répétés du service après ingestion d’un contenu spécifique.

Commandes utiles pour l’investigation locale :

journalctl -u jellyfin --since "24 hours ago" journalctl --since "24 hours ago" | grep -Ei "ffmpeg|segfault|core|crash" ps auxf | grep -i ffmpeg ss -plant find /tmp -type f -mtime -1

Dans des environnements supervisés, il faut corréler les journaux d’upload, d’import ou de scan de bibliothèque avec les événements système. Une vidéo précise qui déclenche systématiquement un crash ou un comportement anormal doit être isolée immédiatement pour analyse hors production.

Détection côté conteneur et orchestration

Sur des déploiements conteneurisés, examinez également :

• les logs du runtime et de l’orchestrateur pour des redémarrages inattendus ;
• les événements OOMKilled ou crash loops ;
• les écarts entre l’image déclarée et l’image réellement exécutée sur les nœuds ;
• la présence de shells interactifs ou d’outils non attendus dans les conteneurs applicatifs.

Exemples génériques :

docker logs <conteneur> docker inspect <conteneur> kubectl logs <pod> kubectl describe pod <pod>

Mitigation

Si le correctif ne peut pas être appliqué immédiatement, la réduction de risque doit viser à limiter le traitement de médias non fiables et à contenir l’impact d’une éventuelle exploitation. Aucune mitigation ne remplace la mise à jour, mais plusieurs mesures peuvent réduire significativement l’exposition à court terme.

1. Réduire les entrées non fiables

• désactiver temporairement l’upload ou l’import de médias depuis des utilisateurs non strictement de confiance ;
• suspendre les synchronisations automatiques depuis des sources externes ou partagées ;
• désactiver les bibliothèques collaboratives si elles ne sont pas indispensables ;
• isoler les nouveaux médias dans une zone de quarantaine avant indexation.

Dans un environnement d’entreprise ou associatif, cela peut passer par une règle simple : aucun nouveau contenu n’est ingéré automatiquement tant que la mise à jour n’est pas validée sur tous les nœuds.

2. Désactiver les traitements automatiques non essentiels

Quand l’application le permet, réduire temporairement les fonctions qui déclenchent le décodage côté serveur :

• génération automatique de miniatures ;
• prévisualisations vidéo ;
• analyse approfondie des médias à l’import ;
• transcodage à la volée pour les profils non critiques.

Le but est de diminuer le nombre de chemins de code atteignables avant patch. Le compromis fonctionnel est parfois acceptable quelques heures ou quelques jours face à un risque de compromission serveur.

3. Isoler le processus de transcodage

La mitigation la plus efficace après le patch reste l’isolation. Si FFmpeg doit traiter des données potentiellement hostiles, il ne devrait pas disposer d’un accès large au système.

• exécuter le service sous un compte dédié sans privilèges ;
• restreindre les droits sur les bibliothèques, répertoires de configuration et secrets ;
• interdire l’accès en écriture hors des répertoires strictement nécessaires ;
• appliquer des profils AppArmor ou SELinux quand disponibles ;
• utiliser des options de confinement systemd comme NoNewPrivileges=yes, PrivateTmp=yes, ProtectSystem=strict, ProtectHome=yes lorsque compatibles avec l’application.

Exemple de directives de durcissement systemd à évaluer avant déploiement :

[Service] NoNewPrivileges=yes PrivateTmp=yes ProtectSystem=strict ProtectHome=yes RestrictSUIDSGID=yes RestrictNamespaces=yes

Ces paramètres doivent être testés avec soin, car certaines applications média ont besoin d’accéder à des bibliothèques ou périphériques spécifiques.

4. Cloisonner le réseau

• limiter les sorties réseau du service média si elles ne sont pas nécessaires ;
• éviter de cohéberger sur le même hôte des services sensibles sans segmentation ;
• bloquer l’accès du conteneur ou du service aux sockets d’administration comme /var/run/docker.sock ;
• restreindre l’accès aux partages réseau montés automatiquement.

Une RCE confinée à un service sans privilèges, sans egress libre et sans accès aux secrets, est beaucoup moins grave qu’une RCE sur un hôte polyvalent mal segmenté.

5. Durcir la chaîne de mise à jour

Le cas PixelSmash rappelle qu’une bibliothèque native omniprésente doit être suivie comme un composant critique de supply chain. Les mesures de fond incluent :

• inventaire logiciel des dépendances natives réellement présentes en production ;
• suivi des advisories éditeurs et distributions ;
• rebuild automatique des images conteneur lors de la publication de correctifs de base ;
• SBOM quand possible pour les applications auto-hébergées et images internes ;
• politique de redémarrage contrôlé après mise à jour de bibliothèques sensibles.

Pour les organisations françaises, l’appui des bulletins de sécurité éditeurs et, selon les cas, la veille du CERT-FR peut compléter utilement la surveillance de l’écosystème, même si toutes les vulnérabilités d’applications auto-hébergées n’y font pas nécessairement l’objet d’un bulletin dédié.

Perspective écosystème

Cette correction illustre un problème structurel du web auto-hébergé moderne : des applications perçues comme “simples” reposent en réalité sur des piles logicielles profondes, mêlant code managé, bibliothèques natives, codecs, accélération matérielle, conteneurs et paquets distribution. Une faille dans un décodeur vidéo ne reste pas cantonnée au poste utilisateur : elle remonte désormais jusqu’aux serveurs web qui traitent du contenu média à grande échelle ou de manière automatisée.

Le sujet est particulièrement important pour les administrateurs de petites infrastructures, homelabs et associations, qui utilisent souvent Jellyfin ou des services voisins sur des hôtes mutualisant plusieurs applications. Dans ces contextes, la dette de mise à jour est fréquente : images anciennes, paquets figés, builds communautaires, scripts d’installation non maintenus. La faille rappelle qu’un composant comme FFmpeg mérite le même niveau d’attention qu’un serveur web, un moteur de base de données ou un reverse proxy.

Il faut également retenir la leçon opérationnelle suivante : lorsqu’une application “consomme des fichiers”, elle exécute en pratique du code complexe de parsing sur des données potentiellement hostiles. Le modèle de menace doit donc intégrer les bibliothèques de traitement documentaire, image, audio et vidéo. C’est vrai pour les serveurs média, mais aussi pour des CMS avec génération de vignettes, des plateformes e-learning, des DAM, des solutions de visioconférence et des pipelines CI qui inspectent des artefacts.

La priorité immédiate reste claire : identifier la présence de FFmpeg, appliquer la version corrigée publiée par l’éditeur ou le paquet aval correspondant, reconstruire les conteneurs et restreindre temporairement le traitement de médias non fiables. En complément, un chantier de durcissement plus large est recommandé pour éviter qu’une prochaine faille de parsing ne se transforme en compromission serveur complète. Pour approfondir ces mesures de réduction de surface d’attaque, le hardening des services et l’isolation des composants, voir aussi les ressources pratiques de FailleWeb dans la catégorie /categorie/pratiques.

Source originale mentionnée par l’écosystème : article de BleepingComputer sur la correction de PixelSmash dans FFmpeg, s’appuyant sur la publication amont du projet et les correctifs diffusés par les mainteneurs aval. Tant que l’ensemble des distributions et applications embarquant FFmpeg n’ont pas publié leurs propres paquets mis à jour, la vérification locale des versions réellement exécutées reste indispensable.