Zero-day cPanel: la lezione dei due mesi di silenzio

Il 28 aprile 2026 WebPros ha pubblicato la patch per CVE-2026-41940, una vulnerabilità di autenticazione di cPanel & WHM con punteggio CVSS 9.8. Due giorni dopo, le honeypot della Shadowserver Foundation registravano già 44.000 indirizzi IP attivi nello scanning e nello sfruttamento. Ma il dettaglio che fa più rumore non è nel bollettino: lo zero-day circolava dal 23 febbraio. Due mesi pieni in cui gli attaccanti hanno avuto via libera su un software installato su circa 1,5 milioni di server pubblici.

La storia non parla solo di una falla in cPanel. Parla di come è fatta la filiera che tiene online il tuo sito.

Cronologia di uno zero-day che è viaggiato per due mesi

La timeline ricostruita da Help Net Security, Rapid7 e watchTowr Labs racconta una sequenza precisa:

• 23 febbraio 2026 - Prime tracce di sfruttamento mirato contro entità governative del Sudest asiatico. La vulnerabilità non è ancora pubblica: nessun difensore può sapere che esiste.
• 28 aprile 2026 - WebPros pubblica il bollettino di sicurezza e rilascia le patch nelle ore successive (versioni 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20, 11.136.0.5; WP Squared in 136.1.7).
• 30 aprile 2026 - Shadowserver registra 44.000 IP coinvolti in scansioni e brute-force; circa 650.000 istanze cPanel/WHM risultano esposte su Internet. L'exploit pubblico si diffonde in poche ore.
• 3 maggio 2026 - Scadenza CISA BOD 22-01: tutte le agenzie federali statunitensi devono aver patchato. CVE-2026-41940 entra nel catalogo Known Exploited Vulnerabilities.
• 4 maggio 2026 - TechCrunch riporta sfruttamento di massa: distribuzione di varianti della botnet Mirai e di un nuovo ransomware chiamato "Sorry", con MSP e provider di hosting tra i bersagli principali.

Tradotto: chiunque gestisse un server cPanel a febbraio era esposto, senza saperlo, a un attaccante non autenticato in grado di prendere il controllo amministrativo del pannello. E nessuna patch poteva difenderlo.

CRLF injection: il bug spiegato in tre righe

Nel cuore di cpsrvd - il demone che gestisce le sessioni di cPanel - l'header Authorization: Basic … viene scritto sul disco prima dell'autenticazione e senza sanificazione. Iniettando un \r\n grezzo nel valore Base64, l'attaccante riesce ad appendere proprietà arbitrarie al file di sessione, inclusa user=root. Al successivo reload, cpsrvd si fida del file e concede privilegi di amministratore.

È un classico CRLF injection, della classe di bug che si insegnava nei corsi di web security quindici anni fa. Sopravvissuto in produzione su un software che regge un pezzo importante del web ospitato.

Perché due mesi sono troppi

C'è una differenza enorme tra "vulnerabilità divulgata oggi, patch domani" e "vulnerabilità sfruttata nel silenzio per due mesi prima che qualcuno se ne accorga". Nel primo caso il difensore parte alla pari con l'attaccante: appena il fix è disponibile, il rischio si sposta su chi non aggiorna. Nel secondo caso, chi è stato compromesso a marzo 2026 oggi non sta solo patchando un buco: sta provando a chiudere una porta in una casa in cui qualcuno potrebbe essere già dentro da settimane, con webshell, cron job e account WHM creati ad hoc.

Per questo, in scenari come CVE-2026-41940, applicare la patch non basta. L'unica risposta corretta dopo due mesi di esposizione è: patch immediata, audit forense del sistema, rotazione totale delle credenziali, revisione di account, cron, processi e file modificati di recente. È un lavoro che la maggior parte degli utenti finali - il piccolo studio, l'e-commerce con cinquanta ordini al giorno, il freelance con tre WordPress in produzione - non sa fare e non dovrebbe nemmeno dover fare da solo.

