Plex2Shell: come mettere in sicurezza Plex nell'homelab

Plex è una delle applicazioni più diffuse negli homelab: facile da gestire, disponibile su molte piattaforme e spesso raggiungibile dall'esterno. Proprio quest'ultima caratteristica rende urgente l'allarme su Plex2Shell, una catena di quattro vulnerabilità che CISA ha inserito nel catalogo KEV, cioè tra le falle sfruttate attivamente.

Non è un rischio teorico: i primi attacchi osservati hanno depositato miner per criptovalute e malware per trasformare i server compromessi in proxy. Per un SysAdmin la priorità è quindi duplice: aggiornare subito e stabilire se la macchina sia ghà stata toccata.

Perché la catena è critica

Le quattro falle sono CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 e CVE-2026-96656. Singolarmente vanno da una severità media a alta; combinate, però, consentono a un attaccante di ricavare il token amministrativo del proprietario e arrivare all'esecuzione di codice con privilegi elevati. Ilricercatore che le ha scoperte valuta la catena completa CRITICA 9.8.

Il percorso comprende due falle di tipo SSRF, una manipolazione degli URI usati dai plugin e una scrittura arbitraria di file tramite le impostazioni del transcoder. La lezione più importante è generale: un servizio che può chiamare indirizzi interni e scrivere file non deve mai essere trattato come una semplice app multimediale.

1. Verificare la versione senza fidarsi della UI

Sono vulnerabili le versioni anteriori a 1.43.3.10861. Su un'installazione Docker si può controllare l'immagine effettivamente in esecuzione:

docker inspect plex --format '{{.Config.Image}}'
docker exec plex /usr/lib/plexmediaserver/Plex Media Server --version

Se il container ha un nome diverso, sostituire plex. Per unc installazione nativa si può leggere la versione dal pannello, cliccando sull'eventuale notifica di aggiornamento, ma il controllo finale deve riguardare il binario che sta realmente girando.

2. Aggiornare con un rollback sensato

Prima dell'update salvare la configurazione, il database e foto o metadati che non si possono ricostruire. Non è necessario copiare l'intera libreria video se i file originali sono già protetti altrove.

Con Docker Compose, un flusso semplice è:

docker compose pull
docker compose up -d --remove-orphans
docker compose ps
docker logs --since 10m plex

Non usare automaticamente il tag latest senza verificare che l'immagine pubblicata contenga almeno la versione 1.43.3.10861. In produzione è preferibile pinare un tag o, ancor meglio, un digest verificato. Dopo il riavvio controllare nuovamente la versione dal container, non solo la status "healthy".

3. Ridurre l'esposizione dall'esterno

Laggiornamento è obbligatorio, ma non sostituisce la segmentazione. Se l'accesso remoto non serve, disabilitarlo e nattare la porta UPnP o il port-forward sul router. Se serve, evitare di esporre direttamente la porta di Plex su Internet: una VPN con autenticazione forte è una scelta migliore per molti homelab.

Plex dovrebbbe stare in una VLAN o rete dedicata, con regole firewall in uscita: consentire solo DNS, NTP, gli endpoint di aggiornamento e eservizi strettamente necessari. Le protezioni contro l'SSRF sono più efficaci se il server non può raggiungere liberamente pannelli di gestione, metadata cloud o altre subreti sensibili.

Per il container:

eseguire con un utente non root quando l'immagine lo supporta;
non montare il Docker socket;
montare i media in sola lettura, se compatibile con il flusso di gestione;
limitare le capabilità Linux e usare no-new-privileges;
evitare la modalità privileged.

4. Cercare segni di compromissione

L'agiornamento non cancella un attacco ghà avvenuto. Conservare i log prima di ruotarli e verificare:

processi sconosciuti o con uso anomalo di CPU;
container, servizi systemd o job cron non previsti;
connessioni in uscita verso IP insoliti;
modifiche recenti nelle directory di configurazione e del transcoder;
nuovi utenti, chiavi SSH o token non riconosciuti;
eventi di accesso dall'esterno fuori dagli orari usuali.

Comandi di base per un container Docker:

docker stats --no-stream
docker top plex -aux
docker logs --since 168h plex
docker diff plex

docker diff mostra le modifiche al filesystem del container: è utile per il triage, ma non è una prova di integrità se l'attaccante ha modificato volumi persistenti. Se compaiono indicatori credibili, isolare il server, clonare dischi e log e rigenerare token, password e segreti presenti nella macchina. Per un server esposto e non aggiornato, la reinstallazione da immagini pulite è spesso più rapida e affidabile del tentativo di bonifica in place.

Checklist operativa

[ ] Inventariare tutte le istanze Plex, inclusi NAS e server di test.
[ ] Verificare una versione uguale o successiva a 1.43.3.10861.
[ ] Effettuare un backup coerente della configurazione.
[ ] Aggiornare immagine o pacchetto e riverificare da druntime.
[ ] Rimuovere port-forward e mappature UPnP non necessarie.
[ ] Segmentare Plex dai moduli di gestione e servizi critici.
[ ] Conservare e analizzare i log dell'ultima settimana.
[ ] Ruotare i segreti se la macchina è stata esposta verso Internet.
[ ] Agiornare l'inventario e documentare l'esito.

Priorità operativa, non panyco

Il catalogo KEV di CISA non impone trattamento uguale per ogni CVE: serve a dare precedenza alle falle per cui esistono prove di sfruttamento reale. Per Plex2Shell la scelta corretta è quindi trattarla come un incidente potenziale, non come un normale aggiornamento mensile.

Pach, riduzione dell'esposizione e triage devono avanzare insieme. Aggiornare senja controllare i log lascia aperta la domanda "siamo arrivati in tempo?"; cercare solo indicatori senza chiudere la falla lascia il server a rischio. Una risposta matura fa entrambe le cose e trasforma l'evento in un miglioramento strutturale dell'homelab.