“Ho appena aggiornato WordPress e tutti i plugin, sono a posto.” Per questa falla no. WordPress è la casa, PHP è il terreno su cui è costruita: puoi rifare il tetto quanto vuoi, ma il problema questa volta sta sotto.
Cosa è successo?
Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti di sicurezza per due falle critiche, e lo stesso giorno l’Ufficio federale della cibersicurezza (UFCS) ha chiesto di installarli subito. Secondo l’UFCS, le due falle potrebbero consentire agli hacker di eseguire codice dannoso sui server interessati senza doversi autenticare.
L’UFCS raccomanda di aggiornare senza indugio i sistemi interessati, di farsi confermare la correzione dai provider di hosting e dai produttori, e di controllare anche le applicazioni e i dispositivi che usano PHP come componente integrato, non solo i siti pubblici.
Le due falle si chiamano CVE-2026-109618 e CVE-2026-109619 (il codice con cui si cataloga una falla di sicurezza). Entrambe hanno un punteggio di gravità di 9,2 su 10 e nascono da errori nella gestione della memoria del motore PHP.
Il CERT-AgID riporta per entrambe un punteggio CVSS v4.0 di 9.2 e precisa che l’aggiornamento del solo CMS (come WordPress) o dei suoi plugin non corregge le vulnerabilità dell’interprete PHP.
In parole semplici: in alcune configurazioni basta una richiesta preparata ad arte, inviata al sito come una visita qualsiasi, per far eseguire al server comandi scelti dall’attaccante. Nel caso più grave, secondo gli sviluppatori, questo succede prima ancora che parta il codice del sito: in quel caso un plugin di sicurezza di WordPress non fa in tempo a intervenire.
Gli sviluppatori indicano a rischio tutte le installazioni PHP che rispondono a richieste web. Il rischio più alto è per la configurazione Apache con mod_php, dove hanno dimostrato un attacco con una sola richiesta senza login, eseguito prima del codice dell’applicazione.
La falla è già sfruttata?
Al 21 ottobre 2026 nessuna delle fonti ufficiali conferma attacchi in corso. Circolano però online le prime prove di sfruttamento (in gergo “PoC”, proof of concept): il CERT-AgID scrive che la loro efficacia non è ancora stata pienamente verificata, ma che la loro disponibilità aumenta il rischio di tentativi di attacco.
Il centro di sicurezza delle istituzioni europee osserva che i dettagli tecnici sono ormai discussi pubblicamente e che le prime prove di sfruttamento hanno cominciato a circolare: questo rende più probabile che gli attaccanti stiano già sfruttando le falle. Raccomanda di aggiornare immediatamente.
Tradotto per chi ha un sito: oggi non risultano siti colpiti, ma le istruzioni cominciano a circolare. Chi cerca siti non aggiornati usa programmi automatici, che provano un indirizzo dopo l’altro senza guardare se il sito è grande o piccolo.
Il mio sito WordPress o il mio negozio online è coinvolto?
Se il tuo sito usa PHP, probabilmente sì, finché l’hosting non ha installato la versione corretta. WordPress gira su PHP, e così molti negozi online e gestionali web. L’UFCS ricorda che PHP può trovarsi anche dentro pannelli di amministrazione, applicazioni interne e dispositivi, senza che chi li usa lo sappia.
Le versioni che chiudono le falle sono:
| Se il tuo sito usa | Deve essere almeno |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 o precedente | non riceve più aggiornamenti dal progetto PHP: chiedi all’hosting se ha una correzione propria, altrimenti va portato a una versione supportata |
Un dettaglio che confonde: molti hosting applicano la correzione senza cambiare il numero di versione che vedi (lo fanno le distribuzioni Linux con le patch “in backport”). L’UFCS lo dice chiaramente: un numero di versione rimasto uguale non significa per forza che la correzione manchi. Per questo la risposta giusta la dà l’hosting, per iscritto, non solo il numero.
PHP, versioni supportate (in inglese)Come scopro che versione di PHP usa il mio sito?
Hai due strade, entrambe senza toccare codice.
- Dal pannello dell’hosting: nella sezione del dominio o del sito di solito c’è una voce “Versione PHP” o “Impostazioni PHP”, spesso con un menu per sceglierla.
- Da WordPress: Bacheca → Strumenti → Salute del sito → Informazioni → sezione Server. Lì trovi la versione di PHP che il sito sta usando davvero.
Il secondo controllo conta: il CERT-AgID avverte che la versione di PHP usata dal sito può essere diversa da quella che risulta altrove sullo stesso server. Quella che conta è quella che risponde ai visitatori.
Cosa chiedo al mio hosting?
Una domanda precisa riceve una risposta precisa. Puoi copiare questa email:
Buongiorno, il mio sito
tuodominio.chgira su PHP. In merito alle falle CVE-2026-109618 e CVE-2026-109619 pubblicate il 21 ottobre 2026, vi chiedo di confermarmi per iscritto:
- quale versione di PHP usa il mio sito;
- se la correzione è già installata (versione 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure una vostra patch equivalente) e da quando;
- se i processi PHP sono stati riavviati dopo l’aggiornamento;
- se la mia versione non è più supportata, quale mi consigliate e cosa devo verificare prima del cambio. Grazie.
Il punto 3 non è un dettaglio: sia l’UFCS sia il CERT-AgID ricordano che dopo l’aggiornamento i servizi PHP vanno riavviati, altrimenti continua a girare la versione vecchia.
Se il server lo gestisci tu (o il tuo tecnico, su un server dedicato o virtuale): aggiorna PHP alla versione corretta del tuo ramo o al pacchetto corretto della tua distribuzione, riavvia i servizi, verifica che il sito usi davvero la versione nuova e controlla i log per richieste anomale e crash. Le misure temporanee indicate dagli sviluppatori riducono solo alcune vie d’attacco: l’UFCS precisa che non sostituiscono l’aggiornamento e che anche un firewall applicativo (WAF) da solo non basta.
Un esempio dal Ticino
Immagina un’impresa di serramenti del Mendrisiotto: sito WordPress con modulo per i preventivi, su un hosting condiviso, fatto anni fa da un’agenzia che non lo segue più. Il titolare aggiorna i plugin quando WordPress lo segnala, e pensa di essere a posto.
Su un hosting condiviso PHP lo aggiorna il fornitore, ma spesso la versione la sceglie il cliente dal pannello. Se il sito era stato lasciato su PHP 7.4 “perché il tema vecchio non funzionava con le nuove”, oggi è fuori dagli aggiornamenti del progetto PHP. Il fornitore può aver aggiornato tutto il resto, ma quel sito resta sulla versione scelta anni fa.
Cinque minuti per guardare il pannello e un’email all’hosting bastano per sapere da che parte stai.
E in Italia?
Il CERT-AgID ha pubblicato lo stesso giorno la stessa raccomandazione: aggiornare tempestivamente, partendo dai servizi esposti su Internet. Per le PMI italiane il quadro è identico: il sito su hosting condiviso dipende dalla versione di PHP scelta nel pannello e dagli aggiornamenti del fornitore, e l’aggiornamento di WordPress da solo non chiude queste falle.
Il Metodo 3V applicato all’aggiornamento di PHP
Le tre domande del Metodo 3V valgono anche per la manutenzione del sito. Il metodo viene dal libro «Sicurezza informatica per professionisti», spiegato nella guida al social engineering.
| Domanda | Applicata al tuo sito |
|---|---|
| Verifica: sai cosa usi e chi lo aggiorna? | Sai su che versione di PHP gira il sito, e se la aggiorna l’hosting, l’agenzia o nessuno? |
| Validazione: hai una conferma, non una supposizione? | L’hosting ti ha confermato per iscritto la correzione e il riavvio dei servizi? “Aggiorniamo sempre tutto” non è una conferma. |
| Velocità controllata: quando conviene aspettare? | Qui la fretta è giusta: la correzione esiste, le prove di sfruttamento circolano. Si aggiorna adesso, non alla prossima manutenzione. |
Cosa fare se temi che il sito sia già stato colpito
- Segni da non ignorare: pagine che non hai creato, reindirizzamenti verso altri siti, nuovi utenti amministratori, avvisi del browser o dell’hosting, sito molto lento o che si blocca.
- Aggiorna comunque PHP: l’UFCS ricorda che un aggiornamento non risolve una compromissione già avvenuta, ma chiude la porta da cui potrebbero rientrare.
- Chiedi all’hosting un controllo dei file modificati e dei log, e ripristina da un backup pulito se serve.
- Cambia le password di WordPress, dell’hosting e del database dopo l’aggiornamento, non prima.
- Segnala: in Svizzera all’UFCS; in Italia alla Polizia Postale. Se ci sono dati di clienti coinvolti, valuta gli obblighi di notifica previsti dalla protezione dei dati.
Domande frequenti
Ho aggiornato WordPress e tutti i plugin: sono protetto da questa falla?
No. Le due falle sono in PHP, il motore su cui gira WordPress, non in WordPress. Il CERT-AgID lo scrive esplicitamente: aggiornare il CMS o i plugin non corregge l'interprete PHP. Serve che l'hosting abbia installato la versione corretta (8.5.12, 8.4.27, 8.3.36 o 8.2.35) o una patch equivalente.
Come faccio a vedere che versione di PHP usa il mio sito?
Dal pannello dell'hosting, nella sezione del dominio, alla voce Versione PHP. Oppure in WordPress: Strumenti, Salute del sito, Informazioni, sezione Server. Ricorda che il numero da solo non basta: alcuni hosting correggono senza cambiarlo, quindi chiedi conferma scritta.
Il mio sito è su un hosting condiviso: tocca a me o al fornitore?
Di solito il fornitore installa gli aggiornamenti di PHP, ma tu scegli quale versione usa il sito. Se il sito è su una versione vecchia non più supportata, nessun aggiornamento del fornitore lo protegge. Controlla la versione e chiedi al fornitore se la correzione è installata e i servizi riavviati.
La falla è già usata dagli hacker?
Al 21 ottobre 2026 le fonti ufficiali non confermano attacchi in corso. Circolano però prove di sfruttamento pubbliche, di efficacia non ancora verificata, e il CERT-EU ritiene più probabile che le falle vengano sfruttate. Per questo l'UFCS chiede di aggiornare subito.
Per capire perché un sito piccolo viene provato quanto uno grande, leggi 793 tentativi di accesso in 24 ore su un solo server. La correzione è disponibile da oggi: ogni giorno in cui il sito resta sulla versione vecchia è un giorno in cui chi scansiona Internet lo trova aperto.
