Plex Media Server SSRF (CVE-2026-96652) sfruttata — aggiorna a 1.43.3.10861

CISA ha inserito oggi CVE-2026-96652 — una server-side request forgery (SSRF) in Plex Media Server — nel suo catalogo delle Known Exploited Vulnerabilities, con scadenza di remediation federale al 3 novembre 2026. Presa da sola la falla è classificata media. È proprio questo a renderla pericolosa: è il primo passo silenzioso di una catena di quattro bug che termina con esecuzione di codice non autenticata sul server, e le istanze esposte su Internet e non aggiornate vengono già trasformate in cryptominer e nodi proxy.

Notizia in evoluzione — pubblicata alle 21:56 (19:56 UTC) del 20 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-96652 (CWE-918, SSRF)
Prodotto / versioni colpite	Plex Media Server precedenti a 1.43.3.10861
Corretta in	1.43.3.10861 (rilasciata il 1° settembre 2026); Plex Desktop 1.115.0
CVSS	5.3 Media (CVSS 4.0) · 4.3 Media (CVSS 3.1), entrambi assegnati dalla CNA; NVD non ha aggiunto un punteggio proprio
Sfruttata attivamente	Sì — Plex dichiara che la catena è "sfruttata attivamente e su larga scala"; CISA KEV
CISA KEV	Aggiunta 2026-10-20; scadenza federale 2026-11-03 (BOD 26-04)
PoC pubblico	Sì — analisi tecnica e PoC pubblicate il 2026-10-16
Advisory ufficiale	Aggiornamento di sicurezza Plex Media Server

Cosa è successo

Plex ha rilasciato la correzione in sordina il 1° settembre 2026, in Plex Media Server 1.43.3.10861 e Plex Desktop 1.115.0. Per sei settimane è sembrato un normale aggiornamento di manutenzione. Poi, il 16 ottobre, il ricercatore che aveva segnalato i bug — con lo pseudonimo zmain — ha pubblicato un'analisi completa e un proof-of-concept funzionante chiamato "Plex2Shell". Nel giro di pochi giorni è iniziato lo sfruttamento di massa dei server non aggiornati e il 19 ottobre Plex ha modificato il proprio advisory dichiarando che le vulnerabilità sono "sfruttate attivamente e su larga scala". CISA ha inserito CVE-2026-96652 nel catalogo il 20 ottobre.

Lo scarto tra una patch silenziosa e un PoC pubblico è l'intero incidente. La versione corretta esiste dal 1° settembre; chi ha estratto il diff e ricostruito la catena non ha aspettato. Se il tuo server è stato raggiungibile da Internet e girava una versione precedente a 1.43.3.10861 da metà ottobre, l'indicazione di Plex è di considerarlo compromesso.

Come una SSRF media diventa esecuzione di codice

Letta in isolamento, CVE-2026-96652 è banale. L'endpoint /player/timeline costruisce un URL di callback a partire dai valori protocol, host e port forniti dal client, senza mai validarli. Sulle richieste WAN controlla soltanto che l'header X-Plex-Token sia presente — il valore non viene mai verificato, quindi passa qualsiasi stringa. Metti un URL di loopback completo in protocol e il server invia una POST verso la destinazione che scegli. L'attaccante non può leggere la risposta. Da sola, è un 4.3.

La catena è ciò che segnala la scheda CISA KEV quando nota che CVE-2026-96652 "può essere concatenata con CVE-2026-96654, CVE-2026-96655 e CVE-2026-96656". L'analisi del ricercatore descrive le fasi:

