Falla di cPanel: perché dopo il ripristino bisogna cercare la porta rimasta aperta

A fine aprile 2026 cPanel, il pannello con cui si gestisce una parte importante dei siti web e dei negozi online, ha corretto una falla critica, la CVE-2026-41940, che permetteva di ottenere l’accesso da amministratore senza conoscere la password. Secondo le ricostruzioni pubblicate in quei giorni, la falla veniva sfruttata almeno dal 23 febbraio, due mesi prima della correzione. Chi ha un sito su un server cPanel deve quindi fare due cose, non una: aggiornare e verificare che nessuno sia già entrato. Il backup rimette online il sito; solo un’analisi forense, cioè la ricostruzione tecnica di che cosa è successo, dice se la copia ripristinata contiene ancora la porta lasciata aperta.

Che cosa è successo, in breve?

Per la maggior parte delle persone la settimana è passata senza che se ne accorgessero. Per chi gestisce server web è stata una corsa agli aggiornamenti e ai controlli.

Rapid7 ha stimato, con dati del motore di ricerca Shodan, circa 1,5 milioni di istanze cPanel raggiungibili da internet, senza poter dire quante fossero vulnerabili. Le versioni interessate erano tutte quelle successive alla 11.40. Le indicazioni di cPanel sono state nette: aggiornare subito, verificare la versione installata, riavviare il servizio del pannello e usare lo script fornito per cercare segni di compromissione.

Perché una falla chiusa può lasciare una porta aperta?

Perché l’aggiornamento corregge l’errore, non cancella ciò che un attaccante ha fatto mentre l’errore era aperto. Con l’accesso da amministratore a un pannello di gestione si possono creare nuovi account, generare chiavi di accesso per programmi (token API), aggiungere chiavi SSH per collegarsi al server, programmare attività automatiche, caricare file nelle cartelle dei siti. Tra questi file c’è spesso una web shell: una piccola pagina che, richiamata dall’esterno, esegue comandi sul server.

Sono porte sul retro che possono restare inattive per settimane, in attesa di essere usate o rivendute. Non è un’ipotesi di scuola: il rapporto M-Trends 2026 di Mandiant, pubblicato a marzo 2026, indica la compromissione precedente come terzo modo di entrare a livello globale nel 2025 (10% delle intrusioni) e come primo negli attacchi ransomware (30%). Chi colpisce, spesso, usa una porta aperta da qualcun altro mesi prima.

Uno scenario tipico: l’e-commerce che si rompe due volte

Uno scenario ricostruito sulle dinamiche di questi attacchi, non un caso reale. Un’azienda vende online con un negozio ospitato su un server gestito con cPanel. Un sabato mattina gli ordini si fermano: la pagina di pagamento rimanda altrove. Il fornitore di hosting aggiorna il pannello, ripristina la copia della notte precedente e il sito torna online in giornata. Tutti tirano un sospiro di sollievo.

Due settimane dopo, il problema si ripresenta. La copia ripristinata era pulita solo in apparenza: conteneva una web shell caricata a marzo, quando la falla era già sfruttata ma non ancora nota. Il backup aveva salvato la giornata; mancava il lavoro che salva la successiva, cioè capire da quando l’attaccante era dentro, che cosa aveva lasciato e che cosa aveva letto.

È la stessa logica dei tre pilastri raccontati nell’articolo sul tassello mancante: il backup permette di ripartire, ma non dice se si riparte da una situazione sana.

Che cosa controllare su un server cPanel dopo l’aggiornamento?

Se il server è gestito dal fornitore di hosting, i controlli spettano in gran parte a lui, ma l’azienda deve chiederne l’esito. Se è gestito internamente, l’elenco è questo:

1. La versione. La build installata deve essere tra quelle corrette e il servizio del pannello deve essere stato riavviato, come indicato da cPanel.
2. Gli indicatori di compromissione. Lo script messo a disposizione da cPanel va eseguito, e il risultato conservato.
3. Account e accessi. Utenti del pannello e rivenditori, token API, chiavi SSH, account FTP e caselle email creati o modificati dopo il 23 febbraio.
4. Attività pianificate e processi. Operazioni automatiche mai decise da nessuno, programmi in esecuzione che nessuno riconosce.
5. I file dei siti. File modificati di recente, soprattutto file eseguibili nelle cartelle di caricamento, e le pagine di pagamento, dove un codice aggiunto può copiare i dati delle carte.
6. I registri. Accessi al pannello e al server web dal 23 febbraio in poi, se esistono ancora: è il motivo per cui conviene conservarli a lungo e altrove, come spiega l’articolo su Sherlock Holmes e i file di log.
7. Le credenziali. Nuove password per pannello, database, posta e servizi di pagamento collegati; sessioni aperte chiuse; chiavi API rigenerate.
8. L’esposizione. Accesso al pannello limitato agli indirizzi dell’azienda o a una rete privata virtuale, non aperto a tutto internet.

Da quale copia ripartire?

Dalla più recente che sia sicuramente precedente al primo accesso dell’attaccante. Il problema è che quella data, all’inizio, nessuno la conosce: se lo sfruttamento è cominciato a febbraio, una copia di aprile può contenere già la porta sul retro. Per questo il ripristino si fa per parti, non in blocco.

