LiteSpeed zero-day 2026: cosa è successo e come proteggere il server

LiteSpeed zero-day 2026: la vulnerabilità resa pubblica a settembre ha riportato l’attenzione sulla sicurezza dei server hosting e sull’importanza di mantenere aggiornato non soltanto WordPress, ma anche l’intero stack che permette ai siti web di funzionare.

Il 16 settembre 2026 Hostinger ha dichiarato di aver rilevato un attacco su uno dei propri server di hosting condiviso in Brasile che sfruttava una vulnerabilità precedentemente non rilevata di LiteSpeed Web Server Enterprise.

Nel caso documentato dal provider, l’attaccante sarebbe riuscito a passare dai privilegi limitati di un normale account hosting fino all’accesso root del server, superando anche i confini di isolamento previsti da CloudLinux CageFS.

LiteSpeed ha successivamente distribuito ulteriori correzioni e la raccomandazione per gli amministratori è utilizzare LiteSpeed Enterprise 6.3.7 Build 2 o successiva.

Vediamo cosa è successo, cosa significa realmente zero-day, come controllare la build installata e quali verifiche abbiamo effettuato sull’infrastruttura Xlogic.

Cos’è una vulnerabilità zero-day?

Una vulnerabilità zero-day è un problema di sicurezza che può essere sfruttato prima che sia disponibile una correzione adeguata o prima che il problema sia conosciuto e gestito dal produttore.

Il termine deriva proprio dal fatto che chi sviluppa il software può trovarsi ad avere idealmente zero giorni di preavviso per preparare la patch.

Il processo può essere semplificato così:

vulnerabilità
↓
scoperta o sfruttamento
↓
analisi
↓
sviluppo della patch
↓
aggiornamento dei server
↓
verifica e monitoraggio

È importante però chiarire subito un punto: la presenza di una vulnerabilità non significa automaticamente che tutti i server che utilizzavano quella versione siano stati compromessi.

Significa che esisteva una possibilità di attacco e che gli amministratori devono aggiornare rapidamente e verificare eventuali indicatori di compromissione.

LiteSpeed zero-day 2026: cosa è successo?

Secondo il resoconto tecnico pubblicato da Hostinger, il 16 settembre 2026 alle 13:08 UTC i sistemi di monitoraggio del provider hanno rilevato attività anomala su un server situato nel data center brasiliano.

L’indagine avrebbe individuato un attacco che sfruttava una vulnerabilità critica di LiteSpeed Web Server Enterprise.

Nello scenario osservato, un utente con privilegi limitati su un server shared sarebbe riuscito a:

• oltrepassare i normali confini dell’account hosting;
• superare l’isolamento atteso di CageFS;
• scrivere o modificare file con privilegi elevati;
• raggiungere privilegi root sul server.

Hostinger riferisce che l’attaccante ha distribuito webshell su 399 account presenti sul server interessato e che sono stati rilevati comandi non autorizzati su 11 di questi.

Il provider afferma inoltre di aver isolato il server, sospeso gli account associati all’attaccante, rimosso attività pianificate malevole e collaborato direttamente con LiteSpeed per lo sviluppo della correzione.

Perché una privilege escalation è particolarmente grave?

Su un normale servizio di hosting condiviso ogni cliente dovrebbe operare esclusivamente all’interno del proprio account.

Se un sito WordPress viene compromesso, il comportamento atteso dovrebbe essere:

WordPress compromesso
↓
account hosting compromesso
↓
isolamento
↓
STOP

L’attaccante non dovrebbe poter accedere ai dati degli altri clienti e soprattutto non dovrebbe poter ottenere privilegi amministrativi sul sistema operativo.

Una vulnerabilità di privilege escalation diventa quindi particolarmente critica perché può consentire di superare questo confine.

CloudLinux CageFS e isolamento degli account

Nei server hosting condivisi vengono normalmente utilizzati diversi livelli di isolamento.

CloudLinux mette a disposizione CageFS, un filesystem virtualizzato che separa gli utenti e limita la visibilità dei file e delle risorse appartenenti agli altri account.

L’obiettivo è impedire che la compromissione di un singolo sito possa trasformarsi automaticamente in un problema per tutto il server.

Secondo l’advisory pubblicato da cPanel, la vulnerabilità LiteSpeed poteva in determinate condizioni consentire a un utente malevolo di oltrepassare anche i normali controlli di isolamento di CageFS.

Quale versione corregge il problema?

La raccomandazione aggiornata è utilizzare:

LiteSpeed Web Server Enterprise 6.3.7 Build 2 o successiva.

Il dettaglio della build è fondamentale.

Controllare semplicemente:

LiteSpeed/6.3.7 Enterprise

non è sufficiente per sapere se è presente l’ultimo aggiornamento di sicurezza.

