Plex è sotto attacco. La correzione era uscita undici settimane prima.

Un media server è la cosa più innocua da esporre su internet. Questo mese è anche la più costosa.

Il 20 ottobre 2026 la CISA ha aggiunto in un colpo solo quattro vulnerabilità di Plex Media Server al proprio catalogo delle falle sfruttate attivamente. Concatenate, permettono a un attaccante senza credenziali di ottenere un token di amministrazione ed eseguire codice con i privilegi del processo Plex. Il ricercatore che le ha trovate assegna alla catena un punteggio di 9,8.

La build corretta, 1.43.3.10861, è uscita il 4 agosto. Tutto quello che è successo da allora riguarda la distanza tra una correzione che esiste e una correzione che è installata, e quella distanza è l’unica parte della storia che dipende da voi.

La cronologia, perché è l’argomento

Undici settimane di preavviso. Trentaseimila server che non le hanno usate.

Cos’è davvero la catena

Quattro difetti, ciascuno insignificante da solo, ed è esattamente per questo che sono passati inosservati:

• CVE-2026-96652 (CVSS 5,3), server-side request forgery: si può indurre Plex a inviare richieste POST verso destinazioni arbitrarie, comprese le sue API interne.
• CVE-2026-96654 (CVSS 6,9), URL injection: parametri controllati dall’attaccante raggiungono le funzioni di altri plugin.
• CVE-2026-96655 (CVSS 5,3), un’altra SSRF, questa volta nell’endpoint del transcoder.
• CVE-2026-96656 (CVSS 8,6), scrittura arbitraria di file nelle impostazioni del transcoder: una libreria condivisa può essere piazzata dove Plex la caricherà.

Rileggete l’ultimo punto, perché è lo schema da portarsi dietro su ogni altro servizio: un processo che scrive file e poi carica codice dalla stessa directory in cui scrive dista un bug di scrittura dall’esecuzione di codice. Codec, plugin, temi, estensioni, upload con percorso di inclusione. I punteggi singoli sono medi. La catena è 9,8.

Lo sfruttamento richiede accesso di rete alla porta TCP 32400. La funzione Remote Access di Plex, o un port forwarding manuale, è ciò che trasforma un servizio da salotto in un servizio esposto.

Tre cose da fare subito

1. Controllate il numero di build completo, non la versione commerciale.

# installazione da pacchetto su Debian o Ubuntu
dpkg -s plexmediaserver | grep '^Version'
# immagine Docker ufficiale
docker exec plex dpkg -s plexmediaserver | grep '^Version'
# qualunque installazione, dalla macchina stessa: l'endpoint identity risponde senza token
curl -s http://127.0.0.1:32400/identity

Tutto ciò che precede 1.43.3.10861 è interessato. Una build 1.43.3 iniziale lo è ancora: contano le ultime cinque cifre.

2. Aggiornate, poi verificate che il processo in esecuzione sia quello nuovo. Un container mai riscaricato, o un pacchetto bloccato da un pin, mostrerà allegramente una versione nuova nell’interfaccia mentre serve ancora il vecchio binario.

docker compose pull plex && docker compose up -d plex
docker exec plex dpkg -s plexmediaserver | grep '^Version'

3. Se il server era raggiungibile da internet con una build vecchia, date per scontato che sia stato raggiunto. L’avviso di Plex dice di trattare questi server come potenzialmente compromessi e fornisce indicatori: file .so o .dll sconosciuti nella directory Codecs e connessioni in uscita verso proxystream.st. Controllate entrambi prima di chiudere la faccenda:

# librerie condivise inattese nella directory dei codec
find ~/Library/Application\ Support/Plex\ Media\ Server/Codecs \
     /var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/Codecs \
     -name '*.so' -o -name '*.dll' 2>/dev/null | sort

# tutto ciò con cui la macchina parla e che non sapete nominare
ss -tn state established | awk 'NR>1{print $4}' | sort | uniq -c | sort -rn | head -20

Un cryptominer si annuncia con la CPU. Il proxyware no: rivende il vostro indirizzo come banda residenziale e resta silenzioso. L’assenza di carico non è assenza di compromissione.

La checklist che vi avrebbe salvato comunque

Nulla di quanto segue richiede di conoscere una CVE in anticipo. È esattamente il punto: queste misure pagano nelle settimane in cui non avete ancora aggiornato, cioè per ogni servizio, sempre.

Non inoltrate una porta su internet solo per usarla voi. Remote Access e un port forwarding esistono per servire persone che non sono sulla vostra rete. Se l’unico utente remoto siete voi, un tunnel WireGuard o una VPN mesh elimina del tutto la superficie d’attacco invece di difenderla. L’esposizione è una decisione, e quasi sempre nessuno la prende deliberatamente.

