# Plex : quatre failles liées pour passer d’une URL à l’exécution de code

> Plex confirme une exploitation active de quatre failles liées. Analyse de la chaîne SSRF, accès local, divulgation du jeton administrateur et écriture de fichier.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/plex-ssrf-jeton-ecriture-rce-2026/

**Version corrigée disponible le 1er septembre 2026 ; détails et exploitation confirmés le 19 octobre.** Plex décrit une chaîne inhabituelle de **quatre** vulnérabilités permettant à un attaquant distant sans authentification d'exécuter du code avec les privilèges du processus Plex Media Server. Son [avis officiel](https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319/) nomme CVE-2026-96652, -96654, -96655 et -96656, indique qu'un PoC public est apparu le 16 octobre et confirme une exploitation active et étendue. La valeur de cette histoire est dans les frontières successives franchies, pas dans une prétendue « faille unique donnant root ».

## Le serveur comme mandataire de l'attaquant

Le premier défaut, **CVE-2026-96652**, est une SSRF sans authentification dans l'endpoint de chronologie du lecteur. Une SSRF permet à un acteur extérieur de demander au serveur de produire une requête réseau vers une destination qu'il ne devrait pas pouvoir atteindre lui-même. La distinction est importante : obtenir une réponse du serveur Plex ne signifie pas encore lire n'importe quel fichier ou exécuter un programme. La primitive fournit un **point de départ réseau depuis l'intérieur** de la machine.

Le deuxième défaut, **CVE-2026-96654**, concerne des fonctions d'agent internes accessibles par l'interface de loopback. Normalement, `127.0.0.1` constitue une frontière pratique : seuls les processus locaux peuvent y parler. Une SSRF peut briser cette hypothèse si l'application accepte de relayer des requêtes vers elle-même. L'association des deux failles transforme une fonction « locale seulement » en fonctionnalité que l'attaquant distant peut atteindre indirectement.

## De la fonction interne au droit administrateur

Le troisième élément, **CVE-2026-96655**, divulgue le jeton administrateur du propriétaire du serveur. Le jeton est une capacité : toute personne qui le présente peut faire des opérations que le système réserve normalement au propriétaire, tant que le serveur l'accepte. La chaîne ne « devine » pas le mot de passe ; elle récupère un secret déjà reconnu par l'application grâce aux chemins précédents.

Le quatrième défaut, **CVE-2026-96656**, autorise une écriture de fichier arbitraire dans le répertoire `Codecs` via les préférences du transcodeur. Une écriture devient particulièrement dangereuse dans un emplacement dont le contenu est ensuite chargé comme code ou utilisé par un processus privilégié. Plex affirme que les quatre problèmes, combinés, aboutissent à une exécution de code avec les droits du **processus Plex Media Server**. Cela ne signifie pas automatiquement `root` ou administrateur système : le compte sous lequel tourne Plex et les permissions de l'installation déterminent la portée ultérieure.

Le schéma causal est donc : entrée HTTP publique → requête interne provoquée par le serveur → fonction normalement limitée au loopback → jeton propriétaire → écriture dans `Codecs` → code exécuté par Plex. Chaque flèche demande sa propre condition. Un article qui n'en montre qu'une seule, ou qui appelle la SSRF « RCE » sans expliquer les autres, masque la raison de la gravité réelle.

## Ce que prouve le PoC public et ce que l'avis ne détaille pas

Plex confirme la date de publication d'un PoC, mais son [communiqué](https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319/) ne fournit pas le code ni une trace reproductible de chaque requête. Le PoC signalé renforce la plausibilité d'une reproduction par d'autres acteurs ; l'affirmation d'exploitation active vient séparément de Plex. Sans analyser et exécuter ce PoC dans un laboratoire contrôlé, il serait abusif d'inventer les paramètres exacts de l'endpoint, la forme de la charge écrite ou le moment où le codec est chargé. Le mécanisme ci-dessus reprend uniquement les primitives et le résultat que Plex publie.

Pour rechercher cette classe de chaîne dans une revue autorisée, on cartographie les endpoints sans compte qui effectuent des requêtes sortantes, puis on teste leurs règles de destination contre loopback, adresses privées et redirections. On recense ensuite les fonctions internes protégées uniquement par la localisation réseau et on suit toute route qui expose un jeton. Enfin, une revue des opérations d'écriture demande si un répertoire cible peut influencer du code chargé ultérieurement. Le test utile n'est pas quatre scanners indépendants : c'est la vérification des **transitions entre privilèges**.

## Réponse et enseignement

Plex fixe le seuil à **1.43.3.10861** pour Media Server ; son message initial conseillait aux utilisateurs de NAS d'installer manuellement le paquet si leur catalogue ne proposait pas encore la mise à jour. L'inventaire doit donc lire la version du binaire réellement lancé, pas la seule présence d'une notification de mise à jour. Sur un serveur exposé avant correction, il faut aussi examiner les accès anormaux, les jetons actifs et les fichiers du répertoire de codecs ; appliquer le correctif ne supprime pas nécessairement des effets d'une intrusion passée.

Cette affaire montre pourquoi « accessible uniquement en local » n'est pas une barrière suffisante lorsqu'un autre composant peut être persuadé de parler au local pour le compte d'un attaquant. La défense tient autant à la validation des destinations qu'à l'autorisation propre des fonctions internes et à la protection du jeton administrateur.

**Source principale :** [annonce de sécurité Plex et mise à jour du 19 octobre](https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319/).