Alle 16:00 del 21 ottobre 2026, ora dell’Europa centrale, il PHP Security Team prevede di pubblicare correzioni per due vulnerabilità critiche. Entrambe hanno un punteggio CVSS v4.0 di 9,2. Per chi gestisce WordPress, la conseguenza concreta è semplice: l’aggiornamento non arriverà dal pannello dei plugin e non basta premere “Aggiorna WordPress”. La correzione riguarda il runtime PHP installato sul server.

Questo cambia anche il responsabile dell’intervento. Su un hosting gestito deve muoversi il provider; su un VPS o un server dedicato deve intervenire chi amministra lo stack. L’errore più costoso, oggi, è scoprire questa distinzione dopo il rilascio della patch.

La finestra operativa è oggi

L’avviso ufficiale di PHP, pubblicato il 20 ottobre, fissa il rilascio per mercoledì 21 ottobre 2026 alle 14:00 UTC. In Svizzera e in Italia corrisponde alle 16:00 CEST. Il team si riserva di anticiparlo se diventassero pubblici dettagli tecnici o comparissero prove di sfruttamento attivo.

Il comunicato ufficiale conferma tre elementi e soltanto questi:

  • le vulnerabilità sono due;
  • entrambe sono valutate 9,2 sulla scala CVSS v4.0;
  • versioni coinvolte, versioni corrette e dettagli tecnici saranno comunicati insieme al rilascio.

Non esiste ancora una versione corretta da installare. La preparazione serve quindi a ridurre il tempo tra la pubblicazione del fix e la sua applicazione, senza trasformare l’urgenza in un aggiornamento alla cieca.

Per una PMI la metrica utile non è “abbiamo letto l’avviso”, ma “quanto tempo ci serve per sapere quali siti dipendono da PHP, chi li aggiorna e come dimostriamo che il nuovo runtime è davvero attivo”. Se queste tre risposte non sono disponibili, il rischio è organizzativo prima ancora che tecnico.

Separa i fatti dalle ipotesi

Nelle ore precedenti al rilascio sono circolati due identificativi, CVE-2026-109618 e CVE-2026-109619, insieme al nome informale “PHP2Shell” e alla tesi secondo cui sarebbero coinvolte tutte le versioni da PHP 5 in avanti. watchTowr descrive questi elementi come provenienti da un rapporto non verificato e precisa che, al momento del suo aggiornamento del 21 ottobre, non risultavano sfruttamenti osservati in natura.

La distinzione conta. Il punteggio 9,2 e l’orario sono confermati da php.net; il perimetro tecnico non lo è ancora. Non va quindi scritto in un ticket interno che “tutti i server da PHP 5.4 sono vulnerabili” come se fosse un fatto del vendor. Va scritto invece che tutti i sistemi PHP esposti devono essere inventariati e preparati, in attesa della matrice ufficiale delle versioni.

Wordfence chiarisce un secondo punto importante per WordPress: aggiornare core, temi o plugin non modifica il runtime PHP. Un firewall applicativo può eventualmente ridurre una parte dell’esposizione, ma non sostituisce la patch del componente vulnerabile. Finché non sono pubblicati il difetto e il percorso di attacco, promettere una regola WAF risolutiva sarebbe prematuro.

La mia lettura tecnica è questa: non serve inseguire ogni screenshot dell’exploit. Serve preparare un cambio infrastrutturale tracciabile. Le indiscrezioni possono giustificare la priorità; solo l’avviso ufficiale deve decidere il pacchetto da installare.

Fai l’inventario in 30 minuti

Un inventario utile non è un foglio con il solo dominio. Per ogni sito devono comparire almeno ambiente, provider, versione PHP servita dal web, modalità di gestione e proprietario dell’intervento. WordPress consente di vedere la versione da Strumenti → Salute del sito → Informazioni → Server. Su infrastruttura amministrata direttamente, il comando php -v controlla la CLI, ma non prova quale versione stia usando il sito: PHP-FPM, Apache e la shell possono puntare a runtime diversi.

La scheda minima per ogni installazione dovrebbe includere:

  • URL pubblico e ambiente di staging associato;
  • versione PHP osservata dal processo web;
  • provider o server che eroga PHP;
  • accesso disponibile: pannello hosting, SSH, console cloud o supporto;
  • persona responsabile e contatto di escalation;
  • orario dell’ultimo backup verificato;
  • procedura di rollback già provata;
  • controlli da eseguire dopo il cambio.

La tabella ufficiale delle versioni supportate indica che PHP 8.4 e 8.5 sono in supporto attivo; PHP 8.2 e 8.3 ricevono soltanto correzioni di sicurezza. PHP 8.2 termina il supporto di sicurezza il 31 dicembre 2026. Un sito su PHP 8.1 o precedente è fuori dal ciclo ufficiale e non va trattato come un normale aggiornamento puntuale: richiede una migrazione verso un ramo supportato, con test di compatibilità.

Per WordPress questo è praticabile. Il team Core ha comunicato nel maggio 2026 che WordPress 6.4 e successivi supportano PHP 8.3, WordPress 6.8 e successivi PHP 8.4, mentre WordPress 6.9 e 7.0 supportano PHP 8.5. Tema, plugin proprietari e integrazioni restano però parte della verifica: la compatibilità del core non garantisce quella dell’intero sito.

Scegli il percorso per il tuo hosting

