Plex2Shell : des serveurs Plex exploités pour miner de la cryptomonnaie

Plex2Shell : quatre failles chaînées pour exécuter du code à distance

Le 16 octobre 2026, le chercheur en sécurité Zach Main a publié les détails techniques et une preuve de concept (PoC) de Plex2Shell, une chaîne de quatre vulnérabilités dans Plex Media Server permettant l'exécution de code à distance (RCE) sans aucune authentification. Dès le lendemain, des attaquants exploitaient activement la chaîne pour déployer un cryptominer XMRig et une backdoor proxy sur les serveurs exposés (source : Plex).

Toutes les versions de Plex Media Server antérieures à 1.43.3.10861 sont vulnérables. Le correctif est disponible depuis le 3 août 2026, mais selon Shadowserver, plus de 36 000 instances Plex restaient exposées sur internet sans le correctif en septembre 2026. Si vous hébergez Plex sur un VPS Linux ou un serveur dédié, cet article détaille la menace, les signes de compromission et les mesures à prendre pour administrer correctement votre serveur.

Plex Media Server est un logiciel d'auto-hébergement populaire que de nombreux administrateurs installent sur un serveur privé virtuel (VPS) ou une machine dédiée pour diffuser leurs contenus multimédia à distance. Hébergé sur une machine virtuelle chez un hébergeur comme ElypseCloud, le serveur Plex bénéficie de ressources garanties (processeur, RAM, stockage SSD) mais reste exposé aux mêmes risques de sécurité que tout service accessible depuis internet. La virtualisation KVM isole chaque serveur virtuel, mais un processus compromis à l'intérieur du VPS conserve tous les droits du service Plex et peut exploiter l'intégralité des ressources allouées.

La chaîne d'attaque en quatre étapes

Plex2Shell enchaîne quatre CVE pour passer d'une requête HTTP non authentifiée à l'exécution de code arbitraire avec les droits du processus Plex :

Concrètement, l'attaquant envoie une requête au endpoint /player/timeline pour contourner la validation du jeton (étape 1), injecte une URL qui appelle l'API interne des plugins (étape 2), obtient le jeton admin du propriétaire du serveur via le transcodeur (étape 3), puis utilise ce jeton pour écrire un fichier malveillant (.so sous Linux, .dll sous Windows) dans le répertoire Codecs de Plex (étape 4). Le fichier est chargé automatiquement au prochain transcodage et le serveur exécute le code de l'attaquant sans qu'aucun mot de passe n'ait été saisi.

Exploitation active : cryptominer et backdoor proxy

Les attaques observées en conditions réelles déploient deux charges utiles sur le serveur compromis :

• XMRig : un mineur de cryptomonnaie Monero (XMR) qui consomme l'intégralité des ressources processeur du serveur. Le processus observé sur les honeypots porte le nom mylovelyminer.
• Backdoor proxy résidentiel : un service (myawesomeproxy) qui transforme le serveur compromis en proxy résidentiel. Le trafic d'autres utilisateurs transite par votre adresse IP, ce qui peut impliquer votre serveur dans des activités malveillantes. Des connexions vers le domaine proxystream.st sont un indicateur de cette backdoor.

Le 20 octobre 2026, la CISA (Cybersecurity and Infrastructure Security Agency) a ajouté les quatre CVE à son catalogue Known Exploited Vulnerabilities (KEV), confirmant l'exploitation active à grande échelle.

Impact sur les ressources du serveur

Le cryptominer XMRig a un impact direct sur les performances de votre serveur virtuel, qu'il soit hébergé sur un VPS ou un serveur dédié :

• Processeur : le minage Monero utilise tous les coeurs disponibles à 100 %. Sur un VPS avec 4 vCPU, les quatre coeurs du processeur sont monopolisés en permanence. Tout autre service hébergé sur le même serveur (serveur web, base de données, serveur de jeu) devient inutilisable.
• RAM : XMRig consomme entre 256 Mo et 2 Go de RAM selon la configuration du minage. Sur un VPS disposant de peu de mémoire vive, le système peut commencer à swapper sur le disque, dégradant encore les performances.
• Espace disque et SSD : les binaires malveillants (mineur, backdoor proxy, bibliothèque .so dans le répertoire Codecs) occupent peu d'espace disque, mais le swap intensif et les logs générés par l'activité réseau du proxy peuvent saturer un SSD de petite capacité sur un serveur virtuel d'entrée de gamme.
• Bande passante : la backdoor proxy route le trafic d'utilisateurs tiers via votre serveur. Selon votre forfait chez votre hébergeur, ce trafic non sollicité peut entraîner des frais de dépassement ou un bridage réseau.

Sur un serveur qui héberge aussi un serveur web (Apache ou Nginx), un serveur de jeu ou tout autre service, le minage monopolise le processeur et la RAM au point de rendre ces services inaccessibles. Un script de monitoring comme htop permet d'identifier rapidement le processus responsable.

Chronologie des événements

Détecter un serveur Plex compromis

Si votre Plex Media Server tournait en version antérieure à 1.43.3.10861 avec un accès direct depuis internet (port 32400 ouvert dans le firewall), vérifiez les signes suivants :

