CVE-2026-41940: bypass di autenticazione in cPanel e WHM, cosa verificare subito

In sintesi: CVE-2026-41940 è una vulnerabilità critica nel flusso di login di cPanel e WHM. Secondo NVD, permette ad attaccanti remoti non autenticati di ottenere accesso non autorizzato al pannello. Per chi gestisce hosting condiviso, server reseller o macchine con WHM esposto, la priorità è aggiornare subito, ridurre l'esposizione delle porte di gestione e verificare eventuali indicatori di compromissione.

Perché è urgente

cPanel ha pubblicato l'avviso di sicurezza il 28 aprile 2026 e lo ha aggiornato il 30 aprile 2026. L'advisory indica che il problema riguarda cPanel, WHM e DNSOnly nelle versioni successive alla 11.40, con patch disponibili per più rami supportati.

Il rischio operativo è alto perché WHM non è un semplice pannello: controlla account hosting, configurazioni, email, database, file web e privilegi amministrativi. Un accesso non autorizzato può portare a web shell, redirect malevoli, furto di credenziali applicative, modifica dei DNS interni o persistenza sugli account compromessi.

Dettaglio tecnico della catena

La parte più importante per un team difensivo è capire dove cercare, non replicare l'exploit.

Le analisi pubbliche indicano una falla nel caricamento e salvataggio delle sessioni di cPanel e WHM. Il servizio cpsrvd crea file di sessione prima che l'autenticazione sia completata. Se input non fidato viene scritto in modo non sanificato nel file di sessione, un attaccante può provare a far comparire attributi che non dovrebbero esistere in una sessione pre-auth.

La catena descritta dai ricercatori passa da:

sessione creata durante una richiesta non autenticata;
manipolazione del flusso di login e dei valori legati alla sessione;
iniezione di caratteri di nuova riga nel dato poi persistito su disco;
ricaricamento della sessione con attributi alterati;
promozione logica della sessione oltre il punto in cui dovrebbe fallire.

Questo spiega perché gli IOC di cPanel cercano combinazioni anomale dentro /var/cpanel/sessions, come sessioni nate da badpass che contengono campi associati a token o stati autenticati. Il punto difensivo è trattare la sessione come artefatto forense: origine, timestamp, token, stato 2FA e riuso nei log HTTP vanno correlati.

Segnali da cercare nei log

Durante il triage, cercare soprattutto:

richieste a whostmgrd o cpsrvd seguite da sessioni promosse in modo inatteso;
sessioni con origine badpass ma attributi successivi non coerenti;
presenza simultanea di campi di errore token e token di sessione valorizzati;
accessi riusciti poco dopo tentativi di login falliti dalla stessa sorgente;
richieste su porte 2083, 2087, 2095 e 2096 da ASN o paesi inattesi;
modifiche ad account, pacchetti, zone DNS, forwarder email o file web subito dopo il possibile evento.

Se un indicatore è positivo, la risposta deve assumere compromissione possibile. Non basta cancellare la sessione: bisogna ruotare credenziali, verificare utenti e controllare persistenza.

Versioni da portare in produzione

Le versioni corrette indicate da cPanel includono:

11.86.0.41
11.110.0.97
11.118.0.63
11.126.0.54
11.130.0.19
11.132.0.29
11.134.0.20
11.136.0.5

Per WP Squared, cPanel indica 136.1.7.

La regola pratica è semplice: se il server è cPanel e la versione non rientra tra quelle corrette per il proprio ramo, va trattato come esposto fino a verifica contraria.

Azioni immediate

Eseguire l'aggiornamento cPanel forzato seguendo la procedura ufficiale del vendor.
Verificare la versione effettiva restituita dal server dopo l'update.
Riavviare cpsrvd come indicato nell'advisory.
Se l'update non è possibile subito, bloccare temporaneamente l'accesso pubblico alle porte di gestione 2083, 2087, 2095 e 2096, limitandole a IP amministrativi o VPN.
Eseguire il controllo degli indicatori di compromissione suggerito da cPanel.
Rivedere access log WHM, sessioni cPanel, utenti creati di recente, chiavi SSH, cron e file modificati nelle ultime 72 ore.

Per server con update pinning, policy di update disabilitate o versioni fuori supporto, il punto critico è non affidarsi all'auto-update: serve verifica manuale.

Dove dare priorità

La priorità più alta va a:

provider hosting e reseller con molti account sullo stesso WHM;
server cPanel esposti direttamente a Internet;
ambienti dove WHM è accessibile senza VPN o allowlist IP;
server che hanno già subito login sospetti o tentativi massivi sulle porte cPanel;
hosting con WordPress, email e database di più clienti sullo stesso nodo.

Per una PMI che usa hosting gestito, l'azione corretta è chiedere conferma scritta al provider: versione corretta installata, data e ora dell'update, eventuali blocchi temporanei sulle porte, controlli IOC eseguiti.

Controlli post-patch

Dopo l'aggiornamento non basta vedere "versione nuova". Bisogna verificare:

che il servizio risponda solo dove previsto;
che gli account WHM e cPanel non abbiano nuove chiavi, forwarder o utenti inattesi;
che non siano apparsi file PHP anomali nelle webroot;
che non ci siano job cron non autorizzati;
che i log non mostrino sessioni anomale prima della patch;
che backup e snapshot precedenti all'incidente siano disponibili.

La vulnerabilità è di autenticazione: se c'è il sospetto di sfruttamento, la risposta corretta include rotazione credenziali, revisione degli account e controllo di persistenza, non solo patch.

Fonti

Come può aiutare SecBox

SecBox può aiutare a ridurre l'esposizione dei pannelli amministrativi, applicare allowlist, monitorare accessi anomali e costruire una checklist di verifica post-patch per server hosting e VPS aziendali.

Richiedi una verifica urgente dell'esposizione del tuo hosting