Su hosting condiviso o gestito non installare pacchetti manualmente. Apri un ticket con quattro domande verificabili: quale ramo PHP usa il sito, se il provider applicherà la release corretta, in quale finestra e come comunicherà il completamento. “Aggiorniamo automaticamente” non è una risposta sufficiente quando manca l’orario.

Su VPS o server dedicato, identifica prima la sorgente del runtime: repository del sistema operativo, repository esterno, immagine container o pannello di controllo. La pubblicazione su php.net non rende immediatamente disponibile un pacchetto in ogni distribuzione. Verifica quindi il bollettino del fornitore e non sostituire il runtime compilando sorgenti in produzione senza una procedura già collaudata.

Prima della patch:

  1. esegui un backup coerente di database e file;
  2. verifica che il backup sia leggibile e che esista una destinazione di ripristino;
  3. salva la versione corrente del runtime e dei pacchetti installati;
  4. prova l’aggiornamento in staging, se l’ambiente replica davvero PHP e le estensioni della produzione;
  5. definisci chi autorizza il rollback e dopo quanti minuti di errore;
  6. riduci le modifiche editoriali e gli ordini in transito durante la finestra.

Un backup non è un rollback finché nessuno sa ripristinarlo. Per WooCommerce o siti con form critici, il punto di ripristino deve tenere conto dei dati ricevuti tra backup e intervento. In questi casi è meglio prevedere una breve modalità manutenzione coordinata che rischiare di perdere ordini, lead o modifiche utente.

La documentazione WordPress raccomanda backup, aggiornamento di core, temi e plugin, controllo di compatibilità e possibilità di tornare alla versione PHP precedente in caso di errore. Oggi questa sequenza non deve diventare un alibi per rimandare: le verifiche di compatibilità vanno fatte prima che il pacchetto sia disponibile.

Verifica il sito, non solo il pacchetto

Dopo l’intervento, il package manager può dichiarare successo mentre PHP-FPM continua a servire processi vecchi oppure il virtual host punta a un pool diverso. La prova deve quindi partire dall’applicazione. Controlla la versione in Salute del sito, riavvia in modo controllato i servizi richiesti dalla distribuzione e conferma che il processo web carichi la build corretta.

Subito dopo esegui una verifica breve ma rappresentativa:

  • homepage e almeno una pagina non in cache;
  • accesso e salvataggio nel back office;
  • invio di un form verso una casella di test autorizzata;
  • checkout e webhook in modalità di test, se presenti;
  • job cron, REST API e chiamate a servizi esterni;
  • log PHP, log del web server e tasso di errori 5xx;
  • svuotamento controllato delle cache opcode e applicative.

Non usare la homepage in cache come unica evidenza. Potrebbe rispondere senza eseguire PHP. Una pagina autenticata o una richiesta REST obbligano invece l’applicazione a passare dal runtime e fanno emergere estensioni mancanti, errori fatali o incompatibilità.

Registra infine quattro dati: versione prima, versione dopo, orario del cambio ed esito dei test. Questo registro trasforma “il provider dice di aver aggiornato” in una prova tecnica. È lo stesso principio applicato al monitoraggio di certificati e configurazioni TLS: un controllo di sicurezza vale quando produce evidenza osservabile, non quando resta una dichiarazione.

Se non puoi applicare subito la patch

La priorità va calcolata sull’esposizione. Un sito pubblico con upload, form, e-commerce o API accessibili richiede una finestra più stretta di uno strumento interno già isolato da VPN e allowlist. Se la patch non è ancora disponibile per la tua distribuzione, chiedi al fornitore un tempo stimato e valuta misure temporanee che riducano la superficie senza fingere di correggere il difetto.

Le azioni ragionevoli sono limitare l’accesso ai sistemi non essenziali, rimuovere dall’Internet pubblico ambienti di staging dimenticati, controllare upload e endpoint inutilizzati, aumentare il monitoraggio di processi anomali e preparare il ripristino. Non improvvisare regole basate su payload circolati online: senza dettagli ufficiali rischiano di bloccare traffico legittimo lasciando aperta una variante dell’attacco.

Se il sito usa un ramo PHP fuori supporto e non può migrare oggi, la decisione deve salire al titolare del rischio. Chiedere un backport al provider può essere utile, ma un backport non ufficiale richiede una conferma esplicita del vendor che lo distribuisce. In assenza di patch o mitigazione verificata, isolare temporaneamente un servizio non essenziale è una scelta più onesta che dichiararlo protetto.

La chiusura operativa

Il piano per oggi è corto: inventario adesso, backup verificato, responsabile nominato, finestra pronta per le 16:00 CEST e controllo applicativo subito dopo. Quando php.net pubblicherà le versioni corrette, confronta il tuo ramo con la matrice ufficiale e applica il pacchetto distribuito dal tuo sistema o provider.

La take più importante per una PMI è organizzativa: una vulnerabilità critica del runtime attraversa tutti i siti sullo stesso server. Gestirla dominio per dominio fa perdere tempo e produce prove incoerenti. Conviene trattare PHP come un asset infrastrutturale condiviso, con un proprietario, un inventario e un tempo massimo di aggiornamento.

Non serve promettere “patch immediata” senza sapere chi controlla il server. Serve poter rispondere, con un orario e un’evidenza, a quattro domande: dove gira PHP, chi lo aggiorna, come torniamo indietro e come dimostriamo che il sito funziona dopo.

Fonti

Approfondimenti