Plex est exploité. Le correctif existait onze semaines plus tôt.

Un serveur multimédia est la chose la plus anodine à exposer sur internet. C’est aussi, ce mois-ci, la plus coûteuse.

Le 20 octobre 2026, la CISA a ajouté d’un coup quatre vulnérabilités de Plex Media Server à son catalogue des failles activement exploitées. Chaînées, elles permettent à un attaquant sans identifiants d’obtenir un jeton d’administration et d’exécuter du code avec les droits du processus Plex. Le chercheur qui les a trouvées note la chaîne 9,8.

La version corrigée, 1.43.3.10861, est sortie le 4 août. Tout ce qui s’est passé depuis concerne l’écart entre un correctif qui existe et un correctif qui est installé, et cet écart est la seule partie de l’histoire qui dépend de vous.

La chronologie, car c’est elle l’argument

Onze semaines d’avertissement. Trente-six mille serveurs qui ne s’en sont pas servis.

Ce qu’est réellement la chaîne

Quatre défauts, chacun banal isolément, et c’est précisément pour cela qu’ils sont passés inaperçus :

• CVE-2026-96652 (CVSS 5,3), falsification de requête côté serveur : on peut faire envoyer à Plex des requêtes POST vers des destinations arbitraires, y compris ses propres API internes.
• CVE-2026-96654 (CVSS 6,9), injection d’URL : des paramètres contrôlés par l’attaquant atteignent les fonctions d’autres plugins.
• CVE-2026-96655 (CVSS 5,3), une autre SSRF, celle-ci dans le point d’entrée du transcodeur.
• CVE-2026-96656 (CVSS 8,6), écriture de fichier arbitraire dans les réglages du transcodeur : une bibliothèque partagée peut être déposée là où Plex la chargera.

Relisez le dernier point, car c’est le schéma à transposer à tous vos autres services : un processus qui écrit des fichiers, puis charge du code depuis le répertoire où il écrit, n’est qu’à un bug d’écriture d’une exécution de code. Codecs, plugins, thèmes, extensions, téléversements avec chemin d’inclusion. Les scores individuels sont moyens. La chaîne vaut 9,8.

L’exploitation exige un accès réseau au port TCP 32400. La fonction Remote Access de Plex, ou une redirection de port manuelle, est ce qui transforme un service de salon en service exposé.

Trois choses à faire d’abord

1. Vérifiez le numéro de build complet, pas la version commerciale.

# installation par paquet Debian ou Ubuntu
dpkg -s plexmediaserver | grep '^Version'
# image Docker officielle
docker exec plex dpkg -s plexmediaserver | grep '^Version'
# n'importe quelle installation, depuis la machine : le point d'entrée identity répond sans jeton
curl -s http://127.0.0.1:32400/identity

Tout ce qui est antérieur à 1.43.3.10861 est affecté. Un build 1.43.3 précoce l’est encore : ce sont les cinq derniers chiffres qui comptent.

2. Mettez à jour, puis vérifiez que le processus en cours est bien le nouveau. Un conteneur jamais re-téléchargé, ou un paquet retenu par un pin, affichera volontiers une nouvelle version dans l’interface alors que l’ancien binaire tourne toujours.

docker compose pull plex && docker compose up -d plex
docker exec plex dpkg -s plexmediaserver | grep '^Version'

3. Si le serveur était joignable depuis internet avec un ancien build, supposez qu’il a été joint. L’avis de Plex demande de traiter ces serveurs comme potentiellement compromis et donne des indicateurs : des fichiers .so ou .dll inconnus dans le répertoire Codecs, et des connexions sortantes vers proxystream.st. Vérifiez les deux avant de considérer l’affaire close :

# bibliothèques partagées inattendues dans le répertoire des codecs
find ~/Library/Application\ Support/Plex\ Media\ Server/Codecs \
     /var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/Codecs \
     -name '*.so' -o -name '*.dll' 2>/dev/null | sort

# tout ce avec quoi la machine échange et que vous ne savez pas nommer
ss -tn state established | awk 'NR>1{print $4}' | sort | uniq -c | sort -rn | head -20

Un mineur se signale par le processeur. Le proxyware non : il revend votre adresse comme bande passante résidentielle et reste discret. L’absence de charge n’est pas l’absence de compromission.

La checklist qui vous aurait sauvé de toute façon

Rien de ce qui suit n’exige de connaître une CVE à l’avance. C’est tout l’intérêt : ces mesures paient pendant les semaines où vous n’avez pas encore corrigé, c’est-à-dire pour chaque service, en permanence.

Ne redirigez pas un port vers internet juste pour y accéder vous-même. Remote Access et une redirection de port existent pour servir des gens qui ne sont pas sur votre réseau. Si le seul utilisateur distant c’est vous, un tunnel WireGuard ou un VPN maillé supprime la surface d’attaque au lieu de la défendre. L’exposition est une décision, et la plupart du temps personne ne la prend délibérément.

