Chi gestisce un sito WordPress deve verificare la versione PHP usata dal server e prepararsi ad applicare le patch annunciate dal team di sicurezza. Aggiornare WordPress o un plugin non aggiorna automaticamente il motore PHP dell’hosting: per quello può servire un intervento dal pannello del provider o dell’amministratore di sistema.
Il 20 ottobre 2026 il team PHP ha annunciato un rilascio straordinario per due vulnerabilità critiche, entrambe con punteggio CVSS v4.0 pari a 9,2. La pubblicazione è prevista per il 21 ottobre alle 14:00 UTC, cioè alle 16:00 in Italia. Nell’annuncio ufficiale PHP, gli sviluppatori precisano che versioni coinvolte, versioni corrette e dettagli completi saranno comunicati insieme al rilascio. Al momento di questa verifica, la mattina del 21 ottobre, non risultano ancora specificati nell’annuncio.
Cosa sappiamo delle vulnerabilità PHP e cosa resta da confermare
La conferma ufficiale riguarda la gravità dei due problemi e la necessità di preparare l’aggiornamento. Il team si riserva di anticipare il rilascio se emergessero dettagli pubblici o prove di sfruttamento attivo. Questo non equivale ad affermare che ogni sito WordPress sia già stato violato.
Anche CERT-EU invita le organizzazioni a identificare le applicazioni basate su PHP e a prepararsi ad applicare le correzioni appena disponibili. Per chi amministra un sito, la domanda utile adesso è: quale componente devo aggiornare, chi può farlo e come verifico il risultato? Non serve attribuire al proprio server una vulnerabilità specifica prima di conoscere le condizioni tecniche ufficiali.
Come vedere la versione PHP realmente usata da WordPress
Accedi alla bacheca con un account amministratore e apri Strumenti > Salute del sito > Informazioni. Espandi la sezione Server e annota il valore della versione PHP. La schermata è informativa: consente di leggere la configurazione, non di cambiarla. La documentazione ufficiale di Salute del sito descrive le informazioni disponibili sull’installazione e sull’ambiente server.
Conserva il numero completo, non soltanto “PHP 8”. Confrontalo con il pannello dell’hosting per quel dominio. Se le indicazioni non coincidono, chiedi al provider quale ambiente sta effettivamente servendo il sito: selezionare una versione in un pannello non è una verifica sufficiente dell’esecuzione finale.
Chi dispone di una shell può leggere la versione dell’eseguibile richiamato con php -v. Attenzione però: il comando identifica quel binario PHP. Non assumere che corrisponda automaticamente all’ambiente web assegnato al dominio. Per il sito WordPress, confronta anche la lettura nella bacheca e la conferma dell’hosting.
Aggiornare WordPress, plugin e PHP: tre interventi diversi
| Componente | Dove si gestisce normalmente | Cosa verificare |
|---|---|---|
| WordPress | Bacheca o strumenti di gestione del sito | Versione del CMS |
| Plugin e temi | Bacheca o gestione dei pacchetti | Versione del singolo componente |
| PHP | Pannello hosting o amministrazione server | Release effettiva e correzioni del provider |
La distinzione evita un falso senso di sicurezza: vedere “tutti gli aggiornamenti completati” nella bacheca non dimostra che il server abbia ricevuto la patch PHP. Allo stesso modo, correggere PHP non elimina una vulnerabilità indipendente di un plugin. Nel caso di Hummingbird vulnerabile, per esempio, il componente da verificare era il plugin e il rischio dipendeva dalle condizioni descritte per quel prodotto.
Cosa chiedere all’hosting prima delle patch
Invia una richiesta riferita al dominio interessato, con la versione letta da WordPress. Chiedi se l’ambiente rientra fra quelli coinvolti quando saranno disponibili i dettagli ufficiali, chi applicherà la correzione e come riceverai conferma dell’intervento. Se gestisci più siti, prepara un elenco: non considerare verificati tutti gli ambienti perché ne hai controllato uno.
Puoi usare questa formulazione: “Per il dominio indicato, WordPress segnala la versione PHP riportata qui sotto. In relazione al rilascio straordinario annunciato per il 21 ottobre, potete verificare l’eventuale coinvolgimento, indicare il piano di aggiornamento e confermare dopo l’intervento la release o il pacchetto corretto effettivamente in uso?”. Inserisci soltanto dati del tuo ambiente, senza password o chiavi di accesso.
Backup e compatibilità: preparare l’aggiornamento senza improvvisare
Prima di modificare l’ambiente, verifica di avere un backup recente di file e database e di sapere come ripristinarlo. Aggiorna i componenti del sito tramite i rispettivi canali affidabili e controlla eventuali incompatibilità note con il ramo PHP proposto dall’hosting. Se hai uno staging, usalo per provare il cambiamento: è una verifica di compatibilità, non una ragione per rimandare indefinitamente una correzione critica.
Non confondere una patch del ramo in uso con il passaggio a una diversa versione principale. Chiedi al provider quale intervento è necessario e supportato per il tuo ambiente. Evita comandi copiati da guide generiche: pacchetti, servizi e procedure dipendono dal sistema operativo e dalla configurazione del server.
Dopo l’aggiornamento: i controlli che rendono utile la conferma
Rileggi la versione dall’ambiente web e conserva la conferma del provider. Poi prova le funzioni che contano per il tuo sito: accesso alla bacheca, apertura degli articoli, ricerca, invio dei moduli e, se presenti, carrello e acquisto di prova secondo le procedure del negozio. Controlla i log con chi gestisce il server se compaiono nuovi errori.
Un sito che si apre non dimostra da solo che la correzione sia stata applicata; una versione confermata non dimostra che tutte le funzioni siano compatibili. Sono due verifiche differenti. E se emergono indizi di una compromissione precedente, serve un’indagine separata: come spiegato nel caso di Admin Menu Editor Pro compromesso, aggiornare un componente non certifica automaticamente la pulizia del sito.
Cosa fare se il provider non può correggere subito
CERT-EU raccomanda di valutare l’isolamento delle applicazioni esposte a Internet quando non è possibile intervenire immediatamente. È una decisione da prendere con hosting o responsabile IT sulla base del rischio reale e dei dettagli disponibili: una normale pagina di manutenzione WordPress non va considerata, da sola, una barriera equivalente all’isolamento dell’applicazione.
Per chi gestisce WordPress, la priorità è avere una risposta verificabile su ambiente coinvolto, correzione applicata e funzionamento successivo. Fino al bollettino completo, non indicare come risolutiva una release scelta per supposizione e non installare pacchetti provenienti da canali sconosciuti.
Entra nella conversazione
Condividi il tuo punto di vista: non serve creare un account. I contributi restano soggetti alla moderazione editoriale.