LiteSpeed ha distribuito infatti più build della stessa versione 6.3.7:

Le modifiche sono riportate nel changelog ufficiale di LiteSpeed Web Server.

Anche chi aveva già LiteSpeed 6.3.7 deve controllare la build

È uno degli aspetti più importanti del LiteSpeed zero-day 2026.

cPanel ha aggiornato il proprio advisory specificando esplicitamente che chi aveva già installato la versione 6.3.7 doveva effettuare nuovamente l’upgrade per ottenere Build 2 o successiva.

È quindi possibile avere due server che riportano entrambi:

LiteSpeed/6.3.7 Enterprise

ma uno può essere:

Build 0

e l’altro:

Build 2

Dal punto di vista della verifica di sicurezza questa differenza è essenziale.

Come verificare la versione LiteSpeed installata

Da shell è possibile controllare la versione principale con:

/usr/local/lsws/bin/lshttpd -v

Un risultato tipico è:

LiteSpeed/6.3.7 Enterprise

Per conoscere la build installata bisogna invece verificare:

cat /usr/local/lsws/BUILD

Per un server aggiornato alla build raccomandata il risultato deve essere almeno:

2

La situazione attesa è quindi:

LiteSpeed/6.3.7 Enterprise
Build 2

Come aggiornare LiteSpeed Enterprise

L’advisory cPanel indica questo comando per aggiornare LiteSpeed 6.3.7 alla build più recente:

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7

L’opzione -f forza la reinstallazione della versione e permette quindi di ottenere una build più recente anche quando sul server è già presente LiteSpeed 6.3.7.

Terminato l’aggiornamento è opportuno verificare nuovamente:

cat /usr/local/lsws/BUILD

e controllare che venga restituito almeno:

2

Riavviare e controllare il servizio

Dopo l’aggiornamento è necessario verificare che LiteSpeed sia correttamente in esecuzione.

A seconda della distribuzione Linux e del pannello di controllo utilizzato, l’unità systemd può presentarsi con nomi differenti, ad esempio:

lshttpd.service
litespeed.service
lsws.service

Lo stato corretto deve risultare:

Active: active (running)

Il comando ufficiale LiteSpeed per il restart è:

/usr/local/lsws/bin/lswsctrl restart

Verificare HTTP e HTTPS dopo l’aggiornamento

Aggiornare il software non basta: bisogna anche controllare che il web server continui a rispondere regolarmente.

Per HTTP è possibile utilizzare:

curl -sSI --max-time 10 http://127.0.0.1/ | head -1

Per HTTPS:

curl -skSI --max-time 10 https://127.0.0.1/ | head -1

Risposte come:

HTTP/1.1 200 OK
HTTP/2 200

confermano che il web server sta rispondendo correttamente alle richieste locali.

LiteSpeed zero-day 2026: cosa ha verificato Xlogic

Xlogic utilizza LiteSpeed Enterprise sulla propria infrastruttura hosting.

Dopo la pubblicazione dell’advisory relativo al LiteSpeed zero-day 2026 abbiamo verificato i server controllando:

• versione LiteSpeed Enterprise;
• numero esatto della build;
• stato del servizio;
• risposta HTTP;
• risposta HTTPS;
• funzionamento dei siti;
• rilevamenti malware presenti sugli account.

I server verificati risultano allineati alla versione:

LiteSpeed Enterprise 6.3.7
Build 2

I test HTTP e HTTPS eseguiti dopo l’aggiornamento hanno inoltre confermato il normale funzionamento del web server.

Infrastruttura Xlogic: i server LiteSpeed Enterprise sono stati verificati e risultano aggiornati alla versione 6.3.7 Build 2 raccomandata dopo l’advisory di sicurezza di settembre 2026.

Per approfondire perché utilizziamo questa tecnologia puoi leggere anche l’articolo dedicato a Xlogic e LiteSpeed.

Essere stati su una build precedente significa essere stati compromessi?

No.

Questo è un punto importante per evitare interpretazioni errate.

Un server che utilizzava una build precedente non deve essere considerato automaticamente compromesso.

La procedura corretta è:

aggiornare
↓
verificare
↓
analizzare
↓
monitorare

Dopo l’aggiornamento è opportuno cercare eventuali indicatori di compromissione, tra cui:

• account amministrativi inattesi;
• cron sospetti;
• nuove chiavi SSH;
• file PHP nascosti;
• webshell;
• processi insoliti;
• connessioni di rete anomale;
• file appartenenti a clienti modificati in modo sospetto;
• malware distribuito contemporaneamente su account differenti.

Malware WordPress e vulnerabilità LiteSpeed non sono la stessa cosa

Durante una verifica di sicurezza può capitare di trovare uno o più siti WordPress già compromessi.

