#Finsubito news dalla rete – Chi non aggiorna Plex Media Server rischia di minare criptovalute per hacker a sua insaputa

Una catena di quattro vulnerabilit� in Plex Media Server, corretta dall’azienda ad agosto ma resa pubblica solo il 16 ottobre, viene sfruttata attivamente dal weekend scorso per installare software di mining di criptovalute e proxy residenziali sui server che non hanno ancora installato la patch. Il ricercatore che si firma ZM ha segnalato la falla a Plex il 27 luglio e ha pubblicato la ricostruzione tecnica il 16 ottobre con il nome Plex2Shell. L’azienda ha confermato il problema e corrisposto un bounty di 500 dollari il 4 agosto, lo stesso giorno in cui � diventata disponibile la build corretta, la versione 1.43.3.10861. I quattro CVE sono stati assegnati il 23 settembre, insieme a una quinta falla minore non necessaria alla catena di esecuzione del codice.

Il compenso di appena 500 dollari per una falla che consente l’esecuzione di codice da remoto senza alcuna credenziale, e che la proof of concept pubblicata su GitHub valuta 9,8 su 10 nella scala CVSS, ha acceso qualche ironia online. Singolarmente nessuna delle quattro vulnerabilit� supera un punteggio di 6,9, ma incatenate insieme restituiscono un accesso completo al server.

Per individuare le quattro falle, ZM ha utilizzato modelli linguistici di intelligenza artificiale in ogni fase del lavoro: dalla mappatura dei percorsi che portano dall’input dell’utente ai punti pericolosi del codice, alla caccia mirata ai singoli bug, fino alla verifica di ciascuna scoperta, affidata a un agente separato con il compito di provare a smontarla. Il ricercatore precisa per� che non si � trattato di chiedere semplicemente a un modello di violare Plex: le ore di lavoro, i vicoli ciechi e le decisioni su cosa approfondire sono rimaste un compito suo, con l’intelligenza artificiale impiegata per accelerare il processo.

Come funziona la catena Plex2Shell

Plex Media Server ascolta sulla porta 32400 e viene spesso esposto direttamente su internet per permettere lo streaming da remoto. Sotto la scocca combina un binario in C++, un framework di plugin in Python e un transcoder video, ed � proprio l’interazione tra questi componenti ad aprire la falla.

Il primo passo � una falsificazione di richieste lato server, o SSRF: l’endpoint che gestisce i telecomandi e i dispositivi di casting controlla solo che l’header del token sia presente, non che il valore sia valido. Un parametro non filtrato nella procedura di annullamento della sottoscrizione lascia inserire un indirizzo a piacere, e il server finisce per inviare una richiesta a se stesso sull’interfaccia di loopback (127.0.0.1), quella riservata alle comunicazioni interne.

Da l� si apre il secondo passo. Le richieste che arrivano da loopback saltano l’autenticazione, incluso l’accesso al sistema di plugin che gestisce il recupero dei metadati da servizi come TheTVDB. Un controllo nel codice che dovrebbe verificare l’identificatore del plugin chiamato � scritto in modo da non bloccare mai nulla, e questo permette di forgiare una chiamata a qualunque funzione dei plugin con parametri scelti dall’attaccante.

La funzione presa di mira recupera un URL esterno per conto del server, e Plex aggiunge automaticamente il token di amministratore del proprietario a ogni richiesta che il server rivolge a un indirizzo che inizia con la stringa “127.0.0.1”. Un servizio DNS pubblico permette di registrare un nome host che inizia proprio con quella stringa ma punta all’indirizzo dell’attaccante. Il controllo di Plex riconosce il prefisso come interno e allega il token, mentre la risoluzione DNS indirizza la richiesta al vero destinatario: l’attaccante riceve il token e ottiene cos� pieno accesso da amministratore senza aver mai avuto credenziali reali.