La cronologia ricostruita dall’analisi forense indica il punto da cui fidarsi e permette di rispondere alla domanda che interessa anche ai legali: quali dati sono stati letti o copiati.

Che cosa chiedere al fornitore di hosting?

Molte aziende non gestiscono il server, ma restano responsabili del sito e dei dati dei clienti. Sei domande da fare per iscritto:

• In che data avete installato l’aggiornamento sul nostro server?
• Avete eseguito lo script di cPanel per gli indicatori di compromissione, e con quale esito sul nostro account?
• Per quanto tempo conservate i registri di accesso al pannello e al server web?
• Da quale data sono disponibili le copie di sicurezza, e dove sono conservate?
• Chi ha accesso amministrativo al server, oltre a voi?
• Come e con quali tempi ci avvisate se trovate qualcosa?

Le risposte dicono molto della qualità del fornitore, e vanno conservate con la documentazione dell’incidente.

Ci sono obblighi di notifica?

Dipende da che cosa è stato toccato. Un negozio online tratta dati personali dei clienti: se c’è stato un accesso non autorizzato, il GDPR chiede di notificare la violazione all’autorità di controllo (in Italia il Garante per la protezione dei dati personali) entro 72 ore dalla scoperta, ove possibile, salvo che sia improbabile un rischio per le persone; se il rischio è elevato vanno avvisati anche gli interessati. Le aziende soggette alla NIS2 hanno anche i termini verso il CSIRT Italia per gli incidenti significativi. La valutazione si fa con il DPO e con i legali. Per le imprese sammarinesi il quadro è diverso e va valutato caso per caso.

In sintesi

• La CVE-2026-41940 permetteva di entrare come amministratori nei pannelli cPanel senza password; la correzione è del 28 aprile 2026.
• Gli sfruttamenti erano in corso almeno dal 23 febbraio: aggiornare non basta, bisogna cercare ciò che l’attaccante ha lasciato.
• Una porta sul retro sopravvive all’aggiornamento e, spesso, anche al ripristino da backup.
• I controlli riguardano versione, indicatori di compromissione, account, chiavi, attività pianificate, file dei siti, registri e credenziali.
• Si riparte per parti: applicazione da fonti originali, dati dopo un controllo, credenziali tutte nuove.
• Con dati dei clienti coinvolti, la notifica al Garante va valutata entro 72 ore.

Domande frequenti

Il nostro sito non usa cPanel: siamo al sicuro?

Da questa falla sì, ma la lezione vale per qualsiasi pannello di gestione esposto su internet. Conviene sapere quale pannello usa il vostro fornitore, come viene aggiornato e chi può raggiungerlo.

Se l’hosting ha già aggiornato, dobbiamo fare qualcosa?

Sì: chiedere l’esito dei controlli sugli indicatori di compromissione per il vostro account, verificare utenti e file del sito, cambiare le credenziali. L’aggiornamento chiude la falla, ma non dice se qualcuno è entrato prima.

Un antivirus sul server basta a trovare una porta sul retro?

Non sempre. Una web shell può essere un file di poche righe, simile a quelli legittimi del sito. Servono il confronto con i file originali, l’analisi dei registri e la verifica di account, chiavi e attività pianificate.

Quanto indietro bisogna guardare nei registri?

Almeno fino alla data dei primi sfruttamenti noti, cioè il 23 febbraio 2026, e oltre se emergono segnali precedenti. Se i registri non arrivano così lontano, va detto chiaramente nel resoconto: è un limite dell’indagine.

Serve rifare il sito da zero?

Non sempre. Spesso basta reinstallare l’applicazione da pacchetti originali, ripristinare i contenuti dopo un controllo e cambiare tutte le credenziali. La scelta dipende da che cosa emerge dall’analisi.

Una falla diffusa si chiude in un giorno; le porte aperte mentre era sfruttata si trovano solo cercandole. La divisione Cybersecurity di Strategic si occupa di gestione degli incidenti e analisi forense: ricostruire da quando l’attaccante era dentro, da quale copia ripartire e che cosa comunicare, insieme all’IT, al fornitore di hosting e ai legali dell’azienda.

Fonti

• Rapid7, CVE-2026-41940: cPanel & WHM Authentication Bypass, 29 aprile 2026
• Help Net Security, cPanel zero-day exploited for months before patch release (CVE-2026-41940), 30 aprile 2026, aggiornato il 1° maggio 2026
• CyberScoop, cPanel’s authentication bypass bug is being exploited in the wild, CISA warns, 30 aprile 2026
• NIST, National Vulnerability Database, CVE-2026-41940
• CISA, Known Exploited Vulnerabilities Catalog
• Mandiant (Google Cloud), M-Trends 2026, marzo 2026
• NSA e ASD, Detect and Prevent Web Shell Malware, annuncio CISA del 22 aprile 2020
• Regolamento (UE) 2016/679 (GDPR), articoli 33 e 34, EUR-Lex
• Garante per la protezione dei dati personali, Data breach