• Dalla SSRF all'API di loopback. La SSRF cieca raggiunge 127.0.0.1:32400, dove l'API dei plugin /system/agents/* si fida dei chiamanti in loopback e salta il controllo del token. Un difetto nel controllo di un identificativo consente di invocare funzioni di plugin arbitrarie.
• Furto del token admin del proprietario. Una funzione di un agente di metadati integrato recupera URL e allega il token admin del proprietario a qualsiasi URL che inizi con il prefisso di loopback. Un hostname costruito ad arte che inizia con 127.0.0.1. fa trapelare il token all'attaccante.
• Scrittura arbitraria di file. Con i privilegi admin, l'attaccante modifica una preferenza del transcoder in modo che questo scriva byte controllati nella directory Codecs.
• Esecuzione di codice. All'avvio del transcoder il server carica i file .so da quella directory. La libreria piazzata viene eseguita con l'account di servizio plex.

Una richiesta non autenticata a un "media server" finisce in esecuzione di codice nativo. Nessuna credenziale indovinata; serviva solo che la SSRF esistesse e che il server fosse raggiungibile. È per questo che la triage basata sul solo CVSS continua a fallire sulle catene: ogni anello è sopravvivibile, la somma no.

Chi è esposto

Qualsiasi Plex Media Server precedente a 1.43.3.10861 raggiungibile da Internet — nel caso più comune un server domestico o di piccola impresa con la porta 32400 inoltrata, oppure con il Remote Access attivo. L'exploit non richiede credenziali valide né un valore di token valido. Plex riferisce che i server compromessi hanno eseguito miner di criptovalute e proxyware, con artefatti osservati tra cui processi sconosciuti generati dal server (Plex cita come esempi myawesomeproxy, mylovelyminer, x12345), librerie estranee nella cartella Codecs e traffico in uscita verso proxystream.st.

Controlla la versione in Impostazioni → Generale in Plex Web. Se riporta 1.43.3.10861 o successiva, non sei esposto a questa catena.

Remediation

Basata sull'advisory Plex e sull'analisi pubblica. La patch chiude la porta; non caccia chi è già dentro.

1 — Sono colpito? Verifica la versione in esecuzione (Impostazioni → Generale). Determina l'esposizione a Internet: il Remote Access è attivo, o la TCP 32400 è inoltrata al server? Un server raggiungibile da Internet sotto 1.43.3.10861 dopo metà ottobre è il caso ad alto rischio.

2 — Applica la patch (versioni corrette esatte). Aggiorna Plex Media Server a 1.43.3.10861 o successiva; aggiorna Plex Desktop a 1.115.0. "Plex Media Server 1.43.3.10861 e successive non sono vulnerabili."

3 — Non puoi aggiornare subito? Controlli compensativi. Disattiva il Remote Access (Impostazioni → Remote Access) e smetti di inoltrare la porta 32400 sul router. Metti il server dietro una VPN o un reverse proxy con autenticazione. Poiché la SSRF richiede soltanto che il server sia raggiungibile, rimuovere l'esposizione WAN rimuove la superficie d'attacco fino alla patch.

4 — Caccia alla compromissione (indicatori da vendor + ricercatore). Mappati su MITRE ATT&CK:

• Accesso iniziale (T1190): richieste WAN in ingresso verso /player/timeline con valori X-Plex-Token arbitrari; traffico di subscribe/unsubscribe del player con URL di loopback nel campo protocol; richieste in uscita verso hostname nella forma 127.0.0.1.<qualcosa> (nomi in stile sslip.io).
• Accesso a credenziali (T1552.001): uso o esposizione inattesi del token admin del proprietario.
• Esecuzione / persistenza (T1574): file .so/.dll nuovi o estranei nella directory Codecs; modifiche inattese alla preferenza TranscoderH264Options in Preferences.xml; richieste di transcodifica il cui parametro path punta a URL HTTP esterni.
• Impatto (T1496 / T1090): CPU inspiegabilmente alta senza riproduzioni in corso (miner); connessioni in uscita verso proxystream.st o endpoint proxy sconosciuti; processi sconosciuti generati dal processo Plex.

5 — Bonifica e verifica. Se la compromissione è accertata o non può essere esclusa, l'indicazione di Plex è di ricostruire da un'installazione pulita anziché riutilizzare la directory dati esistente. Come minimo, elimina il contenuto della cartella Codecs e rivedi Preferences.xml per opzioni del transcoder che non hai impostato. Esci da tutti i dispositivi nell'account Plex e cambia la password Plex. Considera potenzialmente esposta — e ruota — qualsiasi condivisione, mount o credenziale che l'account di servizio Plex poteva raggiungere. Riverifica dopo la patch: una scansione pulita su un server non aggiornato non prova nulla.

Cosa non si sa ancora

• Se gli operatori ransomware stiano usando la catena. CISA registra l'uso ransomware noto come "Unknown" alla data del 20 ottobre.
• L'entità della compromissione. Plex parla di sfruttamento "su larga scala" ma non ha pubblicato un conteggio dei server.
• L'attribuzione dei gruppi che distribuiscono miner e proxyware.
• Se NVD divergerà dai punteggi medi della CNA una volta completata la propria analisi.

Questo articolo sarà aggiornato man mano che queste lacune si chiuderanno.

Perché le catene battono i punteggi di severità — e cosa risponde davvero

La lezione pratica di CVE-2026-96652 è che una coda di vulnerability management ordinata per CVSS mette un 4.3 in fondo nello stesso giorno in cui lo si usa per esecuzione di codice remota. La severità è una proprietà di un singolo bug; la sfruttabilità è una proprietà di un percorso. L'unico modo onesto per sapere se i quattro anelli si compongono in una RCE funzionante sulla tua specifica build e configurazione è percorrere la catena come fa l'attaccante.

È il lavoro che un red team autonomo basato su AI svolge in continuo. Lo sciame di 10 agenti di Zero Hunt rileva la versione esatta di Plex e la piattaforma, poi il suo motore generativo scrive una catena di exploit per quell'ambiente — cucendo il primitivo SSRF al pivot in loopback, al furto del token e alla scrittura del file — invece di rieseguire uno script statico. L'Exploit Forge itera un proof-of-concept eseguibile finché non funziona in modo dimostrabile, così il risultato che ricevi è "questo arriva all'esecuzione di codice sul tuo server", non "da qualche parte hai una SSRF media". Ogni passo gira on-premise sui modelli privati di Zero Hunt — nessun dato lascia l'apparato, nessun terzo può limitare o spegnere la capacità — con un operatore umano che autorizza ogni azione di sfruttamento, e ogni verdetto firmato alla scrittura (Ed25519, hash-chain) per la catena di evidenze. La campagna di default è black-box: il motore ottiene il risultato senza credenziali, esattamente come fa Internet.

Una volta provata la catena, la domanda diventa cosa faccio adesso — e per un evento di patch-più-presunzione-di-compromissione come questo, la sequenza conta. L'AI Remediation Advisor ordina i rilievi per sfruttabilità reale (prima CISA KEV, poi ciò che è stato provato raggiungibile nella campagna, poi CVSS ed EPSS), ti consegna la versione corretta esatta con note di rollout e rollback e un controllo compensativo per i server che stanotte non puoi aggiornare, e riverifica la correzione con la stessa prova che aveva dimostrato il problema — così "corretto" significa ri-testato, non solo un numero di versione più alto. Per la scadenza in sé, la guida ai requisiti di pentest per regolamento mappa dove quell'evidenza deve finire.