Plex Media Server: exploit Plex2Shell usato in rete per installare cryptominer XMRig

• Exploit Plex2Shell usato il 17 ottobre 2026 contro un honeypot Plex su Linux/Docker
• Catena di 4 CVE (CVE-2026-96652, -96654, -96655, -96656) per eseguire codice senza login
• Installati un miner XMRig e un software proxy; autori e numero di vittime reali ignoti
• Aggiornare Plex Media Server alla 1.43.3.10861, anche su NAS e Docker

Alcuni attaccanti stanno sfruttando vulnerabilità di Plex Media Server per installare malware di cryptomining. Il ricercatore di Boredhackerblog ha registrato attacchi andati a buon fine contro un honeypot (un sistema esca) il 17 ottobre 2026. L’attività segue la pubblicazione di Plex2Shell, un exploit pubblico che concatena quattro vulnerabilità per eseguire codice senza autenticazione.

Come funziona la catena di exploit

Plex ha annunciato gli aggiornamenti di sicurezza il 1° settembre, invitando a installare Plex Media Server 1.43.3 e Plex Desktop 1.115.0. L’avviso ufficiale precisa che gli utenti di NAS potrebbero dover aggiornare manualmente.

L’exploit combina CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 e CVE-2026-96656. Secondo il repository di Plex2Shell, si parte da una server-side request forgery (SSRF), che induce il server a inviare richieste scelte dall’attaccante. Si arriva poi a funzioni interne e a richieste autorizzate come se provenissero dal proprietario. Infine si scrive un file in un percorso deciso dall’attaccante.

L’ultima fase abusa del caricamento di un codec non firmato per eseguire codice. Il repository indica come vulnerabili le versioni precedenti alla 1.43.3.10828 e come corretta la 1.43.3.10861. L’exploit supporta Linux e Windows. L’attività osservata riguarda però un’installazione Plex su Linux in esecuzione in Docker.

Cosa ha osservato il ricercatore

Il primo tentativo è partito da un indirizzo, seguito da altri. Le richieste prendevano di mira il percorso /player/timeline/subscribe e contenevano riferimenti a servizi interni di Plex, a un hostname sslip.io e allo user agent Python-urllib/3.10.

Dopo aver abilitato il traffico in uscita, il ricercatore ha rilevato download di file chiamati docker e x. Gli artefatti pubblicati comprendono campioni packed e unpacked, seguiti da un miner XMRig. Un uso analogo di XMRig è già comparso in altre campagne, tra cui quelle contro server Redis esposti.

In un aggiornamento è stato segnalato anche un processo chiamato myawesomeproxy, con traffico verso un dominio dedicato. Il programma mostrava un messaggio sull’uso esterno del traffico internet del dispositivo. Ciò fa temere un abuso come proxy.

Limiti dei dati

Le evidenze mostrano uno sfruttamento attivo di un server di test, non solo scansioni. Non permettono però di stabilire quanti server reali siano stati compromessi né chi sia dietro la campagna. Non provano nemmeno un legame con una botnet specifica. Le restrizioni sul traffico in uscita hanno inoltre impedito, all’inizio, di raccogliere alcuni payload.

Cosa fare

• Installare l’ultima versione di Plex e verificare quella effettivamente in esecuzione, soprattutto su NAS e in ambienti Docker.
• Su Linux, esaminare l’albero dei processi di Plex per individuare processi figli inattesi, download sospetti e programmi di mining o proxy sconosciuti. Il ricercatore suggerisce di usare ps axjf.
• Sfruttare le catture di pacchetti pubblicate per creare regole di rilevamento. I file marcati «lab» provengono da test controllati, non da attacchi reali.
• Non affidarsi solo a indicatori fissi: il repository avverte che gli attaccanti possono cambiare porte, domini e nomi di file.

Indicatori di compromissione (IoC)

45.194.92[.]222
91.92.40[.]202
176.65.139[.]228
217.60.194[.]116
proxystream[.]st
myawesomeproxy
/player/timeline/subscribe
Python-urllib/3[.]10

Fonte: Cyber Security News · Foto: Cyber Security News