In breve
- Il 21 ottobre 2026 il team di PHP ha corretto due vulnerabilità critiche (CVE-2026-109618 e CVE-2026-109619, gravità 9,2 su 10) che permettono di eseguire codice sul server da remoto, senza bisogno di credenziali.
- PHP è il linguaggio su cui girano WordPress, WooCommerce e la maggior parte dei siti aziendali: il problema riguarda praticamente tutti.
- Il provider con cui lavoriamo ha attivato le protezioni dal pomeriggio del 21 ottobre e ha aggiornato tutte le versioni di PHP. Poi abbiamo controllato i siti dei clienti che seguiamo.
- Se il tuo hosting non ti ha comunicato nulla, o non sai chi aggiorna il tuo sito, qui trovi i segnali da controllare e cosa fare subito.
Martedì 20 ottobre il team di sicurezza di PHP ha annunciato un rilascio d’emergenza per il giorno dopo. Non succede spesso: di solito le correzioni escono in silenzio, con calma. Questa volta alcune informazioni sulle falle erano già circolate in anticipo e il rischio era che qualcuno iniziasse ad attaccare prima che i server fossero aggiornati.
Per chi ha un sito aziendale la domanda è una sola: il mio sito è al sicuro? In questo articolo spieghiamo cosa è successo con parole semplici, cosa poteva fare chi attaccava, come abbiamo gestito la situazione sui siti dei nostri clienti e cosa fare se hai un dubbio sul tuo.
Cosa è successo, in breve
- 20 ottobre: il team di PHP annuncia due vulnerabilità critiche, entrambe con punteggio 9,2 su 10, e fissa il rilascio delle correzioni.
- 21 ottobre, ore 16 italiane: escono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, le versioni corrette.
- PHP 8.1 e precedenti non ricevono un aggiornamento ufficiale perché fuori supporto. Restano protetti solo se il provider applica la correzione per conto suo.
- Nelle stesse ore sono comparsi strumenti di attacco pubblici e i primi tentativi reali sui server.
Le falle sono nel cuore di PHP, non in un plugin o in un tema. Per questo riguardano qualsiasi sito costruito in PHP, indipendentemente da quanto sia curato il resto.
Perché è così grave: cosa poteva fare chi attaccava
Il termine tecnico è esecuzione di codice da remoto senza autenticazione. Tradotto: una persona estranea, senza password, poteva far eseguire comandi al server come se fosse chi lo gestisce. Con quel livello di accesso un attaccante può:
- installare una porta di servizio nascosta (backdoor) per rientrare anche dopo che la falla è stata chiusa;
- leggere il database: richieste arrivate dai moduli contatto, dati dei clienti, ordini, indirizzi email;
- modificare le pagine inserendo link nascosti, contenuti spam o reindirizzamenti verso siti truffa;
- usare il server per inviare spam o ospitare pagine di phishing, con il risultato che il dominio finisce nelle liste nere e le email aziendali smettono di arrivare;
- far comparire su Google l’avviso di sito compromesso, che allontana chiunque stia cercando la tua attività.
C’è poi un aspetto che molte imprese sottovalutano: se un attacco espone dati personali, il GDPR prevede che la violazione venga valutata e, quando c’è un rischio per le persone, notificata al Garante entro 72 ore.
“La mia versione di PHP sembra vecchia: sono vulnerabile?”
È la domanda che sta generando più confusione. Molti provider non hanno installato le nuove versioni di PHP, ma hanno applicato la correzione alle versioni che avevano già (si chiama backport). Il numero di versione resta quello di prima, ma la falla è chiusa.
Esempio concreto: un server che mostra PHP 8.4.26 può essere già protetto, anche se la versione corretta “ufficiale” è la 8.4.27. Per questo non basta guardare il numero: serve una conferma esplicita del provider che la correzione per le due CVE sia stata applicata.
Come abbiamo gestito la situazione
Il server su cui ospitiamo i siti che seguiamo appartiene a un provider strutturato, con procedure e certificazioni di sicurezza. Lo abbiamo scelto proprio per momenti come questo, non per il prezzo più basso. Il provider ci ha avvisato subito e ha agito in due tempi:
- dal pomeriggio del 21 ottobre ha attivato regole di protezione sul firewall applicativo (WAF), che bloccano i tentativi di attacco noti mentre le correzioni vengono installate;
- subito dopo ha aggiornato tutte le versioni di PHP disponibili sui server con le patch di sicurezza.
A quel punto abbiamo fatto la nostra parte: abbiamo controllato tutti i siti che gestiamo per i nostri clienti, per essere certi che fossero sulle versioni corrette e che non ci fossero segnali di accessi anomali.
Va detto con onestà: la sicurezza al 100% non esiste. Esiste il tempo che passa tra la scoperta di una falla e la sua chiusura, ed esiste qualcuno che controlla. È lì che si gioca la differenza tra un sito esposto per ore e uno esposto per settimane.
Perché la manutenzione non è un costo accessorio
Un sito non si mette online e si dimentica. È un software che vive su un server, e il software ha bisogno di aggiornamenti. Una manutenzione fatta bene lavora su più livelli:
- Server e PHP aggiornati da un provider che comunica e interviene in fretta.
- WordPress, tema e plugin aggiornati con regolarità, e plugin ridotti a quelli davvero necessari.
- Backup automatici conservati fuori dal server, per poter tornare a una versione pulita.
- Firewall e protezioni attive, che fermano gli attacchi più comuni prima che arrivino al sito.
- Accessi protetti: password robuste, verifica in due passaggi, pochi utenti amministratori.
- Monitoraggio: avvisi di Google Search Console, controllo dei file modificati, sito raggiungibile.
I siti più esposti in questi giorni sono quelli lasciati su versioni vecchie di PHP, senza nessuno che li segua. Quando parliamo di costi, la manutenzione è una delle voci che spieghiamo sempre nella guida su quanto costa un sito web professionale, ed è tra le domande da fare a qualsiasi fornitore prima di firmare (ne parliamo in come scegliere un partner digitale).
Come capire se il tuo sito è stato colpito
Alcuni segnali da controllare, anche senza competenze tecniche:
- utenti amministratori che non riconosci nel pannello di WordPress;
- il sito che, aperto da Google o dal telefono, porta su pagine diverse dalle tue;
- contenuti, link o pagine che non hai mai pubblicato;
- un avviso di problemi di sicurezza in Google Search Console;
- email del tuo dominio che finiscono in spam o tornano indietro;
- il sito diventato improvvisamente lento o irraggiungibile;
- comunicazioni del provider su attività sospette o sospensione dell’account.
Cosa fare subito se hai un dubbio
- Scrivi al tuo hosting e chiedi una conferma esplicita: “la correzione per CVE-2026-109618 e CVE-2026-109619 è stata applicata al mio server?”.
- Cambia le password di hosting, FTP, database e amministratore del sito, e attiva la verifica in due passaggi.
- Controlla gli utenti con ruolo di amministratore ed elimina quelli che non riconosci.
- Verifica di avere un backup precedente al 20 ottobre, conservato fuori dal server.
- Se trovi segni di attacco, non limitarti a cancellare qualche file: serve una pulizia completa, la rimozione delle backdoor, gli aggiornamenti e, se Google ha segnalato il sito, la richiesta di revisione.
- Se sono coinvolti dati personali, valuta con il tuo consulente privacy la notifica al Garante entro 72 ore.
Ti serve una mano?
Se il tuo sito è stato attaccato, se il tuo hosting non ti ha dato risposte o semplicemente non sai chi si occupa degli aggiornamenti, possiamo partire da una verifica: controlliamo versione di PHP, stato degli aggiornamenti, utenti, file e segnalazioni di Google, e ti diciamo con chiarezza cosa sistemare e in che ordine.
Lavoriamo con imprese di Milano, Monza Brianza e Brescia e da remoto in tutta Italia. Scrivici dalla pagina contatti oppure su WhatsApp: rispondiamo entro 24 ore lavorative.
Fonti: annuncio del PHP Security Team e aggiornamenti di CloudLinux sulle versioni corrette.
