Plex corrige plusieurs failles non divulguées et pousse 360 000 serveurs exposés à se mettre à jour
Plex publie Plex Media Server 1.43.3 et Plex Desktop 1.115.0 pour combler plusieurs failles dont les CVE n’ont pas encore été publiées, alors que Censys recense plus de 360 000 interfaces web exposées sur Internet. Mettez à jour serveur et clients, et vérifiez le canal de mise à jour de votre NAS qui peut accuser un retard.
4 septembre 2026. Plex presse ses utilisateurs de mettre à jour leurs instances après la publication d’une mise à jour qui comble plusieurs failles de sécurité non divulguées. Les correctifs sont livrés dans Plex Media Server 1.43.3 et Plex Desktop 1.115.0. Pourquoi c’est important : selon Censys, plus de 360 000 appareils exposent l’interface web de Plex Media Server sur Internet, et l’éditeur n’a pas encore publié les détails techniques des failles — il faut donc patcher à l’aveugle, et vite.
Un correctif sans détails, un risque réel
Plex n’a pas précisé la nature des vulnérabilités corrigées, indiquant seulement que des identifiants CVE ont été demandés. Le conseil tient en une phrase : « Nous recommandons à tous les propriétaires de serveurs et aux utilisateurs de Desktop de mettre à jour dès que possible. » Ce silence éditorial n’est pas une anomalie — c’est la pratique courante quand les CVE ne sont pas encore attribuées — mais il oblige à une mise à jour sans évaluation préalable du risque.
Un détail pratique compte pour les auto-hébergeurs : si vous faites tourner Plex Media Server sur un NAS, la version corrigée peut ne pas être encore disponible dans le gestionnaire de paquets de l’appareil. Plex recommande alors d’installer le paquet manuellement plutôt que d’attendre la mise à disposition automatique.
Un historique qui pèse dans la balance
Ce correctif n’arrive pas dans un vide. Plex a déjà été le théâtre de failles sérieuses, et sa surface d’exposition est documentée.
En août 2025, Plex a corrigé CVE-2025-34158 (CVSS 8.5), un bogue d’authentification : l’endpoint /myplex/account exposait les détails du compte du propriétaire — dont son jeton d’accès administratif — à tout utilisateur authentifié non propriétaire ou à faibles privilèges. Un second appel à /api/resources permettait ensuite de révéler les autres serveurs accessibles par ce propriétaire. Combinées, ces deux failles formaient une chaîne d’exploitation menant à la découverte de toute l’infrastructure Plex d’une victime.
L’histoire la plus grave remonte à août 2022. L’intrusion de LastPass a été facilitée par l’implantation d’un enregistreur de frappe sur l’ordinateur personnel d’un employé, compromis à travers une faille de Plex Media Server — CVE-2020-5741 (CVSS 7.2). Un serveur multimédia personnel est ainsi devenu le point d’entrée d’une des brèches les plus médiatisées de la décennie.
En février 2021 encore, Plex corrigeait une faille qui permettait à un attaquant de faire « réfléchir » un serveur en le poussant à amplifier des paquets UDP pour gonfler une attaque par déni de service. Le correctif (Plex Media Server 1.21.3.4014) imposait au serveur de ne répondre aux requêtes UDP qu’en provenance du réseau local, plus de l’Internet.
360 000 interfaces exposées
Le chiffre de Censys donne la mesure du problème : plus de 360 000 appareils exposent l’interface web de Plex Media Server sur Internet. Tous ne sont pas vulnérables, mais chacun représente une surface d’attaque potentielle. Plex est, par nature, le service auto-hébergé que l’on ouvre volontiers à l’extérieur — pour regarder sa bibliothèque depuis l’extérieur, la partager avec la famille, ou la servir à des clients distants.
C’est précisément ce confort qui se paie. Une interface Plex exposée sans correctif est une cible facile pour des robots qui scannent en permanence les services multimédia. La mise à jour d’un NAS étant souvent retardée par le canal du fabricant, la fenêtre pendant laquelle une instance reste vulnérable s’allonge d’autant.
Pourquoi on patch à l’aveugle
L’absence de détails techniques n’est pas un caprice de Plex : c’est le fonctionnement normal de la divulgation coordonnée. Quand un chercheur signale une faille, l’éditeur prépare un correctif, le distribue, puis publie les détails — et les CVE — une fois qu’une partie du parc a eu le temps de se mettre à jour. Révéler la technique avant le correctif reviendrait à offrir un mode d’emploi aux attaquants.
Pour l’utilisateur, cela impose un acte de foi temporaire : mettre à jour sans savoir ce qu’on corrige. C’est le contrat classique du self-hosting : vous gérez la sécurité de services que vous exposez, parfois sans visibilité sur le risque exact. La seule réponse rationnelle est la réactivité — appliquer les mises à jour dès leur publication, et traiter toute instance exposée comme une cible jusqu’à preuve du contraire.
Plex, Jellyfin et la question de l’exposition
Plex n’est pas la seule option pour héberger sa bibliothèque multimédia. Jellyfin et Emby offrent des fonctionnalités comparables avec des modèles différents — Jellyfin étant entièrement libre et sans dépendance à un compte tiers. Ce choix a une incidence directe sur la sécurité : Plex couple le serveur local à un compte en ligne et à des services distants, ce qui élargit la surface d’attaque au-delà du simple serveur.
Mais changer de logiciel n’est pas une stratégie de sécurité à part entière. La vraie frontière n’est pas entre Plex et Jellyfin, mais entre un serveur exposé directement et un serveur accessible uniquement via VPN ou reverse proxy authentifié. Quelle que soit la solution retenue, un service multimédia exposé sans correctif reste une cible ; un service patché et segmenté ne l’est plus. Le verdict qui suit tient compte de cette distinction.
Ce qu’il faut faire
- Mettre à jour immédiatement. Appliquer Plex Media Server 1.43.3 et Plex Desktop 1.115.0. Si le NAS n’a pas encore la version, installer le paquet manuellement.
- Vérifier l’exposition. Si l’interface web de Plex est accessible depuis Internet, la protéger par un reverse proxy avec authentification ou la réserver à un VPN.
- Contrôler le canal de mise à jour. Sur un NAS, suivre la disponibilité du paquet chez le fabricant et ne pas compter sur une mise à jour silencieuse.
Ces trois gestes dépassent le cadre de ce correctif : ils réduisent durablement le risque d’une classe de failles qui, chez Plex, a déjà mené à des brèches majeures.
Mettre à jour selon son installation
La voie de mise à jour dépend de l’installation. Sous Docker, un simple redéploiement de l’image suffit ; sous Linux, le paquet suit le dépôt Plex ; sur un NAS — Synology, QNAP, TrueNAS — le paquet passe par l’écosystème du fabricant, souvent avec un délai de plusieurs jours. Ce délai n’est pas neutre : c’est exactement la fenêtre pendant laquelle une instance reste vulnérable alors qu’un correctif public existe déjà.
# Docker : redéployer l’image Plex à jour
docker pull plexinc/pms-docker:latest
docker restart plexLe chiffre de Censys donne le contexte. Plus de 360 000 interfaces exposées signifient que toute faille Plex rendue publique devient une opportunité de scan massif en quelques heures. Une instance laissée sur un canal NAS en retard n’est pas un risque théorique : c’est une machine déjà listée dans les résultats d’un scanner, en attente d’une charge utile qui existe déjà.
Verdict
Si votre serveur Plex est exposé sur Internet, mettez à jour vers 1.43.3 dès maintenant, sans attendre la publication des CVE : les failles sont corrigées, pas documentées, et plus de 360 000 instances sont à portée des scanners.
Si votre Plex vit sur un NAS, forcez l’installation manuelle du paquet plutôt que d’attendre le canal du fabricant — c’est là que la fenêtre de risque se prolonge.
Si vous voulez réduire le risque structurel, sortez Plex de l’exposition directe : un VPN ou un reverse proxy authentifié transforme une cible scannable en service interne.