ARTICOLO

Falla critica in Apache: chi aggiorna il server del vostro sito?

Apachesecurityhosting

In breve

  • L'11 novembre Apache ha pubblicato la versione 2.4.71, che chiude una falla critica nel modulo HTTP/2: chi la sfrutta può far girare il proprio codice sul server.
  • Sono esposti i server con Apache dalla 2.4.55 alla 2.4.70 e HTTP/2 attivo, un'opzione spenta di base che però molti hosting accendono.
  • Chi ha accesso al server legge la versione con httpd -v o apache2 -v, ma su Linux fa fede l'avviso di sicurezza della distribuzione, anche se il numero sembra fuori fascia; chi è su hosting condiviso chiede al fornitore.
  • A chi gestisce il sito servono tre risposte: chi aggiorna il server, in quanto tempo dopo un avviso critico e come vi avvisa che è fatto.

L'11 novembre Apache ha pubblicato la versione 2.4.71 del suo server web, uno dei più usati al mondo. Corregge una falla critica, la CVE-2026-119618, che permette a un attaccante di far girare il proprio codice sul server senza bisogno di password. Riguarda le versioni dalla 2.4.55 alla 2.4.70 con HTTP/2 attivo.

Cosa è successo

L'errore sta nel modulo mod_http2, in una funzione che gestisce le intestazioni delle richieste. Due parti del server la usano nello stesso momento senza coordinarsi, e con richieste costruite apposta si può corrompere la memoria del processo fino a fargli eseguire comandi. Apache la classifica come critica, il livello più alto della sua scala.

Le segnalazioni sono due. La prima è arrivata il 26 ottobre dallo scanner automatico di Anthropic, l'azienda che sviluppa Claude: uno strumento basato sull'IA che legge il codice dei progetti open source in cerca di errori. La seconda, il 3 novembre, da due ricercatori di Google Cloud. I dati vengono dalla pagina ufficiale delle vulnerabilità di Apache 2.4; un riassunto in italiano lo trovate su Hardware Upgrade.

Perché riguarda anche un'azienda piccola

Secondo Hardware Upgrade, Apache fa girare circa un sito su cinque nel mondo. Tanti sono siti di attività piccole: una vetrina su hosting condiviso, un WordPress fatto qualche anno fa, un gestionale raggiungibile da fuori per chi lavora in trasferta.

La falla si apre solo con HTTP/2 attivo, un'opzione che rende le pagine più veloci. Apache la tiene spenta di base, però molti hosting e molti tecnici la accendono proprio per la velocità. A occhio non si capisce se il vostro sito è esposto: va controllato o chiesto.

Chi attacca non sceglie i bersagli per nome. Usa programmi che girano su internet in cerca di server con la versione giusta, e per quei programmi un sito piccolo è un bersaglio come un altro. Un server preso può mandare spam, ospitare pagine truffa o dare accesso ai dati lasciati nei moduli di contatto.

Il fatto che una delle segnalazioni venga da uno strumento di IA conta anche per voi. Strumenti così trovano errori in codice vecchio di anni in poco tempo. Li usano i ricercatori e li possono usare gli attaccanti, quindi il tempo fra l'annuncio di una falla e i primi attacchi si accorcia. Aggiornare «quando capita» diventa un rischio.

Come si controlla

Se voi o il vostro tecnico avete accesso al server, la versione si legge da terminale:

httpd -v
apache2 -v

Il primo comando vale su Red Hat, AlmaLinux e simili, il secondo su Debian e Ubuntu. La riga che conta è Server version: Apache/2.4.xx. Per sapere se HTTP/2 è attivo si cerca la direttiva Protocols con h2 nei file di configurazione di Apache.

Su un server Linux, però, il numero da solo non basta. Debian ha portato i suoi pacchetti alla 2.4.71, mentre Ubuntu e Red Hat correggono i loro senza passare a quella versione, quindi potreste vedere un numero più basso con la falla già chiusa. Ubuntu ha corretto anche pacchetti con un numero sotto la 2.4.55, che a prima vista sembrerebbero fuori pericolo. Se il server usa una distribuzione Linux, fa fede l'avviso di sicurezza della distribuzione, anche quando il numero sembra fuori fascia. Chi gestisce il server sa dove trovarlo.

Con un hosting condiviso questi comandi non li potete lanciare, e non serve: l'aggiornamento spetta al fornitore. Scrivetegli e fatevi confermare che i server sono alla 2.4.71 o hanno la correzione. Se il sito gira su un altro server web, come nginx o LiteSpeed, questa falla non lo tocca; le domande qui sotto restano utili per la prossima.

Se aggiornare subito non si può, la misura provvisoria indicata dalle fonti è spegnere HTTP/2. Il sito torna a HTTP/1.1, un po' più lento ma fuori da questa falla. È una scelta da fare con chi gestisce il server.

Le tre domande da fare a chi gestisce il sito

Che sia l'hosting, l'agenzia che ha fatto il sito o il tecnico di fiducia, mandate una mail con queste tre domande.

  1. Chi aggiorna il server. Sistema operativo, Apache, PHP: vi serve un nome o un servizio preciso. Capita che l'hosting pensi che se ne occupi l'agenzia e l'agenzia pensi che se ne occupi l'hosting.
  2. In quanto tempo dopo un avviso critico. Per una falla come questa la risposta che vi serve è qualche giorno. Chiedete anche se gli aggiornamenti di sicurezza partono in automatico o li fa qualcuno a mano.
  3. Come vi avvisa quando ha finito. Basta una mail con la data e la versione installata. Se non arriva niente, non avete modo di sapere se il lavoro è stato fatto.

Se a una di queste domande nessuno sa rispondere, il problema da sistemare è quello, prima ancora di questa falla.

Se volete un secondo parere

Se non sapete chi gestisce il vostro server, o la risposta ricevuta non vi convince, posso guardarlo con voi: vediamo cosa dichiara il sito dall'esterno e preparo le domande da girare al fornitore. Per i siti in PHP c'è anche il controllo gratuito della versione PHP, e sul tema avevo scritto delle due falle critiche in PHP di ottobre.

← Tutti gli articoli