cPanel ha rilasciato il 27 agosto 2026 una patch d'emergenza per CVE-2026-65643, una falla che permette a un normale cliente di hosting di eseguire codice come utente root sull'intero server. Il produttore la classifica come critica e dichiara colpite tutte le versioni supportate di cPanel & WHM.

La vulnerabilità non è nel pannello di login né in un componente esotico: è nella funzionalità di domain parking e di addon domain, cioè in una delle operazioni più banali che un cliente compie quando vuole puntare un secondo dominio sul sito che ha già. Secondo la comunicazione inviata da cPanel ai clienti, un titolare di account autenticato che abbia il permesso di aggiungere domini parcheggiati o addon può creare file arbitrari sul server, e da lì arrivare all'esecuzione di codice con privilegi di root, ottenendo il controllo completo della macchina.

Cosa sappiamo (e cosa non sappiamo ancora)

Il quadro informativo è, al momento, volutamente scarno da parte del vendor. Ecco i punti fermi:

  • Nessun punteggio CVSS pubblicato. La notifica ai clienti non lo riporta, e al 28 agosto 2026 non risultava ancora pubblicato il record CVE per CVE-2026-65643, mentre erano già presenti quelli di CVE-2026-58048 e CVE-2026-58047, due falle cPanel divulgate il 31 luglio.
  • Nessuna conferma di sfruttamento attivo. cPanel non si è espressa e la falla non compare nel catalogo KEV della CISA nella versione del 27 agosto 2026.
  • Nessuna mitigazione ufficiale intermedia e nessun indicatore di compromissione fornito dal produttore: chi vuole capire se è già stato colpito deve arrangiarsi.

Le build corrette sono le seguenti:

  • 11.110.0.141 o successive
  • 11.134.0.53 o successive
  • 11.136.0.37 o successive
  • 11.138.0.2 o successive
  • 11.138.1.7 o successive (WP Squared)

L'elenco copre i rami 110, 134, 136 e 138. I rami 11.118 e 11.126, citati negli avvisi di luglio, non compaiono: cPanel non ha chiarito se siano ancora supportati. Chi è su una versione end-of-life non riceve la correzione e deve prima migrare a un ramo supportato.

Perché questa falla pesa più del suo profilo tecnico

Sulla carta CVE-2026-65643 richiede autenticazione, e questo di solito abbassa l'allarme. Qui succede l'opposto, per una ragione di modello di servizio: su un server di hosting condiviso l'autenticazione ce l'hanno tutti i clienti, per definizione. Il prerequisito di sfruttamento non è "compromettere un account", è "avere un account", cioè pagare qualche euro al mese oppure entrare in possesso delle credenziali di un solo sito trascurato fra le centinaia ospitate sulla stessa macchina.

Il risultato è che il confine di sicurezza che regge tutto il modello dell'hosting condiviso — la separazione fra tenant — salta. Chi arriva a root può leggere, modificare o cancellare i dati di tutti gli account presenti sul server, comprese le basi dati dei siti degli altri clienti.

Cosa significa per le aziende italiane

In Italia questa non è una notizia per sistemisti: è una notizia per le PMI e per le web agency, perché l'hosting condiviso con cPanel è l'infrastruttura su cui vive la stragrande maggioranza dei siti aziendali, degli e-commerce di taglia piccola e media e delle caselle di posta di studi professionali e microimprese. Il pannello è lo standard di fatto presso i provider generalisti e presso i rivenditori che rivendono spazio comprato all'ingrosso.

Il rischio va letto in tre profili diversi, perché le responsabilità cambiano radicalmente:

  • Chi gestisce un VPS o un server dedicato con cPanel/WHM installato. Qui la patch è un vostro problema, subito. Se il server ospita clienti terzi, siete voi il confine di sicurezza che è saltato.
  • Chi ha un account reseller. Non potete aggiornare, ma avete sotto di voi clienti finali le cui credenziali sono la porta d'ingresso. L'igiene degli account che rivendete diventa, oggi, una questione di sicurezza dell'intero server.
  • Chi ha un semplice piano condiviso. Non potete fare nulla di tecnico, ma potete fare qualcosa di contrattuale e documentale — ed è esattamente quello che il GDPR si aspetta da voi.

