Plex2Shell : la chaîne d’exploitation de Plex Media Server passe du PoC au minage en 24 heures

16 octobre 2026. Le chercheur Zach Main publie le proof of concept Plex2Shell, qui chaîne quatre failles de Plex Media Server — de CVE-2026-96652 à CVE-2026-96656 — en une exécution de code à distance non authentifiée. 17 octobre 2026. Un honeypot enregistre la première exploitation en conditions réelles. Septembre 2026. Plex avait déjà publié le correctif, sans que les CVE soient rendues publiques. Pourquoi c’est important : le serveur multimédia que vous exposez sur Internet pour regarder vos films de l’extérieur est désormais une cible instrumentée, convertie en mineur de cryptomonnaie et en nœud proxy résidentiel moins de vingt-quatre heures après la publication du PoC.

La chaîne Plex2Shell, en quatre failles

Plex2Shell est le nom donné à la combinaison de quatre vulnérabilités de Plex Media Server, référencées CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 et CVE-2026-96656. Prises séparément, elles sont limitées ; chaînées, elles permettent à un attaquant sans identifiant d’exécuter du code arbitraire sur un serveur exposé, avec les privilèges du service Plex.

Le mécanisme final est aussi élégant que redoutable. Plex charge des bibliothèques partagées lors du transcodage, et son chargeur ne vérifie ni le préfixe lib, ni le bit d’exécution, ni la signature, ni les symboles attendus. Un fichier .so déposé au bon endroit voit son constructeur ELF s’exécuter dès le chargement — le code tourne alors en tant que uid=1000(plex), sans qu’aucune session interactive n’ait été établie.

La chronologie de la divulgation est exemplaire. Plex a été notifié le 27 juillet 2026 et a accusé réception le 4 août, en versant une bug bounty au chercheur. Les correctifs ont été publiés en septembre, avant que l’exploit ne devienne public. C’est précisément le scénario que nous avions documenté à l’époque : un correctif sans détails, poussé « à l’aveugle ». On sait désormais ce que ce correctif colmatait.

Vingt-quatre heures entre le PoC et l’exploitation

La vitesse de l’instrumentalisation est le chiffre qui doit faire réfléchir. Le 16 octobre 2026, Zach Main publie le détail technique et le PoC sur son blog. Le 17 octobre, un chercheur qui surveille un honeypot Plex vulnérable rapporte avoir observé une exploitation en conditions réelles — la première de la campagne.

Ce que les attaquants ont déployé est tout aussi instructif. Le premier payload est un mineur basé sur XMRig, qui consomme CPU et électricité. Le second, repéré le même jour, se nomme myawesomeproxy : il transforme le serveur compromis en nœud proxy, permettant à d’autres de faire transiter leur trafic à travers votre connexion. Pour un serveur Plex hébergé sur une IP résidentielle, c’est un cadeau de choix : les attaquants adorent disposer de proxies résidentiels pour contourner les blocages et atteindre des services d’entreprise.

La leçon est brutale : un Plex exposé n’est plus seulement une bibliothèque multimédia, c’est une machine rentable. Le minage monétise votre électricité ; le proxy monétise votre réputation d’adresse IP.

Pourquoi Plex est une cible à part

Plex occupe une position singulière dans le monde du self-hosting. C’est l’un des serveurs que l’on expose volontiers à Internet — pour regarder sa bibliothèque en déplacement, la partager avec la famille, ou servir des clients distants. Le réflexe d’ouvrir le port est encouragé par le produit lui-même, qui repose sur un accès à distance centralisé.

Cette exposition se mesure. En septembre 2026, Censys recensait plus de 360 000 interfaces web Plex accessibles depuis Internet. Tous ces serveurs ne sont pas vulnérables, mais chacun est une cible scannée en permanence par des robots. Un correctif public sans mise à jour appliquée transforme cette surface en opportunité.

Le facteur aggravant, propre au self-hosting, est le canal de mise à jour. Sur un NAS — Synology, QNAP, TrueNAS — le paquet Plex passe par l’écosystème du fabricant, souvent avec un retard de plusieurs jours. Une instance laissée sur ce canal reste vulnérable alors même que le correctif et le PoC sont publics : c’est exactement la fenêtre que les attaquants exploitent.

Ce qu’il faut faire maintenant

La priorité absolue est de mettre à jour vers Plex Media Server 1.43.3.10861 ou une version ultérieure — la version qui neutralise les quatre failles. Les installations concernées couvrent les NAS, les machines virtuelles et les conteneurs Docker : le correctif est le même, mais la voie d’installation diffère.

