Quando gestisci server Plesk in produzione con decine di clienti e domini attivi, una vulnerabilità che consente l’esecuzione di codice arbitrario come root è lo scenario peggiore possibile. Eppure è esattamente quello che è successo con la CVE-2025-66431, una falla critica scoperta nel meccanismo di creazione domini di Plesk che permette a un utente autenticato di compromettere completamente il server.
Nella mia esperienza di system administrator, ho imparato che le vulnerabilità di privilege escalation nei pannelli di controllo sono tra le più pericolose in assoluto. Non stiamo parlando di un attacco esterno che deve superare firewall e WAF: qui basta un account Plesk con permessi standard per ottenere accesso root. Appena ho letto l’advisory ufficiale di WebPros, ho immediatamente verificato lo stato di tutti i miei server — e vi mostro esattamente come ho fatto e cosa dovete fare anche voi.
Questa vulnerabilità è particolarmente insidiosa perché sfrutta un difetto nel modo in cui Plesk gestisce i symlink durante la creazione dei domini, un’operazione che ogni utente del pannello esegue quotidianamente. Se non avete ancora applicato la patch, il vostro server è esposto adesso. Ecco la mia procedura completa per verificare, correggere e blindare l’infrastruttura.
Cos’è la CVE-2025-66431 e Perché è Così Pericolosa
La CVE-2025-66431 è una vulnerabilità di tipo Local Privilege Escalation (LPE) che affligge tutte le versioni di Plesk Obsidian su Linux precedenti alla 18.0.73.5 e dalla 18.0.74 fino alla 18.0.74.2. Il problema risiede nel meccanismo di creazione domini, che non gestisce correttamente i symbolic link (symlink) verso risorse esterne al perimetro autorizzato.
In termini tecnici, la vulnerabilità è classificata come CWE-61 (UNIX Symbolic Link Following): il sistema non verifica adeguatamente se un file è in realtà un symlink che punta a una destinazione al di fuori della sfera di controllo prevista. Un attaccante può quindi manipolare il processo di creazione dominio per far operare Plesk su file di sistema arbitrari con privilegi root.
Il punteggio CVSS 3.1 è 7.8 (HIGH), con vettore AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H. Tradotto in italiano: l’attacco è locale, richiede bassa complessità e bassi privilegi, non necessita interazione utente e l’impatto su confidenzialità, integrità e disponibilità è alto con cambio di scope — significa che compromette componenti al di fuori del perimetro dell’utente.
Chi è Vulnerabile: Versioni Affette e Requisiti dell’Attacco
Le versioni di Plesk vulnerabili sono:
- Plesk Obsidian dalla 18.0.70 alla 18.0.73.4 (tutte le build precedenti alla 18.0.73.5)
- Plesk Obsidian 18.0.74 fino alla 18.0.74.1 (corretta nella 18.0.74.2)
- Solo sistemi Linux — Windows non è affetto
Per sfruttare la vulnerabilità, l’attaccante deve essere un utente Plesk autenticato con i seguenti permessi abilitati:
- Permesso “Crea e gestisci siti” attivo
- Accesso a una sottoscrizione con “Gestione domini” e “Gestione sottodomini” abilitati
Nella pratica, questi sono permessi piuttosto comuni. Qualsiasi cliente di hosting con un piano che permetta di aggiungere domini o sottodomini potrebbe potenzialmente sfruttare questa falla. In ambienti shared hosting, dove decine di utenti condividono lo stesso server, il rischio è enorme: un singolo account compromesso o un cliente malintenzionato può ottenere il controllo totale del server, inclusi i dati di tutti gli altri clienti.
Come Verifico se il Mio Server Plesk è Vulnerabile
La prima cosa che ho fatto quando è uscito l’advisory è stata connettermi via SSH a ciascun server e verificare la versione installata. Ecco i comandi che utilizzo:
Controllo Versione da Riga di Comando
Il metodo più rapido è il comando nativo di Plesk:
plesk versionL’output mostrerà la versione del prodotto, la build e la revisione. In alternativa, potete leggere direttamente il file di versione:
cat /usr/local/psa/versionSe la versione riportata è inferiore a 18.0.73.5 oppure è la 18.0.74 o 18.0.74.1, il vostro server è vulnerabile e dovete aggiornare immediatamente.
Controllo da Interfaccia Web
Se preferite l’interfaccia grafica, accedete a Plesk > Strumenti e Impostazioni > Aggiornamenti del sistema. La versione corrente è indicata nella parte superiore della pagina. Cercate la disponibilità di micro-update in sospeso.
Procedura di Aggiornamento Step-by-Step
Una volta confermata la vulnerabilità, ecco la procedura che ho seguito sui miei server per applicare la patch. WebPros ha rilasciato sia un hotfix che un micro-update per le versioni 18.0.73.5 e 18.0.74.2.
Aggiornamento via CLI (Raccomandato)
Personalmente preferisco sempre aggiornare da riga di comando perché ho il pieno controllo del processo. Ecco i passaggi:
- Backup preventivo — Prima di qualsiasi aggiornamento, eseguo sempre un backup completo. Come ho spiegato nel mio articolo su backup automatici su Plesk con S3-Compatible, avere un backup recente è fondamentale prima di operazioni critiche.
- Verifica aggiornamenti disponibili:
plesk installer --select-release-latest --show-all-releases - Installa gli aggiornamenti del pannello:
plesk installer install-panel-updatesQuesto comando installa specificamente i micro-update di sicurezza di Plesk senza toccare i componenti aggiuntivi.
- Aggiornamento completo (se volete aggiornare anche i componenti):
plesk installer --select-release-latest --upgrade-installed-components - Verifica post-aggiornamento:
plesk versionConfermato che la versione è 18.0.73.5 o 18.0.74.2 (o superiore).
Aggiornamento via Interfaccia Web
Se preferite la GUI, andate in Strumenti e Impostazioni > Aggiornamenti del sistema > Installa aggiornamenti. Plesk scaricherà e applicherà automaticamente il micro-update. Al termine, verificate che la versione sia aggiornata.
La Vulnerabilità Gemella: CVE-2025-66430
È importante sapere che la CVE-2025-66431 non è stata l’unica vulnerabilità critica corretta in questo ciclo di patch. La CVE-2025-66430 è una falla nella funzionalità Password Protected Directories di Plesk che permette l’iniezione di dati arbitrari nella configurazione Apache, portando anch’essa all’esecuzione di comandi come root.
In questo caso, qualsiasi utente Plesk con accesso alla funzionalità di directory protette da password può iniettare direttive malevole nei file di configurazione di Apache, ottenendo privilegi root. Anche questa vulnerabilità è corretta nelle stesse versioni (18.0.73.5 e 18.0.74.2), quindi con un singolo aggiornamento risolvete entrambi i problemi.
Hardening Post-Patch: Misure di Sicurezza Aggiuntive
Applicare la patch è il primo passo, ma nella mia esperienza non basta mai. Ecco le misure di hardening aggiuntive che implemento sempre dopo una vulnerabilità di questo tipo:
Revisione dei Permessi Utente
Dato che la CVE-2025-66431 richiede specifici permessi per essere sfruttata, ho colto l’occasione per rivedere tutti i permessi assegnati ai clienti:
- Principio del minimo privilegio: rimuovete la gestione domini e sottodomini dagli utenti che non ne hanno reale necessità
- Audit degli account: verificate che non ci siano account inutilizzati o dimenticati con permessi elevati
- Sottoscrizioni condivise: controllate che nessuna sottoscrizione conceda permessi eccessivi per default
Monitoraggio dei Log
Dopo aver applicato la patch, ho controllato i log per verificare eventuali segni di sfruttamento pregresso:
# Verifica creazioni domini recenti sospette
grep -i "domain.*creat" /var/log/plesk/panel.log | tail -50
# Controlla accessi SSH e comandi eseguiti
last -50
cat /var/log/auth.log | grep -i "accepted" | tail -30Cercate creazioni di domini anomale, specialmente da account che normalmente non creano domini, o pattern inusuali nei timestamp.
Protezione dei Symlink a Livello Apache
Come misura di difesa in profondità, verifico sempre che la configurazione Apache limiti il symlink following. In Plesk > Strumenti e Impostazioni > Impostazioni Apache o direttamente nella configurazione:
# In /etc/apache2/conf.d/security.conf o equivalente
Options -FollowSymLinks +SymLinksIfOwnerMatchLa direttiva SymLinksIfOwnerMatch consente di seguire i symlink solo se il proprietario del link coincide con il proprietario del target, limitando significativamente il raggio d’azione di attacchi basati su symlink.
Aggiornamenti Automatici dei Micro-Update
Come descritto nella mia guida su come configurare un server Plesk Obsidian per la sicurezza, raccomando sempre di abilitare gli aggiornamenti automatici per i micro-update di sicurezza:
Andate in Strumenti e Impostazioni > Aggiornamenti del sistema > Impostazioni e selezionate “Installa automaticamente gli aggiornamenti di sicurezza”. In questo modo, patch critiche come questa verranno applicate senza intervento manuale.
Il Contesto: Sicurezza dei Pannelli di Controllo nel 2026
Questa vulnerabilità arriva in un momento in cui la sicurezza dei pannelli di controllo hosting è sotto i riflettori. Come ho scritto nel mio articolo sulla protezione WordPress con virtual patching e monitoraggio CVE, il monitoraggio proattivo delle vulnerabilità è diventato imprescindibile.
Chi gestisce server con Plesk dovrebbe implementare un Vulnerability Disclosure Program strutturato — ne ho parlato approfonditamente nell’articolo dedicato al VDP e al Cyber Resilience Act. Inoltre, l’adozione di SOC autonomi con AI per threat prediction può aiutare a identificare tentativi di exploitation prima che vadano a buon fine.
In ambienti multi-tenant come quelli gestiti con Plesk, una singola vulnerabilità di privilege escalation può avere effetti catastrofici: accesso ai database di tutti i clienti, possibilità di installare backdoor persistenti, manipolazione dei certificati SSL e, nel caso peggiore, utilizzo del server come punto di partenza per attacchi laterali all’interno dell’infrastruttura.
Checklist Rapida Post-Incident
Ecco la checklist che ho seguito e che consiglio a tutti gli amministratori Plesk:
- Verificare la versione con
plesk version - Eseguire il backup prima di aggiornare
- Applicare il micro-update alla 18.0.73.5 o 18.0.74.2+
- Controllare i log per segni di sfruttamento pregresso
- Rivedere i permessi utente applicando il principio del minimo privilegio
- Verificare la protezione symlink nella configurazione Apache
- Abilitare gli auto-update per i micro-update di sicurezza
- Documentare l’intervento nel registro di manutenzione del server
FAQ
La CVE-2025-66431 può essere sfruttata da remoto senza un account Plesk?
No. La vulnerabilità richiede un account Plesk autenticato con permessi specifici (creazione e gestione siti, gestione domini e sottodomini). Tuttavia, in ambienti di hosting condiviso, qualsiasi cliente con un account standard potrebbe potenzialmente disporre di questi permessi, rendendo la superficie d’attacco più ampia di quanto si potrebbe pensare.
Ho Plesk su Windows: sono vulnerabile?
No. La CVE-2025-66431 affligge esclusivamente le installazioni Plesk su Linux. La vulnerabilità è legata alla gestione dei symbolic link UNIX (CWE-61), un meccanismo specifico dei sistemi operativi Unix-like. Se utilizzate Plesk su Windows, non siete interessati da questa specifica falla.
Come posso sapere se il mio server è già stato compromesso?
Controllate i log di Plesk (/var/log/plesk/panel.log) cercando creazioni di domini anomale, specialmente con nomi insoliti o da account che normalmente non creano domini. Verificate anche i log di sistema (/var/log/auth.log) per accessi sospetti e controllate la presenza di file inattesi nelle directory di sistema. In caso di dubbio, eseguite una scansione con rkhunter o chkrootkit e considerate un audit di sicurezza approfondito.
Devo aggiornare anche se ho un singolo sito senza clienti esterni?
Assolutamente sì. Anche se gestite un solo sito, qualsiasi account con accesso a Plesk — incluso il vostro — potrebbe essere compromesso tramite phishing, credential stuffing o altre tecniche. Inoltre, la CVE-2025-66430 (corretta nello stesso aggiornamento) sfrutta le directory protette da password, una funzionalità comunemente utilizzata anche su server con un singolo sito.
L’aggiornamento causa downtime al server o ai siti ospitati?
I micro-update di Plesk sono progettati per essere applicati senza downtime significativo. Nella mia esperienza, il processo richiede pochi minuti e l’interfaccia web di Plesk potrebbe risultare brevemente non raggiungibile, ma i siti web ospitati continuano a funzionare normalmente durante l’aggiornamento. Consiglio comunque di pianificare l’operazione in un orario di basso traffico per precauzione.
Conclusione
La CVE-2025-66431 è un promemoria severo che anche i pannelli di controllo più diffusi possono nascondere vulnerabilità critiche. Un difetto nella gestione dei symlink durante la creazione dei domini, combinato con i privilegi root del processo Plesk, ha creato una finestra di attacco che potrebbe consentire la compromissione totale del server.
Il messaggio è chiaro: aggiornate subito. Se usate Plesk su Linux, verificate immediatamente la vostra versione e applicate il micro-update alla 18.0.73.5 o 18.0.74.2. Non aspettate. Non rimandate. Una vulnerabilità di esecuzione codice come root non è qualcosa su cui si può procrastinare.
Ho protetto i miei server nel giro di minuti dall’uscita dell’advisory, e vi consiglio di fare altrettanto. Se avete dubbi sulla procedura o volete condividere la vostra esperienza con questa vulnerabilità, lasciate un commento qui sotto — confrontarsi tra colleghi è sempre il modo migliore per migliorare le nostre difese.