Questo non dimostra automaticamente che il LiteSpeed zero-day 2026 sia stato utilizzato per comprometterli.

WordPress può essere infettato attraverso numerosi vettori differenti:

• plugin vulnerabili;
• temi obsoleti;
• credenziali compromesse;
• plugin o temi nulled;
• password FTP rubate;
• malware presente sul computer dell’amministratore;
• vecchie backdoor mai eliminate;
• installazioni non aggiornate.

Prima di collegare un’infezione a una vulnerabilità del server bisogna quindi ricostruire la timeline.

Perché le date dei file sono importanti

Uno dei controlli più semplici consiste nell’analizzare i metadati del filesystem.

Con:

stat nome-file.php

è possibile verificare informazioni come:

• data di creazione;
• ultima modifica;
• ultimo cambio dei metadati;
• proprietario;
• dimensione del file.

Se una backdoor risulta presente da settimane o mesi prima della finestra temporale della vulnerabilità LiteSpeed, non è corretto attribuirla automaticamente al nuovo exploit.

Malware che si rigenera: il problema della persistenza

Una compromissione moderna può utilizzare più meccanismi contemporaneamente.

Eliminare il singolo file rilevato dall’antivirus può quindi non essere sufficiente.

Un malware può lasciare copie o componenti all’interno di:

• MU-plugin;
• plugin;
• temi;
• database WordPress;
• wp-config.php;
• directory uploads;
• directory temporanee;
• cron;
• cache;
• file nascosti.

Se uno di questi componenti rimane attivo, può ricreare automaticamente i file rimossi.

Per questo una vera bonifica WordPress deve individuare e rimuovere anche i meccanismi di persistenza.

Il ruolo di Imunify360

Sull’infrastruttura Xlogic viene utilizzato Imunify360 come ulteriore livello di sicurezza.

Il sistema può identificare diverse categorie di file malevoli, tra cui:

• backdoor;
• webshell;
• dropper;
• plugin WordPress falsi;
• codice PHP offuscato;
• iniezioni di codice.

Anche in questo caso è però necessario interpretare correttamente i risultati.

Un file malware all’interno di un singolo account indica innanzitutto che quel sito deve essere bonificato; non rappresenta automaticamente la prova di una compromissione root del server.

Il ruolo dei backup

I backup diventano particolarmente importanti durante un incidente di sicurezza.

Un backup precedente alla compromissione permette di:

• confrontare versioni differenti dei file;
• individuare modifiche anomale;
• ricostruire una timeline;
• ripristinare file originali;
• recuperare un sito da uno stato precedente all’infezione.

Sull’infrastruttura Xlogic viene utilizzato JetBackup per la gestione dei backup degli account hosting.

La sicurezza dell’hosting funziona a strati

Nessuna singola tecnologia può garantire da sola la sicurezza assoluta di un server.

Un’infrastruttura hosting utilizza normalmente più livelli:

rete
↓
web server
↓
WAF
↓
CloudLinux
↓
CageFS
↓
Imunify360
↓
PHP
↓
account hosting
↓
WordPress

L’obiettivo è fare in modo che, se un livello presenta un problema, gli altri possano comunque limitare, rilevare o rendere più difficile l’attacco.

LiteSpeed è ancora una tecnologia valida?

La scoperta di una vulnerabilità non significa automaticamente che un software debba essere considerato insicuro.

Problemi di sicurezza vengono scoperti periodicamente in:

• sistemi operativi;
• kernel;
• web server;
• PHP;
• database;
• CMS;
• browser;
• librerie.

Gli elementi importanti sono soprattutto la rapidità con cui la vulnerabilità viene identificata, corretta e distribuita agli amministratori.

LiteSpeed ha rilasciato la Build 2 della versione 6.3.7 il 16 settembre 2026 introducendo un ulteriore hardening del componente lscgid.

Per conoscere meglio le differenze tra le principali tecnologie web server puoi leggere il nostro confronto LiteSpeed vs Nginx vs Apache.

LiteSpeed zero-day 2026: checklist per gli amministratori

Chi amministra un server LiteSpeed Enterprise può seguire questa checklist:

1. Controllare la versione LiteSpeed installata.
2. Controllare separatamente il numero di build.
3. Verificare di utilizzare almeno 6.3.7 Build 2.
4. Riavviare LiteSpeed dopo l’aggiornamento.
5. Verificare che il servizio sia attivo.
6. Controllare le risposte HTTP e HTTPS.
7. Analizzare eventuali rilevamenti malware.
8. Controllare cron e attività pianificate sospette.
9. Verificare account con UID 0 inattesi.
10. Controllare eventuali nuove chiavi SSH.
11. Analizzare i file anomali creati nella finestra interessata.
12. Confrontare eventuali file sospetti con backup precedenti.
13. Monitorare eventuali nuove rilevazioni dopo la patch.