Negare per impostazione predefinita il traffico in ingresso, con le porte aperte messe nero su bianco. Su una macchina che fa girare più cose, il firewall è l’unico posto in cui “che cosa è raggiungibile” si legge in una schermata:

ufw default deny incoming
ufw allow 443/tcp
ufw status numbered

Leggete l’output dall’alto in basso e chiedetevi che cosa corrisponde per primo. Su una macchina ereditata che abbiamo verificato questo mese, un’accurata allowlist di tre sottoreti stava quattro righe sotto un ACCEPT generale per la stessa porta da 0.0.0.0/0, quindi non aveva mai limitato nulla. L’audit completo è qui.

Mettete i servizi HTTP dietro un solo reverse proxy, mai direttamente su internet. Una configurazione TLS, un log di accesso, un unico punto in cui aggiungere autenticazione. Lo schema che facciamo girare proprio su questo sito è descritto per intero in Caddy e Docker in produzione. La versione breve, per un servizio che non ha bisogno di alcun accesso pubblico:

media.example.com {
    @notlocal not remote_ip 10.0.0.0/8 100.64.0.0/10 192.168.0.0/16
    respond @notlocal 403
    reverse_proxy 127.0.0.1:32400
}

Legate il servizio a localhost e lasciate che il proxy sia l’unica porta. Un container pubblicato con -p 32400:32400 sta su ogni interfaccia dell’host, compresa quella pubblica; -p 127.0.0.1:32400:32400 no. Questa differenza di pochi caratteri è l’esposizione accidentale più comune che troviamo.

Trattate il traffico in uscita come qualcosa di cui avete diritto di occuparvi. Entrambi i payload osservati qui, il miner e il proxyware, sono inutili senza uscita verso l’esterno. Una macchina di casa o di un piccolo ufficio non ha motivo di aprire connessioni in uscita arbitrarie, e una linea di base confrontabile vale più di qualsiasi lista di IOC pubblicata a cose fatte.

Sappiate come ricostruireste, e provatelo. Dopo questo tipo di compromissione il consiglio onesto è una reinstallazione pulita, sostenibile solo se i dati stanno altrove e il ripristino è un gesto già fatto, non da imparare sotto pressione. Dove debba essere quell’altrove, con prezzi reali su dati reali, è nel nostro confronto degli storage per backup.

Iscrivetevi alle note di rilascio di tutto ciò che esponete. Undici settimane non sono un intervallo sfortunato, sono una mailing list non letta. Per un servizio self-hosted il produttore non ha modo di raggiungervi, né l’obbligo di provarci.

Quello che non sappiamo

Non abbiamo esaminato di persona l’interno di una macchina compromessa, e non facciamo finta del contrario. Gli indicatori qui sopra sono di Plex, i numeri sull’esposizione di Shadowserver, i punteggi CVSS del ricercatore, e le date dello sfruttamento vengono dai produttori e dalla CISA. Il nostro contributo è la parte di cui rispondiamo: che cosa significa questo schema per il resto del vostro stack, e quale configurazione facciamo davvero girare.

Domande frequenti

Quale versione di Plex corregge Plex2Shell? La 1.43.3.10861 e successive, uscita il 4 agosto 2026. Le build precedenti sono interessate, comprese le prime 1.43.3.

Il mio server Plex è a rischio se non è esposto a internet? La catena richiede accesso di rete alla porta TCP 32400. Un server raggiungibile solo dalla rete locale resta attaccabile da quella rete, quindi basta un portatile compromesso o un dispositivo ospite non fidato. È un rischio minore, non teorico.

Come faccio a sapere se il mio server Plex è già stato compromesso? L’avviso di Plex indica due segnali: file .so o .dll sconosciuti nella directory Codecs e connessioni in uscita verso proxystream.st. I payload osservati sono stati cryptominer e malware proxy. Se il server era esposto con una build vecchia, l’ipotesi prudente è la compromissione.

L’aggiornamento elimina una compromissione già avvenuta? No. La patch chiude la porta, non rimuove ciò che è già dentro. Dopo una compromissione confermata l’unica strada pulita è ricostruire da supporti sani e ripristinare dati verificabili.

Devo semplicemente disattivare Remote Access? Se l’unica persona che guarda da fuori siete voi, sì, e collegatevi tramite VPN. Remote Access è la funzione che mette la porta 32400 su internet, e i 36.000 server esposti contati a settembre non erano, in gran parte, decisioni consapevoli.

Cosa viene dopo

Se questo vi ha spinto a guardare il resto dello stack, l’audit di un’ora per un server ereditato è la checklist che usiamo su una macchina sconosciuta, e il confronto tra VPS parla di dove mettere un servizio che preferireste non tenere in casa.