Refus par défaut en entrée, avec les ports ouverts écrits noir sur blanc. Sur une machine qui héberge plusieurs choses, le pare-feu est le seul endroit où « qu’est-ce qui est joignable » tient en un écran :

ufw default deny incoming
ufw allow 443/tcp
ufw status numbered

Lisez la sortie de haut en bas et demandez-vous ce qui correspond en premier. Sur une machine héritée auditée ce mois-ci, une liste d’autorisation soignée de trois sous-réseaux se trouvait quatre lignes sous un ACCEPT global pour le même port depuis 0.0.0.0/0 : elle n’avait donc jamais rien restreint. L’audit complet est ici.

Placez les services HTTP derrière un seul reverse proxy, jamais directement sur internet. Une configuration TLS, un journal d’accès, un seul endroit où ajouter de l’authentification. Le schéma que nous faisons tourner sur ce site même est détaillé dans Caddy et Docker en production. La version courte, pour un service qui n’a besoin d’aucun accès public :

media.example.com {
    @notlocal not remote_ip 10.0.0.0/8 100.64.0.0/10 192.168.0.0/16
    respond @notlocal 403
    reverse_proxy 127.0.0.1:32400
}

Liez le service à localhost et faites du proxy la seule porte. Un conteneur publié avec -p 32400:32400 écoute sur toutes les interfaces de l’hôte, y compris la publique ; -p 127.0.0.1:32400:32400 non. Cette différence de quelques caractères est l’exposition accidentelle la plus fréquente que nous rencontrons.

Considérez le trafic sortant comme quelque chose dont vous avez le droit de vous soucier. Les deux charges observées ici, le mineur et le proxyware, ne servent à rien sans sortie réseau. Une machine domestique ou de petit bureau n’a aucune raison d’ouvrir des connexions sortantes arbitraires, et une ligne de base comparable vaut mieux que n’importe quelle liste d’IOC publiée après coup.

Sachez comment vous reconstruiriez, et testez-le. Après ce type de compromission, le conseil honnête est une réinstallation propre, ce qui n’est tenable que si vos données sont ailleurs et que la restauration est un geste déjà fait, pas un apprentissage sous pression. Où doit être cet ailleurs, avec de vrais prix sur de vraies données, c’est dans notre comparatif des stockages de sauvegarde.

Abonnez-vous aux notes de version de tout ce que vous exposez. Onze semaines, ce n’est pas un intervalle malchanceux, c’est une liste de diffusion non lue. Pour un service auto-hébergé, l’éditeur n’a aucun moyen de vous joindre, et aucune obligation d’essayer.

Ce que nous ne savons pas

Nous n’avons pas examiné nous-mêmes l’intérieur d’une machine compromise, et nous n’allons pas faire semblant. Les indicateurs ci-dessus viennent de Plex, les chiffres d’exposition de Shadowserver, les scores CVSS du chercheur, et les dates d’exploitation des éditeurs et de la CISA. Notre apport, c’est la partie que nous assumons : ce que ce schéma implique pour le reste de votre stack, et la configuration que nous faisons réellement tourner.

FAQ

Quelle version de Plex corrige Plex2Shell ? La 1.43.3.10861 et au-delà, sortie le 4 août 2026. Les builds antérieurs sont affectés, y compris les premiers 1.43.3.

Mon serveur Plex est-il en danger s’il n’est pas exposé à internet ? La chaîne exige un accès réseau au port TCP 32400. Un serveur joignable seulement depuis votre réseau local reste exploitable depuis ce réseau : un portable compromis ou un appareil invité suffit. C’est un risque plus faible, pas un risque théorique.

Comment savoir si mon serveur Plex a déjà été compromis ? L’avis de Plex pointe deux indicateurs : des fichiers .so ou .dll inconnus dans le répertoire Codecs, et des connexions sortantes vers proxystream.st. Les charges observées sont des mineurs et des logiciels proxy. Si le serveur était exposé avec un ancien build, l’hypothèse sûre est la compromission.

La mise à jour supprime-t-elle une compromission existante ? Non. Le correctif ferme la porte, il n’enlève rien de ce qui est déjà entré. Après une compromission confirmée, le seul chemin propre est une reconstruction depuis des supports sains et une restauration de données vérifiables.

Dois-je simplement désactiver Remote Access ? Si la seule personne qui regarde depuis l’extérieur, c’est vous, oui, et passez par un VPN. Remote Access est la fonction qui met le port 32400 sur internet, et les 36 000 serveurs exposés comptés en septembre n’étaient pour la plupart pas des décisions délibérées.

La suite

Si cela vous a donné envie de regarder le reste de votre stack, l’audit d’une heure pour un serveur hérité est la checklist que nous appliquons à une machine inconnue, et le comparatif VPS traite de l’endroit où placer un service que vous préférez ne pas héberger chez vous.