Perché un hosting gestito deve occuparsi anche di questi aggiornamenti

Quando un cliente acquista un hosting WordPress normalmente gestisce:

• contenuti;
• plugin;
• temi;
• pagine;
• ecommerce.

Sotto il sito esiste però un’infrastruttura molto più complessa:

WordPress
↓
PHP
↓
LiteSpeed
↓
CloudLinux
↓
sistema operativo
↓
hardware

Gli aggiornamenti dei livelli inferiori sono normalmente responsabilità dell’hosting provider.

È uno dei motivi per cui la manutenzione dell’infrastruttura continua a essere importante anche in un’epoca nella quale CMS e website builder rendono sempre più semplice realizzare un sito.

Conclusioni

Il caso LiteSpeed zero-day 2026 dimostra quanto rapidamente possa evolvere un problema di sicurezza nel settore hosting.

Secondo Hostinger, il 16 settembre una vulnerabilità critica è stata utilizzata per ottenere privilegi root su un server shared e distribuire webshell su numerosi account ospitati sulla macchina.

La risposta corretta non è però presumere che qualsiasi server o qualsiasi sito WordPress infetto sia stato compromesso attraverso questa vulnerabilità.

La procedura corretta è:

aggiornare
+
verificare
+
analizzare
+
monitorare

Per LiteSpeed Enterprise è raccomandato l’utilizzo della versione 6.3.7 Build 2 o successiva.

Xlogic ha verificato la propria infrastruttura LiteSpeed Enterprise e i server controllati risultano aggiornati alla Build 2, con regolare funzionamento dei servizi HTTP e HTTPS.

La sicurezza di un servizio hosting non dipende da una singola tecnologia, ma dalla capacità di aggiornare rapidamente l’infrastruttura, monitorarla continuamente e distinguere un normale sito compromesso da un eventuale problema a livello server.

Domande frequenti sul LiteSpeed zero-day 2026

Cos’è il LiteSpeed zero-day 2026?

È una vulnerabilità critica di LiteSpeed Web Server Enterprise resa pubblica nel settembre 2026 dopo un incidente segnalato da Hostinger. Nel particolare scenario documentato avrebbe consentito a un utente con privilegi limitati di ottenere privilegi root sul server.

Quale versione di LiteSpeed bisogna utilizzare?

La raccomandazione aggiornata è LiteSpeed Enterprise 6.3.7 Build 2 o una versione successiva che includa la correzione.

LiteSpeed 6.3.7 è sufficiente?

Non basta controllare esclusivamente il numero di versione. È necessario verificare anche la build installata. cPanel ha raccomandato esplicitamente di aggiornare nuovamente anche i server già sulla versione 6.3.7 per ottenere Build 2 o successiva.

Come controllo la build LiteSpeed?

È possibile utilizzare il comando cat /usr/local/lsws/BUILD. Per la versione 6.3.7 aggiornata dopo l’advisory il valore deve essere almeno 2.

Se il server aveva Build 0 significa che è stato compromesso?

No. La presenza di una versione precedente indica che era necessario aggiornare, ma non dimostra che la vulnerabilità sia stata sfruttata. Servono log, analisi dei file e altri indicatori di compromissione.

Un WordPress infetto indica che il server LiteSpeed è stato compromesso?

No. WordPress può essere compromesso attraverso plugin, temi, credenziali rubate, vecchie backdoor e numerosi altri vettori. Occorre ricostruire la timeline prima di attribuire l’infezione a una vulnerabilità del web server.

Cos’è lscgid?

È un componente utilizzato da LiteSpeed per la gestione dell’esecuzione di applicazioni CGI e di alcune comunicazioni interne. Le Build 0 e 2 di LiteSpeed 6.3.7 includono interventi di sicurezza relativi all’autenticazione, alla validazione e all’hardening di lscgid.

CageFS protegge da questo tipo di problema?

CageFS rappresenta un importante livello di isolamento tra gli account hosting. L’advisory cPanel indica però che la vulnerabilità in questione poteva consentire, in determinate condizioni, di oltrepassare i normali confini di isolamento.

Xlogic utilizza LiteSpeed Enterprise?

Sì. Xlogic utilizza LiteSpeed Enterprise sulla propria infrastruttura hosting insieme a tecnologie come CloudLinux, Imunify360, JetBackup e storage SSD NVMe.

I server Xlogic sono stati verificati?

Sì. Dopo l’advisory di settembre 2026 Xlogic ha verificato la propria infrastruttura LiteSpeed Enterprise e i server controllati risultano aggiornati alla versione 6.3.7 Build 2.