L’ultimo passo trasforma l’accesso in esecuzione di codice. Con il token rubato, l’attaccante pu� modificare un’opzione del transcoder video che viene passata direttamente alla libreria di codifica x264, e che include una funzione di debug pensata per scrivere i fotogrammi decodificati su un percorso a scelta. Codificando un video senza perdita di qualit�, i fotogrammi scritti su disco risultano una copia byte per byte dei dati in ingresso: basta nascondere dentro quei dati una libreria condivisa malevola e salvarla nella cartella dei codec di Plex. Quella cartella viene scansionata a ogni avvio del transcoder, e Plex carica ogni file con estensione .so che trova senza verificarne firma o permessi. Al caricamento successivo, il codice della libreria viene eseguito con i privilegi del processo Plex.

Lo sfruttamento nel mondo reale, dai cryptominer ai proxy residenziali

Il ricercatore che si firma boredhackerblog aveva allestito un honeypot, un server Plex deliberatamente vulnerabile usato come trappola, in attesa che la ricostruzione tecnica diventasse pubblica. La mattina del 17 ottobre, un giorno dopo la pubblicazione della ricerca, ha osservato i primi tentativi di sfruttamento reale, condotti con il codice distribuito dagli stessi autori della ricerca. Il primo payload installato � stato un software di mining di criptovalute; nelle ore successive � arrivato un secondo strumento, chiamato myawesomeproxy, che trasforma il server compromesso in un proxy residenziale: fa passare il traffico di terzi attraverso la connessione della vittima, in modo che risulti traffico domestico ordinario. Il programma mostra all’avvio un avviso secondo cui farlo girare implica accettare il possibile utilizzo esterno della connessione del dispositivo.

I tentativi di attacco sono arrivati da almeno tre indirizzi IP distinti, mentre il miner osservato, identificato come mylovelyminer, puntava a un pool di mining il cui dominio � ota.proxystream.st. Un sottodominio collegato allo stesso dominio era gi� stato segnalato da Bitsight nell’agosto 2026 in relazione alla rete AISURU, nota per attacchi DDoS e per il noleggio di proxy residenziali rubati.

Nick Percoco, Chief Security Officer di Kraken, ha commentato l’attacco osservato sull’honeypot sottolineando un dettaglio che rende la pulizia pi� complicata del previsto: il payload resta nella cartella dei codec di Plex e viene ricaricato a ogni transcodifica successiva, quindi fermare il processo del miner non basta a eliminare l’infezione.

Secondo i dati di Shadowserver, al 17 ottobre risultavano ancora esposti online quasi 49mila server con la versione vulnerabile, di cui circa 25.100 in Nord America e 17.600 in Europa. Lo stesso osservatorio aveva gi� contato oltre 36mila installazioni non aggiornate a inizio settembre, quando Plex aveva pubblicato un primo avviso pubblico senza ancora rendere noti i CVE, in attesa della loro assegnazione.

I precedenti di sicurezza di Plex

Nel settembre 2025 Plex aveva gi� chiesto agli utenti di reimpostare la password, dopo che una terza parte non autorizzata aveva avuto accesso a email, nomi utente e password con hash. Pochi mesi prima, in seguito a un’altra segnalazione tramite il programma di bug bounty, oggi tracciata come CVE-2025-34158, l’azienda era arrivata a impedire temporaneamente agli utenti secondari di connettersi ai server rimasti su versioni vulnerabili, pur senza forzare l’aggiornamento automatico dei proprietari. Una persona a conoscenza di un resoconto riservato di LastPass ha identificato in Plex il software multimediale di terze parti sfruttato nel 2022 per compromettere il computer di casa di un ingegnere DevOps dell’azienda, l’episodio che port� poi alla violazione del vault aziendale di LastPass; LastPass e Plex non hanno mai confermato pubblicamente quel collegamento negli stessi termini.

Per chi gestisce un server Plex Media Server, l’indicazione resta semplice: aggiornare alla versione 1.43.3.10861 o successiva, controllare la cartella Codecs in cerca di file .so non riconosciuti e, se non serve l’accesso da remoto, disattivarlo dalle impostazioni invece di lasciare la porta 32400 esposta direttamente su internet.