Due falle PHP con gravità 9,2 su 10 stanno per ricevere una correzione d’emergenza. Se il sito aziendale gira su WordPress, aspettare che l’hosting faccia tutto da solo significa scoprire troppo tardi chi aggiorna il runtime, quali siti dipendono da quella versione e come tornare indietro se un plugin smette di funzionare.
Prima della patch: inventario e responsabilità
Il PHP Security Team ha programmato per il 21 ottobre 2026 alle 14:00 UTC una release per due vulnerabilità critiche, entrambe classificate CVSS v4.0 9.2. L’avviso ufficiale non indica ancora versioni coinvolte, versioni corrette o dettagli tecnici: promette di pubblicarli con la release. Questo è il dato da cui partire, senza trattare indiscrezioni e video non verificati come istruzioni operative.
Apri quindi il pannello dell’hosting e annota, per ogni installazione, dominio, versione PHP, ambiente di staging, referente tecnico e modalità di aggiornamento. Con accesso alla shell puoi confermare il runtime con php -v; su hosting gestito usa il selettore PHP o chiedi al provider. Invia una domanda precisa: «Quale build corretta installerete e in quale finestra?». L’obiettivo non è aggiornare alla cieca, ma sapere chi esegue il cambio e quali siti vanno verificati subito dopo.
Prepara rollback e test essenziali
Prima che la release sia disponibile, crea un backup verificabile di file e database e controlla dove viene conservato. Una scritta «backup giornaliero» nel pannello non basta: annota l’ora dell’ultima copia, la retention e il percorso di ripristino. Se esiste uno staging, allinealo alla produzione e prepara una prova sulla stessa famiglia PHP che il provider renderà disponibile. Non cambiare contemporaneamente core WordPress, plugin, tema e versione PHP: se qualcosa si rompe, non saprai quale modifica ha causato il problema.
La checklist dopo l’aggiornamento deve restare corta e aderente al business: homepage, login, modulo contatti, ricerca, checkout o prenotazione, area riservata e job automatici. Controlla anche log PHP e codici HTTP per intercettare errori invisibili agli utenti. La stessa disciplina serve per ogni intervento urgente: questa guida sulle patch WordPress e la cache mostra perché una correzione non è completa finché non verifichi ciò che il server continua a servire.
Aggiorna quando escono le versioni corrette
Alle 14:00 UTC controlla la pagina ufficiale di PHP e la comunicazione del tuo hosting. Applica soltanto una build indicata come corretta per il ramo supportato che stai usando; non scegliere numeri di versione suggeriti da post social pubblicati prima dell’advisory completo. Se gestisci il server, segui il repository della distribuzione e riavvia i servizi necessari secondo la sua documentazione. Se usi un piano managed, verifica nel pannello che il runtime sia realmente cambiato: l’annuncio del provider e la versione in esecuzione non sono la stessa prova.
Dopo il deploy ripeti la checklist, osserva i log e registra esito, ora e responsabile. Se una funzione critica fallisce, usa il rollback predisposto e coinvolgi subito provider o sviluppatore; non lasciare online un sito parzialmente aggiornato senza sapere quale runtime sta servendo le richieste. Ars Technica riporta scenari più aggressivi, ma distingue correttamente le informazioni ufficiali dalle affermazioni ancora non confermate.
L’errore da evitare e il take finale
L’errore più pericoloso è confondere l’aggiornamento di WordPress con quello di PHP. WordPress è l’applicazione; PHP è il runtime installato sul server. Aggiornare il core dal backend non sostituisce automaticamente PHP, mentre cambiare una major PHP senza test può esporre incompatibilità in plugin o codice personalizzato. Evita anche «mitigazioni» copiate prima che il team PHP pubblichi i dettagli: potrebbero non coprire il vettore reale e creare una falsa sensazione di sicurezza.
Il take operativo è questo: oggi non serve indovinare la falla, serve ridurre il tempo tra release e aggiornamento verificato. Assegna un responsabile, fotografa le versioni, prepara backup e rollback, definisci cinque o sei test di business e attendi l’elenco ufficiale delle build corrette. Poi aggiorna, misura e documenta. Per una PMI è un processo molto più affidabile dell’allarme generico, perché trasforma una notizia urgente in una manutenzione controllata e ripetibile.