• Processeur à 100 % en permanence : le mineur XMRig monopolise tous les coeurs du processeur. Vérifiez avec htop ou btop (guide monitoring VPS Linux). Un processus nommé mylovelyminer ou consommant 100 % du processeur de façon continue est un indicateur clair de compromission.
• Processus inconnus : recherchez des binaires suspects dans /tmp, /var/tmp ou le répertoire de données Plex. Un processus myawesomeproxy indique la présence de la backdoor proxy.
• Fichiers suspects dans le répertoire Codecs : vérifiez les bibliothèques partagées (.so sous Linux, .dll sous Windows) dans le répertoire Codecs de Plex. L'attaque y dépose un fichier malveillant chargé automatiquement par le service au prochain transcodage.
• Connexions réseau inhabituelles : des connexions sortantes vers des pools de minage Monero, vers le domaine proxystream.st ou des serveurs proxy inconnus. Listez les connexions actives avec ss -tunap (guide ports et connexions Linux).
• Consommation de RAM anormale : si htop affiche une utilisation de RAM élevée sans rapport avec vos services habituels, le mineur ou la backdoor en est probablement la cause.

# Vérifier les processus suspects
ps aux | grep -iE "mylovelyminer|myawesomeproxy|xmrig"

# Lister les connexions sortantes inhabituelles
ss -tunap | grep ESTAB

# Vérifier les connexions vers le domaine de la backdoor proxy
ss -tunap | grep proxystream

# Vérifier la version de Plex installée
/usr/lib/plexmediaserver/Plex\ Media\ Server --version

Corriger : mettre à jour Plex Media Server

La seule correction est la mise à jour vers Plex Media Server 1.43.3.10861 ou une version ultérieure. Si vous avez installé le package Plex depuis le dépôt officiel sur votre VPS Ubuntu ou Debian :

sudo apt update
sudo apt install --only-upgrade plexmediaserver
# Vérifier la version du package installé
dpkg -l plexmediaserver

Si vous utilisez Plex via Docker, tirez la dernière image et recréez le conteneur (guide Docker Compose VPS Linux) :

docker compose pull plex
docker compose up -d plex

Si votre serveur est compromis (processus suspects, fichiers .so inconnus dans le répertoire Codecs), la mise à jour seule ne suffit pas. Plex recommande de reconstruire le serveur depuis une installation propre et de supprimer le contenu du répertoire Codecs. Réinitialisez votre mot de passe Plex, déconnectez tous les appareils liés à votre compte et restaurez vos données depuis un backup vérifié.

Sauvegarder et reconstruire après une compromission

Si vous confirmez que votre serveur a été compromis, la reconstruction complète est la seule approche fiable. Voici les étapes à suivre pour administrer correctement la remise en service :

1. Sauvegarder les données multimédia : copiez votre bibliothèque (films, séries, musique) vers un espace de stockage externe avec rsync (guide backup rsync). Ne copiez pas les binaires Plex ni le répertoire Codecs : ils sont potentiellement infectés.
2. Réinstaller le système : réinstallez votre VPS ou serveur dédié depuis une image propre fournie par votre hébergeur. Sur un VPS ElypseCloud, la réinstallation se fait depuis le panel de gestion en quelques minutes.
3. Reconfigurer le serveur : réinstallez les packages nécessaires, configurez le firewall (pare-feu) avec UFW (guide sécurisation VPS Ubuntu), durcissez la configuration SSH et installez la dernière version de Plex Media Server.
4. Configurer un reverse proxy : cette fois, placez Plex derrière un serveur web Nginx ou Caddy configuré en reverse proxy avant de rendre le service accessible depuis internet (voir la section suivante).
5. Restaurer les médias : restaurez uniquement les fichiers multimédia depuis votre backup. Laissez Plex recréer sa base de données et ses métadonnées automatiquement.
6. Planifier des backups automatiques : mettez en place un script de sauvegarde régulier pour ne plus être démuni en cas de nouvel incident.

Ne jamais exposer Plex directement sur internet

La chaîne Plex2Shell ne fonctionne que si l'attaquant peut atteindre directement les endpoints HTTP de Plex (port 32400 par défaut). Si Plex est derrière un reverse proxy Nginx, seuls les chemins explicitement relayés sont accessibles. Les endpoints internes exploités par Plex2Shell (/player/timeline, /video/:/transcode/universal) ne sont jamais exposés.

Voici un exemple minimal de configuration Nginx pour relayer Plex via un nom de domaine avec un certificat TLS (Let's Encrypt) :

server {
    listen 443 ssl http2;
    server_name plex.example.com;

    ssl_certificate     /etc/letsencrypt/live/plex.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/plex.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:32400;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket pour la synchronisation Plex
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Cette configuration suppose que vous avez un nom de domaine pointé vers votre serveur et un certificat TLS configuré avec Certbot.

Pour les administrateurs qui hébergent Plex sur un VPS ou un serveur dédié, les bonnes pratiques de configuration sont :

• Placer Plex derrière un serveur web configuré en reverse proxy (Nginx, Caddy ou Traefik) qui ne relaye que les chemins nécessaires au streaming, avec un nom de domaine et un certificat TLS ;
• Bloquer le port 32400 en accès direct depuis internet avec le firewall (guide pare-feu UFW) et n'autoriser que le reverse proxy en local ;
• Désactiver l'option "Accès distant" dans les paramètres de configuration de Plex si vous utilisez un reverse proxy, pour empêcher Plex de tenter un UPnP ou un port forwarding automatique ;
• Configurer un accès VPN (WireGuard ou OpenVPN) pour l'administration à distance du serveur plutôt que d'exposer des ports de gestion sur internet ;
• Activer les mises à jour automatiques de sécurité pour que les correctifs critiques s'appliquent sans intervention manuelle.

Résumé des actions immédiates