Des attaquants exploitent déjà des failles de Plex Media Server pour installer un mineur de cryptomonnaie et une porte dérobée sur des serveurs non à jour. Des attaques réussies ont été documentées contre un honeypot le 17 octobre 2026. Le correctif existe pourtant depuis la version 1.43.3.10861, publiée le 3 août 2026 : un serveur mis à jour depuis cette date n’est vraisemblablement pas exposé à Plex2Shell sous sa forme publique. Un serveur plus ancien doit être mis à jour sans attendre.
Un correctif disponible deux mois avant les premières attaques
La chronologie est courte. Le 27 juillet 2026, le chercheur Zach Main signale quatre vulnérabilités à Plex. Elles sont corrigées dans la 1.43.3.10861 le 3 août. Les détails techniques de la chaîne d’attaque, baptisée Plex2Shell, sont rendus publics le 16 octobre, et des tentatives d’exploitation dans la nature sont enregistrées dès le lendemain, selon The Hacker News, CyberSecurityNews, Neowin, Ars Technica et Gizmodo.
Le risque était donc évitable : entre le correctif et la publication de l’exploit, plus de deux mois se sont écoulés. Ce qui sépare un serveur exposé d’un serveur protégé, c’est la version installée. Avant la 1.43.3.10861, le serveur est vulnérable ; à partir de cette version, le correctif est présent.
L’exposition à Internet change aussi l’équation. Un serveur joignable depuis l’extérieur est la cible évidente d’une exploitation en ligne. Pour un serveur uniquement local, l’ampleur du risque n’est pas établie par les sources consultées : mieux vaut mettre à jour dans tous les cas.
Comment une requête mène à l’exécution de code, et ce que les pirates installent
Plex2Shell enchaîne quatre failles (CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 et CVE-2026-96656). La chaîne démarre par une requête non authentifiée qui déclenche une SSRF, c’est-à-dire une requête forcée par le serveur vers une destination choisie par l’attaquant, et aboutit à l’exécution d’un fichier sur la machine. La plus sévère, CVE-2026-96656, affiche un score CVSS de 8,6 : elle permet d’écrire puis d’exécuter un objet partagé ELF dans le répertoire Codecs. Aucune de ces failles ne donne seule le contrôle total ; c’est leur enchaînement qui ouvre la porte.
L’exploit supporte Linux et Windows. L’activité observée sur le honeypot visait toutefois un Plex Linux sous Docker ; le cas Windows n’est pas documenté en attaque réelle.
Deux charges sont déposées. La première est un cryptomineur XMRig, nommé « mylovelyminer », qui sollicite le processeur du serveur. La seconde est un proxy Linux, « myawesomeproxy », qui agit comme un proxy IP résidentiel et avertit que son exécution permet à des tiers d’utiliser la connexion internet de la victime. L’enjeu dépasse donc un CPU qui chauffe : des inconnus peuvent faire transiter leur trafic par votre ligne, et vos propres adresses IP risquent d’être associées à des activités que vous ignorez.
Vérifier la version et mettre à jour, Docker compris
La marche à suivre tient en quelques gestes.
- Relevez la version de Plex Media Server installée sur votre machine (NAS, PC, Raspberry Pi ou conteneur).
- Comparez-la à la 1.43.3.10861 : si elle est plus ancienne, mettez à jour immédiatement vers cette version ou une plus récente.
- Sous Docker, ne comptez pas sur une mise à jour automatique : elle n’est pas garantie dans toutes les configurations. Vérifiez la version réellement exécutée par le conteneur après la mise à jour.
- Si le serveur est resté non patché alors qu’il était joignable depuis Internet, contrôlez-le : la mise à jour corrige la faille, mais ne supprime pas un malware déjà installé.
Pour ce contrôle, deux signes doivent alerter : une surcharge anormale du processeur sans activité de lecture ou d’indexation qui l’explique, et un trafic réseau inhabituel. Les sources consultées ne fournissent pas d’autre indicateur fiable que les noms des charges, « mylovelyminer » et « myawesomeproxy » ; inutile de chercher plus loin sans eux. En cas de doute sur une infection avérée, la suite dépend de votre installation et relève d’un choix plus lourd (analyse de la machine, voire réinstallation).
Si votre serveur est branché derrière une baie de brassage, un câble ou une prise RJ45 mal testés peuvent aussi expliquer des ralentissements réseau : écartez cette piste avant de conclure à une compromission sur la seule foi d’un débit en baisse.
Une réserve s’impose : un serveur à jour est vraisemblablement protégé contre Plex2Shell sous sa forme publique, ce qui ne vaut pas garantie contre toute autre faille ou configuration. L’information reste évolutive : de nouvelles versions ou de nouvelles attaques peuvent encore être signalées.
Checklist rapide :
- Version du serveur relevée et comparée à la 1.43.3.10861
- Mise à jour effectuée si la version est plus ancienne, avec vérification de la version réellement active (Docker inclus)
- Serveur joignable depuis Internet sans correctif jusqu’ici : contrôle du processeur et du trafic réseau