La lezione sulla supply chain dell'hosting

Quando compri un piano hosting, stai comprando una catena di responsabilità. Sistema operativo, pannello, PHP, MySQL, web server, rete, monitoring: ogni anello è una scelta che il provider fa per te. Tu paghi, e tu subisci quando un anello si rompe.

CVE-2026-41940 mette in chiaro tre cose che è facile dimenticare quando si confrontano i preventivi:

1. Un pannello popolare non è un pannello sicuro per definizione. cPanel è installato su milioni di server proprio perché è lo standard di mercato. Questo lo rende un bersaglio prioritario, non un fortino. Lo stesso vale per WordPress, per OpenSSL, per qualsiasi software che gira su una fetta significativa del web.
2. La velocità di reazione del provider conta più del prezzo. Tra il 28 e il 30 aprile, la differenza tra "siamo già patchati" e "ci pensiamo lunedì" ha deciso quali siti finivano nella botnet Mirai e quali no. Quella differenza dipende interamente dalla cultura operativa del tuo host: automazioni, monitoraggi, runbook, on-call.
3. La trasparenza non è un di più, è il prodotto. Negli stessi giorni alcuni provider hanno pubblicato status page chiare ("patch applicata il 28 aprile alle 22:30, audit X e Y completati il 29"); altri hanno taciuto. Quando si parla di supply chain, se non te lo dicono, è perché non lo stanno facendo - o perché non sanno di doverlo dire.

Se a febbraio 2026 hai scelto un fornitore confrontando solo GB di spazio e prezzo mensile, oggi hai poche informazioni per sapere se sei stato esposto. È un costo nascosto che diventa visibile solo nei momenti come questo.

Cosa fare se gestisci un sito su cPanel

Non si può evitare il lavoro a freddo, ma la superficie si riduce con poche mosse concrete:

• Verifica subito la versione cPanel/WHM. Da terminale cpanel -V, oppure da WHM in Server Configuration → cPanel Versioning. Se non sei almeno alle versioni 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20 o 11.136.0.5, sei vulnerabile.
• Chiedi al tuo host una conferma scritta. Una mail di tre righe: "Avete applicato la patch CVE-2026-41940? Quando? Avete eseguito un audit post-patch?". La qualità della risposta ti dice quasi tutto.
• Cerca indicatori di compromissione. File di sessione anomali in /var/cpanel/sessions/, account WHM recenti che non riconosci, cron job inattesi, processi cpsrvd con argomenti strani. CISA e Rapid7 hanno pubblicato IoC dettagliati.
• Ruota tutte le credenziali. Account WHM, root, database, FTP, email, chiavi API. Se sei stato esposto, lo eri prima del 28 aprile.
• Abilita l'autenticazione a due fattori dove il pannello la supporta, e limita l'accesso a WHM per IP quando possibile.
• Rivedi la scelta del fornitore. Se gestisci dati sensibili o un e-commerce, valuta piani hosting condiviso con SLA espliciti su patch e audit, o sposta i carichi più critici in cloud dove l'isolamento è più robusto. E controlla che il certificato sia gestito correttamente: i certificati SSL inclusi e rinnovati in automatico riducono un'altra fonte di errore umano.

Chi ha già visto questa scena lo sa: i ransomware EV che colpivano WordPress qualche tempo fa seguivano un copione molto simile - bug → exploit di massa → payload distruttivo. Il pattern non cambia, cambiano i nomi.

Conclusione

CVE-2026-41940 sarà completamente patchato nel giro di pochi giorni, ma lo strascico vero è un altro. È la consapevolezza che, per due mesi, una porzione enorme del web ospitato su cPanel è stata aperta senza che nessun difensore potesse saperlo. Il software perfetto non esiste e gli zero-day continueranno ad esistere; quello che cambia, dal lato di chi paga la bolletta, è la qualità della filiera che ti protegge quando arrivano.

È lì che si misura davvero un buon hosting - e non si misura nel preventivo.