Exploit attivo CVE-2026-41940: root su cPanel senza password
cPanel ha patchato una falla pre-autenticazione da CVSS 9.8 sfruttata da febbraio. Oltre 2.000 IP attaccano server non aggiornati con backdoor strutturate.
Contenuto
cPanel ha confermato il 28 aprile 2026 la patch per CVE-2026-41940, una vulnerabilità pre-autenticazione con punteggio CVSS 9.8 che consente a un attaccante remoto di ottenere una sessione root senza credenziali. Il vendor ha reso disponibili gli aggiornamenti in circa 28 ore dalla conferma del bug, ma ricercatori documentano exploitation in-the-wild già da febbraio con oltre 2.000 IP ancora attivi contro le istanze indietro. La CISA ha inserito la falla nel catalogo KEV il 1 maggio 2026, elevando la criticità per i provider con infrastrutture condivise.
- Il bug risiede in cpsrvd: durante l’autenticazione Basic, un percorso di gestione sessione non sanifica i valori in ingresso, permettendo l’iniezione di sequenze CRLF in un file sessione raw.
- Una successiva riparsificazione in cache JSON promuove le linee iniettate a chiavi top-level, inclusa la flag che disabilita il controllo password, generando una sessione root da zero credenziali.
- cPanel ha distribuito gli aggiornamenti il 28 aprile 2026 e dichiara che oltre il 98% dei server risulta già aggiornato al 10 maggio, ma ricercatori rilevano oltre 2.000 IP malevoli ancora attivi contro le istanze non patchate.
- Analisti di QiAnXin XLab hanno collegato una campagna specifica all’attore Mr_Rot13, che sfrutta la falla per installare la backdoor Filemanager; il vendor cPanel non ha tuttavia confermato né la backdoor né l’attore.
Come funziona il bypass: CRLF injection nel gestore di sessione cpsrvd
Il problema affonda le radici nel demone cpsrvd, il cuore di cPanel, WHM e WP Squared. Durante il flusso di autenticazione Basic, il server scrive i dati di sessione su disco attraverso un percorso che non applica la sanificazione dei valori in ingresso. Un attaccante può iniettare sequenze \r\n all’interno del file sessione raw, alterando la struttura interna del documento.
"Two separate code paths write to session files on disk: one path included an input-sanitisation step; a second path, invoked during Basic authentication handling, did not." — cPanel security advisory
Quando il gestore di sessione risponde a una condizione di errore specifica — il messaggio “token denied” — riparsifica il contenuto raw in una cache JSON. Durante questa conversione, le linee malevole vengono promosse a chiavi top-level. Tra queste figura la flag successful_internal_auth_with_timestamp, che convince il sistema di aver già verificato le credenziali interne. Il controllo password viene saltato, la sessione viene marcata come autenticata e, nel contesto di cPanel/WHM, spesso acquisisce privilegi root. Da quel punto l’RCE è immediata.
L’assenza di una singola chiamata alla funzione di sanificazione, in un ramo secondario del codice di autenticazione, ha quindi aperto una breccia totale nel perimetro di migliaia di server condivisi.
Da febbraio alle patch: la timeline di un exploitation in-the-wild silenzioso
Nonostante la pubblic disclosure sia avvenuta a fine aprile, le evidenze raccolte da watchTowr Labs indicano che l’exploitation in-the-wild era già in corso da febbraio 2026. I ricercatori hanno pubblicato l’analisi root cause e un proof-of-concept, confermando che gli attacchi precedevano di settimane la disponibilità della patch ufficiale rilasciata da cPanel il 28 aprile.
cPanel ha risposto con un ciclo di aggiornamento rapido: gli update sono stati resi disponibili in circa 28 ore dalla conferma interna della vulnerabilità. Al 10 maggio 2026 il vendor dichiarava che oltre il 98% dei server cPanel e WHM aveva già ricevuto le correzioni, raggiungendo una copertura massiccia in pochi giorni. Tuttavia, il residuo pari a circa il 2% — in un ecosistema che conta stime di circa 1,5 milioni di installazioni — rappresenta una superficie di attacco numerosa e concentrata spesso su provider con aggiornamenti disabilitati, versioni legacy o repository pinned.
La CISA ha inserito CVE-2026-41940 nel catalogo Known Exploited Vulnerabilities il 1 maggio 2026, segnalando la necessità di azione immediata per le amministrazioni federali statunitensi e fornendo un riferimento normativo alla gravità dello sfruttamento attivo.
Filemanager e Mr_Rot13: una campagna tra le molte
Parallelamente all’analisi tecnica, QiAnXin XLab ha documentato una campagna specifica che sfrutta la vulnerabilità per installare una backdoor denominata Filemanager. Secondo quanto riportato da editoriali specializzati, i ricercatori attribuiscono la distribuzione di questo payload all’attore Mr_Rot13, evidenziando come la campagna si aggiunga a un panorama più ampio di attacchi automatizzati.
La backdoor, scritta in Go, consente persistenza sul server compromesso attraverso chiavi SSH aggiuntive, webshell e raccolta credenziali tramite pagine di login iniettate. cPanel, nella sua advisory ufficiale, non menziona né l’attore Mr_Rot13 né la backdoor Filemanager, limitandosi alla descrizione del meccanismo root cause e alle metriche di aggiornamento. Non è quindi possibile stabilire se la campagna XLab rappresenti la totalità degli attacchi o solo una minaccia tra molte in corso.
QiAnXin XLab stima che più di 2.000 indirizzi IP malevoli in tutto il mondo siano attualmente coinvolti in attacchi automatizzati contro questa vulnerabilità. La stessa fonte riferisce il furto di circa 4,37 GB di dati sensibili da enti governativi e militari del Sud-Est Asiatico, un dato che non è stato verificato indipendentemente dalle fonti primarie del vendor.
Il rischio del 2% non aggiornato: una superficie ancora troppo vasta
La percentuale di server patchati è alta, ma in valore assoluto il residuo non aggiornato rimane preoccupante. Server con auto-update disabilitato, ambienti legacy o configurazioni gestite da hosting provider terzi su repository pinned possono rimanere esposti per settimane. cPanel raccomanda di trattare ogni istanza non corretta entro il 28 aprile come potenzialmente compromessa, anche se non mostra segni evidenti di intrusione.
La persistenza introdotta dagli attaccanti rende complessa l’eradicazione. Chiavi SSH aggiunte, webshell nascoste in percorsi non standard e modifiche alla pagina di login per il credential harvesting sopravvivono alla semplice applicazione della patch. Senza una risposta a incidente strutturata, un server aggiornato può rimanere controllato dall’attaccante.
Cosa fare adesso
- Applicare immediatamente gli aggiornamenti rilasciati il 28 aprile 2026 e verificare che anche le installazioni WHM e WP Squared rientrino nel perimetro di patch, dato che il bug risiede nel demone cpsrvd condiviso.
- Trattare come sospetti tutti i server che al 28 aprile non erano ancora aggiornati: eseguire audit completo di chiavi SSH autorizzate, webshell nascoste e anomalie nelle pagine di login che potrebbero indicare credential harvesting.
- Correlare i log di accesso pre-aprile con gli IoC diffusi dalla threat intelligence indipendente, inclusi gli oltre 2.000 IP malevoli rilevati da QiAnXin XLab, per identificare tentativi di exploitation passati.
- Rimuovere blocchi su auto-update e versioni pinned legacy che impediscono la ricezione delle correzioni, e attivare monitoraggio sui path di autenticazione Basic per rilevare tentativi di CRLF injection residui.
Il tempo tra l’exploitation silenziosa di febbraio e la patch di aprile ha lasciato una finestra in cui anche un singolo server condiviso può aver ospitato compromissioni multiple. La velocità di risposta del vendor non cancella la necessità di un controllo radicale sulle istanze rimaste indietro.
Domande frequenti
La vulnerabilità colpisce solo cPanel?
No. Il bug risiede nel demone cpsrvd, componente condiviso con WHM e WP Squared. Tutte le piattaforme che utilizzano questo servizio di gestione sessione nella versione vulnerabile sono esposte.
Un server patchato il 29 aprile è da considerare sicuro?
La patch blocca il vettore di ingresso, ma non rimuove eventuali payload o accessi compromessi acquisiti prima dell’aggiornamento. Se il server era esposto durante la finestra di exploitation, è necessario condurre una risposta a incidente completa.
Perché un singolo file di sessione ha permesso il bypass totale?
La mancanza di sanificazione in un solo ramo del codice di autenticazione Basic ha permesso di iniettare sequenze CRLF nel file raw. La successiva riparsificazione in JSON ha elevato quelle righe a parametri top-level, inclusa la flag che marca la sessione come già autenticata internamente, aggirando ogni verifica password.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/05/cpanel-cve-2026-41940-under-active.html
- https://securityaffairs.com/192013/cyber-crime/attackers-exploit-cpanel-cve-2026-41940-to-deploy-filemanager-backdoor.html
- https://thomasharris6.wordpress.com/2026/05/11/cpanel-cve-2026-41940-under-active-exploitation-to-deploy-filemanager-backdoor/
- https://www.picussecurity.com/resource/blog/cve-2026-41940-explained-cpanel-whm-authentication-bypass-hit-1-5m-servers
- https://www.cpanel.net/blog/security/security-update-cve-2026-41940/