# Docker : redéployer l'image Plex à jour
docker pull plexinc/pms-docker:latest
docker restart plex

La mise à jour seule ne suffit pas si le serveur reste exposé. Deux gestes de fond s’imposent :

• Sortir Plex d’Internet. Remplacez l’exposition directe par un VPN (Tailscale, WireGuard) ou un reverse proxy avec authentification. Un serveur inaccessible depuis Internet ne peut pas être scanné ni exploité à distance.
• Chasser les signes de compromission. Une exploitation Plex2Shell laisse des traces : des processus enfants inattendus lancés par Plex, une consommation CPU anormale, des fichiers inconnus dans le répertoire Codecs, et des connexions sortantes vers des adresses inconnues. Un mineur ou un proxy ne se cachent pas toujours derrière un nom de fichier fixe : la détection doit reposer sur le comportement, pas sur une liste d’indicateurs figés.

Détecter une instance compromise

Une exploitation Plex2Shell se repère avant tout par le comportement du serveur, pas par un nom de fichier. Le mineur et le proxy observés dans la campagne portent des noms interchangeables — XMRig, myawesomeproxy — mais leurs effets, eux, ne mentent pas.

Quatre signaux doivent déclencher une vérification immédiate :

• Des processus enfants inattendus. Plex lance peu de processus fils ; un mineur ou un proxy apparaît comme un processus étranger rattaché au service.
• Un CPU anormalement chargé. Un mineur XMRig sature un cœur en continu, même sans transcodage en cours.
• Des fichiers inconnus dans le répertoire Codecs. C’est là que la chaîne dépose sa bibliothèque .so avant le second transcodage.
• Des connexions sortantes vers des adresses inconnues. Le proxy relaie du trafic ; ss ou netstat révèlent les flux sortants.

# Processus enfants de Plex et charge CPU
ps -o pid,ppid,pcpu,comm -u plex
# Connexions sortantes de l'instance
ss -tnp | grep plex

Aucun de ces signaux n’est décisif seul — un transcodage légitime charge le CPU, et Plex ouvre des connexions sortantes vers ses services distants. C’est la conjonction qui compte : un processus étranger, un cœur saturé et des fichiers inconnus dans Codecs, ensemble, signent presque à coup sûr une compromission.

Un avertissement pour tout serveur auto-hébergé

Plex2Shell dépasse le cas Plex. Il illustre la règle qui gouverne le self-hosting depuis des années : n’exposez sur Internet que ce qui doit absolument l’être, et jamais sans couche d’authentification ou de tunnel.

Les chercheurs qui suivent la campagne le disent sans détour : ils s’attendent à ce que les attaquants déploient des payloads plus sophistiqués, et le proxy résidentiel observé dès le premier jour suggère un objectif au-delà du simple minage. Un serveur Plex sur une IP résidentielle peut devenir le point d’entrée pour atteindre des VPN d’entreprise ou des services qui filtrent les infrastructures suspectes.

La réponse n’est pas de fuir Plex vers Jellyfin ou Emby en espérant que le problème disparaisse. La frontière de sécurité réelle ne passe pas entre les logiciels, mais entre un serveur exposé directement et un serveur accessible uniquement via un tunnel authentifié. Quel que soit le logiciel, la première faille de ce type fera la même chose : scanner, exploiter, monétiser.

Verdict

Si votre serveur Plex est exposé sur Internet, mettez-le à jour vers 1.43.3.10861 immédiatement, puis sortez-le de l’exposition directe — un VPN ou un reverse proxy authentifié transforme une cible scannable en service interne. Si votre Plex vit sur un NAS, forcez l’installation manuelle du paquet sans attendre le canal du fabricant : c’est là que la fenêtre de risque se prolonge. Si vous n’êtes pas certain d’être à jour, vérifiez la version installée et chassez les signes de compromission — processus enfants, CPU, fichiers inconnus dans Codecs, connexions sortantes. Une bibliothèque multimédia ne vaut pas une machine transformée en mineur et en relais pour le compte d’un tiers.

Références

• Security Affairs — Plex2Shell Exploit Used to Turn Vulnerable Plex Servers Into Crypto Miners (19 octobre 2026)
• The Hacker News — Hackers Exploit Plex2Shell Flaws to Install Crypto Miners and Linux Proxy Backdoor (19 octobre 2026)
• Zach Main — Plex2Shell, analyse technique
• Plex Forum — Important Security Update for Plex Media Server