C'è un dato interessante nella reazione del mercato. Reclaim Hosting, provider che serve numerose istituzioni accademiche, ha scelto la sera stessa del 27 agosto di disabilitare preventivamente la creazione di nuovi sottodomini, addon domain e domini parcheggiati su tutti i server interessati, lasciando funzionanti quelli già esistenti, in attesa di risolvere la questione. È la risposta corretta e vale la pena osservarla per due motivi: primo, dimostra che una mitigazione compensativa esiste anche senza che il vendor la suggerisca; secondo, mostra il costo reale di una vulnerabilità del genere, che non è solo il tempo di patching ma la sospensione di una funzionalità che i clienti usano quotidianamente. Quando scegliete un fornitore, la domanda giusta non è "avete mai avuto incidenti", è "cosa avete fatto il 27 agosto".

Il contesto normativo: chi risponde davvero

Il punto che nella mia esperienza viene sistematicamente frainteso dalle PMI è questo: il fatto che il server sia del provider non sposta la titolarità del trattamento. Se i dati dei vostri clienti stanno su quel cPanel, il titolare siete voi; il provider è responsabile del trattamento ai sensi dell'art. 28 GDPR. Ne discendono conseguenze concrete:

  • L'art. 32 GDPR vi chiede misure tecniche e organizzative adeguate al rischio. "Adeguato" include verificare che il fornitore applichi le patch critiche in tempi ragionevoli, e poterlo dimostrare. Se non avete un accordo che lo preveda, non avete una misura: avete una speranza.
  • L'art. 33 impone la notifica al Garante entro 72 ore dalla conoscenza di una violazione che comporti un rischio per i diritti degli interessati. Su un server condiviso compromesso a livello root, "conoscenza" spesso arriva da una comunicazione del provider: se il contratto non impone al responsabile di informarvi senza ingiustificato ritardo, le vostre 72 ore iniziano a scorrere tardi e male.
  • Sul fronte NIS2, recepita in Italia con il d.lgs. 138/2024, i fornitori di servizi di cloud computing e di hosting rientrano fra i soggetti destinatari degli obblighi. Se la vostra organizzazione è a sua volta soggetto essenziale o importante, la sicurezza della catena di fornitura ICT non è una buona pratica ma un obbligo esplicito: il vostro hosting è un fornitore, e va trattato come tale nell'analisi del rischio. Un incidente significativo comporta la notifica di preallerta al CSIRT Italia entro 24 ore e la notifica completa entro 72.

Cosa fare subito

Se amministrate il server:

  • Verificate la build installata da WHM in Server Configuration > Update Preferences. I server con aggiornamento automatico giornaliero ricevono la build corretta da soli, ma verificate: non date per scontato che l'automatismo sia attivo.
  • Per applicarla immediatamente, da root: /scripts/upcp --force. In alternativa da WHM, Home > cPanel > Upgrade to Latest Version.
  • Se siete su una versione end-of-life, pianificate la migrazione a un ramo supportato: non riceverete la correzione.
  • Come mitigazione temporanea, valutate di disabilitare la creazione di nuovi addon domain e domini parcheggiati fino a patch applicata, sull'esempio di quanto fatto da alcuni provider.
  • Fate un giro di verifica su chi può creare domini: account reseller, sub-account Team User, integrazioni automatiche. Riducete il perimetro.
  • Poiché la patch chiude la falla ma non annulla ciò che un attaccante ha già eventualmente fatto, controllate le tracce classiche di persistenza post-root: voci inattese in /etc/ld.so.preload, cron di root sconosciuti, binari SUID recenti, chiavi pubbliche aggiunte in /root/.ssh/authorized_keys, utenti di sistema creati di recente. È la stessa checklist che Plesk ha pubblicato ad agosto per un'altra falla di privilege escalation, e resta valida.

Se siete clienti di un hosting condiviso:

  • Scrivete al provider e chiedete per iscritto se i server che vi ospitano sono stati aggiornati e in quale data e ora. La risposta, o la sua assenza, è documentazione utile ai fini dell'art. 32.
  • Cambiate le password degli account cPanel e FTP e rimuovete gli account inutilizzati: ogni account dormiente sul vostro spazio è una potenziale porta d'ingresso al server di tutti.
  • Verificate di avere un backup fuori dal server compromettibile. Un backup che vive sulla stessa macchina che l'attaccante controlla come root non è un backup.
  • Se il provider vi comunica una compromissione, fate partire subito la procedura di data breach: valutazione del rischio, registro delle violazioni e, se necessario, notifica al Garante entro 72 ore.