Plex2Shell: catena di exploit su Plex sfruttata in un giorno

Il 16 ottobre il ricercatore Zach Main ha pubblicato l’analisi tecnica e il codice proof-of-concept di Plex2Shell, una catena di quattro vulnerabilità di Plex Media Server che permette di eseguire codice su un server esposto senza credenziali valide. La mattina del 17 ottobre un honeypot Plex vulnerabile, gestito da un altro ricercatore, ha registrato i primi attacchi reali: gli aggressori hanno installato un miner di criptovalute basato su XMRig e, più tardi, un software proxy.

Le correzioni esistono da settembre. Chi non ha ancora aggiornato, soprattutto se il server è raggiungibile da internet, deve farlo ora: SecurityWeek, Security Affairs, Ars Technica e l’avviso di KISA/KrCERT concordano sulla priorità dell’aggiornamento.

Cronologia

• 27 luglio: le falle vengono segnalate a Plex;
• 4 agosto: Plex le conferma e paga un bug bounty;
• inizio settembre: escono le versioni corrette; secondo SecurityWeek, il 1° settembre Plex annuncia di aver già distribuito le correzioni e invita ad aggiornare;
• 16 ottobre: pubblicazione dell’analisi e del PoC;
• 17 ottobre: primo sfruttamento osservato sull’honeypot;
• 20 ottobre: avviso di aggiornamento di KISA/KrCERT.

Dettagli tecnici

La catena usa CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 e CVE-2026-96656. L’avviso coreano elenca nello stesso aggiornamento anche CVE-2026-96651, e Ars Technica conferma che le CVE pubblicate sono cinque, una con punteggio 8.6 su 10. I tipi, secondo KISA/KrCERT:

• CVE-2026-96651: path traversal;
• CVE-2026-96652 e CVE-2026-96655: server-side request forgery (SSRF);
• CVE-2026-96654: neutralizzazione impropria di schemi URI codificati in una pagina web;
• CVE-2026-96656: controllo esterno del nome o del percorso di un file.

Versioni colpite: Plex Media Server precedenti alla 1.43.3.10861. Corrette: 1.43.3.10861 e successive.

Secondo la ricostruzione riportata da Ars Technica, l’exploit procede per passi: una SSRF senza autenticazione, un pivot sull’interfaccia di loopback, il furto di un token di sicurezza, la consegna del payload e infine la sua esecuzione. Security Affairs, citando l’analisi originale, descrive l’ultimo passo: un’impostazione legata alla transcodifica permette di scrivere una libreria condivisa nella cartella dei codec. Il caricatore di Plex non controlla nome, permesso di esecuzione, firma o simboli della libreria; poiché dlopen esegue i costruttori ELF (DT_INIT_ARRAY) prima di risolvere i simboli, basta una seconda transcodifica perché la cartella venga riletta e il codice giri con l’utente del servizio (uid=1000(plex) nel PoC).

Le fonti parlano di esecuzione «se sono soddisfatte le condizioni necessarie», senza elencarle tutte: in pratica il rischio maggiore riguarda i server raggiungibili dall’esterno. Il ricercatore ha dichiarato di aver usato molto un modello linguistico per trovare e concatenare le falle, guidando lui le scelte.

Tecniche MITRE ATT&CK corrispondenti (mappatura nostra): T1190 Exploit Public-Facing Application, T1129 Shared Modules, T1496 Resource Hijacking, T1090 Proxy.

Cosa hanno installato gli attaccanti

Le informazioni vengono da un solo honeypot, come sottolinea lo stesso ricercatore:

• un miner di criptovalute basato su XMRig;
• più tardi, lo stesso giorno, un programma chiamato myawesomeproxy, un software proxy che mostra un avviso secondo cui chi lo esegue accetta che la propria connessione venga usata da altri.

Il ricercatore avverte che i dati sono parziali: l’honeypot non permetteva traffico in uscita e alcuni payload non sono stati scaricati. Gli aggressori hanno usato l’exploit pubblico, forse modificato. Gli indicatori pubblicati valgono solo per l’attività vista sull’honeypot; nessuna fonte stima quanti server reali siano stati compromessi né attribuisce gli attacchi.

Perché riguarda anche le aziende

Plex nasce per l’uso domestico, ma si installa anche su NAS, macchine virtuali e container Docker (Security Affairs li cita tutti tra le installazioni da aggiornare): può quindi trovarsi in un piccolo ufficio o sulla rete di casa di chi lavora da remoto. Il punto più delicato è il proxy: come scrive il ricercatore, un server Plex su un indirizzo IP residenziale è prezioso per chi vuole raggiungere VPN e posta aziendali da indirizzi che sembrano legittimi e superano i filtri basati su reputazione e geolocalizzazione.

Per i soggetti NIS2, un server compromesso sulla rete aziendale va valutato come possibile incidente significativo, con notifica al CSIRT Italia se ne ricorrono le condizioni. Vale la pena anche rileggere gli accessi a VPN e posta da IP residenziali insoliti.

Cosa fare subito

1. Inventario: cerca istanze di Plex Media Server su server, NAS, macchine virtuali e container Docker, comprese quelle installate fuori dai processi IT.
2. Aggiorna alla 1.43.3.10861 o successiva; valuta gli aggiornamenti automatici.
3. Riduci l’esposizione: se possibile, limita Plex alla rete locale; se deve essere raggiungibile, Ars Technica suggerisce di passare da un reverse proxy invece di esporre la porta predefinita 32400.
4. Cerca tracce, perché l’aggiornamento non rimuove ciò che è già stato installato:
   • processi figli inattesi avviati dal servizio Plex, in particolare miner o proxy;
   • consumo di CPU anomalo;
   • file sconosciuti, soprattutto librerie .so, nella cartella dei codec di Plex;
   • connessioni in uscita verso indirizzi non riconosciuti. Nomi dei file e infrastruttura possono cambiare: non basarti solo su un elenco fisso di indicatori.
5. Se trovi tracce: isola la macchina, reinstallala da zero e cambia le credenziali dell’account Plex e quelle salvate sull’host.

Come aiuta ARXDOME

Su computer e server con l’agent di ARXDOME, ARX Sentry raccoglie l’inventario di software, processi e porte e controlla l’integrità dei file nelle cartelle stabilite: un’installazione di Plex non dichiarata o una libreria nuova nella cartella dei codec diventano visibili. ARX Watch trova sulla rete dispositivi senza sonda come i NAS, ARX Expose mostra i servizi e i prodotti dell’azienda visibili da internet, e ARX Shield permette di isolare dalla rete una macchina sospetta.

Ultimo aggiornamento: 20 ottobre 2026