Il 21 ottobre 2026 il PHP Security Team ha pubblicato aggiornamenti di sicurezza urgenti per correggere due vulnerabilità critiche che possono consentire l’esecuzione remota di codice senza autenticazione.
Le vulnerabilità sono identificate come:
- CVE-2026-109618
- CVE-2026-109619
Le versioni PHP corrette sono:
| Ramo PHP | Versione corretta |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Il progetto PHP raccomanda l’aggiornamento immediato e specifica che non esistono mitigazioni complete alternative all’installazione delle versioni corrette.
Per chi gestisce siti WordPress o WooCommerce non si tratta quindi di una vulnerabilità teorica o marginale: PHP è il runtime su cui WordPress viene eseguito, e il problema riguarda direttamente l’infrastruttura che gestisce le richieste web.
Chi è esposto
Secondo l’advisory ufficiale, sono potenzialmente interessate tutte le installazioni PHP che servono richieste HTTP, incluse configurazioni basate su:
- PHP-FPM;
- Apache con
mod_php; php-cgi;- FrankenPHP;
- LiteSpeed.
Il rischio viene considerato particolarmente elevato nel caso di mod_php: il team PHP segnala che è stato dimostrato un percorso di exploit attivabile da una richiesta non autenticata prima ancora dell’esecuzione del codice dell’applicazione.
Questo punto è importante.
Non stiamo parlando necessariamente di una vulnerabilità in WordPress, in WooCommerce o in un plugin.
Il problema si trova nel runtime PHP sottostante.
Aggiornare WordPress, temi e plugin non corregge quindi queste vulnerabilità se il server continua a utilizzare una versione PHP vulnerabile.
CVE-2026-109618: RCE tramite corruzione durante Out of Memory
La prima vulnerabilità riguarda la gestione di condizioni Out of Memory.
Durante l’elaborazione di una richiesta, PHP può trovarsi in una situazione in cui alcuni dati interni risultano inizializzati solo parzialmente.
Se si verifica un errore di allocazione della memoria in quel momento, la fase di cleanup può successivamente trattare quei dati incompleti come se fossero validi.
Il risultato può essere una condizione di corruzione della memoria sfruttabile per ottenere Remote Code Execution.
Il PHP Security Team identifica il problema come:
CVE-2026-109618 — RCE via OOM corruption.
In termini pratici, un attaccante potrebbe tentare di portare il processo PHP in una condizione controllata di esaurimento della memoria e sfruttare il comportamento anomalo successivo.
CVE-2026-109619: stato globale non più valido riutilizzato tra richieste
La seconda vulnerabilità è differente.
In alcune condizioni, stato interno appartenente a una richiesta può sopravvivere anche dopo che la memoria associata è stata liberata.
Una richiesta successiva gestita dallo stesso worker potrebbe quindi utilizzare quello stato obsoleto prima che la normale inizializzazione lo sostituisca.
Il problema è identificato come:
CVE-2026-109619 — RCE via stale global state.
È un caso particolarmente delicato nei modelli server che mantengono worker PHP attivi tra richieste successive, perché il comportamento potenzialmente sfruttabile può attraversare il confine tra una richiesta e quella seguente.
Quali versioni PHP installare
Se il server utilizza uno dei rami attualmente supportati, il percorso consigliato è semplice.
PHP 8.5
Aggiornare almeno a:
PHP 8.5.12PHP 8.4
Aggiornare almeno a:
PHP 8.4.27PHP 8.3
Aggiornare almeno a:
PHP 8.3.36PHP 8.2
Aggiornare almeno a:
PHP 8.2.35Le quattro release sono state pubblicate specificamente come aggiornamenti di sicurezza e correggono entrambe le vulnerabilità.
Dove scaricare le patch ufficiali
La fonte da utilizzare è il sito ufficiale PHP.
La pagina di download contiene i sorgenti delle versioni aggiornate e, per Windows, anche i relativi binari.
Download ufficiali PHP:
https://www.php.net/downloads.php
Security advisory ufficiale:
https://www.php.net/archive/2026.php#2026-10-21-5
Per chi gestisce direttamente server Linux, però, normalmente non è consigliabile sostituire manualmente i binari PHP scaricando il sorgente.
Se PHP è stato installato tramite i repository della distribuzione, è preferibile utilizzare gli aggiornamenti del vendor.
Il team PHP specifica che distribuzioni Linux e provider LTS hanno ricevuto le patch in anticipo proprio per poter pubblicare pacchetti aggiornati.
Come verificare quale versione PHP utilizza WordPress
Dal pannello WordPress puoi controllare la versione PHP da:
Strumenti → Salute del sito → Informazioni → Server
Qui trovi la voce relativa alla versione PHP attualmente utilizzata dal sito.
In alternativa, se hai accesso alla shell:
php -vAttenzione però a un dettaglio importante.
Il comando da terminale può mostrare la versione PHP utilizzata dalla CLI, che non necessariamente coincide con quella utilizzata dal web server.
Un server può, ad esempio, avere:
- PHP 8.4 in CLI;
- PHP 8.3 tramite PHP-FPM;
- più pool FPM con versioni differenti.
Per questo, su hosting o server con configurazioni multiple, conviene verificare la versione effettivamente collegata al sito web.
Come aggiornare su hosting gestito
Su hosting condivisi o gestiti il percorso più semplice è generalmente il pannello del provider.
La sezione può chiamarsi, a seconda dell’hosting:
- PHP Manager;
- PHP Version;
- MultiPHP Manager;
- Runtime;
- Server Configuration.
Prima di effettuare un cambio di ramo importante, per esempio da PHP 8.2 a 8.4, è comunque opportuno verificare la compatibilità di:
- WordPress;
- WooCommerce;
- tema;
- plugin;
- codice personalizzato.
Se invece il provider rende disponibile una patch della stessa serie, ad esempio da PHP 8.3.35 a 8.3.36, l’aggiornamento è generalmente molto meno invasivo.
Attenzione: riavviare i worker PHP
Dopo l’aggiornamento del pacchetto non è sufficiente presumere che tutti i processi in memoria abbiano iniziato automaticamente a utilizzare il nuovo codice.
Su sistemi gestiti direttamente è buona pratica verificare e, dove necessario, riavviare PHP-FPM o il servizio web coinvolto.
Per esempio:
systemctl restart php8.4-fpmoppure, a seconda della configurazione:
systemctl restart apache2o:
systemctl restart httpdIl comando corretto dipende dalla distribuzione e dall’architettura del server.
E se sto usando PHP 8.1?
PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti ordinari dal progetto PHP.
Il Security Team specifica che alcune distribuzioni Linux e provider LTS possono comunque distribuire backport delle patch.
Data la gravità di queste vulnerabilità, sono stati inoltre pubblicati backport sorgente minimi per:
- PHP 7.4;
- PHP 8.0;
- PHP 8.1.
Questi backport sono destinati soprattutto a chi compila PHP autonomamente o non dispone di un vendor LTS.
Non dovrebbero però essere interpretati come un ritorno al supporto ufficiale di questi rami.
Se un sito WordPress utilizza ancora PHP 7.4, 8.0 o 8.1, la correzione d’emergenza dovrebbe essere accompagnata da un piano di migrazione verso una versione supportata.
PHP 8.2: aggiornare ora, ma pianificare già la migrazione
PHP 8.2 è ancora coperto da aggiornamenti di sicurezza, ma il supporto termina il 31 dicembre 2026. PHP 8.3 riceverà aggiornamenti di sicurezza fino al 31 dicembre 2027, PHP 8.4 fino al 31 dicembre 2028 e PHP 8.5 fino al 31 dicembre 2029.
Per un sito attualmente su PHP 8.2 ci sono quindi due decisioni separate:
- aggiornare immediatamente almeno a PHP 8.2.35 per correggere le vulnerabilità;
- pianificare la migrazione a un ramo più recente prima della fine del supporto.
Non è necessario mischiare le due operazioni.
In una situazione di emergenza può essere preferibile installare prima la patch dello stesso ramo, verificare la stabilità del sito e successivamente pianificare con calma un upgrade maggiore.
Se non posso aggiornare immediatamente
L’advisory PHP descrive alcune misure temporanee che possono ridurre determinate superfici di attacco.
È però importante non confonderle con una soluzione definitiva.
Per CVE-2026-109618 vengono citate, tra le altre:
- configurazioni specifiche del
memory_limit; - limitazione delle dimensioni delle richieste;
- limiti applicati a livello di web server o proxy.
Per CVE-2026-109619 vengono indicate misure come:
session.upload_progress.enabled=0e, su PHP 8.5:
fatal_error_backtraces=0seguite dal riavvio dei worker.
Il PHP Security Team è però molto chiaro: queste misure bloccano solo determinati percorsi conosciuti e non rendono sicura un’installazione vulnerabile.
Per questo motivo non le considererei una vera alternativa all’aggiornamento.
Cosa controllare dopo l’aggiornamento
Dopo aver aggiornato PHP, non fermarti alla semplice verifica della versione.
Controlla almeno:
- frontend del sito;
- login WordPress;
- pannello amministrativo;
- form;
- upload di file;
- cron WordPress;
- chiamate REST API;
- checkout WooCommerce;
- gateway di pagamento;
- webhook;
- eventuali integrazioni esterne.
Controlla inoltre i log PHP e quelli del web server per individuare:
- warning;
- funzioni deprecate;
- errori fatali;
- plugin non compatibili;
- problemi legati a estensioni PHP mancanti.
Su WooCommerce è particolarmente importante testare almeno un ordine completo utilizzando il gateway normalmente impiegato in produzione.
Aggiornare PHP senza test può creare problemi?
Sì, soprattutto se contemporaneamente si cambia ramo.
Passare, per esempio, da PHP 7.4 a PHP 8.4 può far emergere codice non più compatibile.
Ma questo non è un buon motivo per mantenere una versione vulnerabile.
La strategia corretta è:
- backup;
- ambiente di staging, se disponibile;
- aggiornamento PHP;
- test funzionali;
- controllo dei log;
- deploy in produzione.
Nel caso specifico di queste vulnerabilità, però, la priorità dell’aggiornamento è elevata.
Una lunga attesa per ottenere un ambiente perfetto di test deve essere bilanciata con il rischio concreto di lasciare esposto un runtime PHP vulnerabile.
WordPress è vulnerabile?
La formulazione corretta è leggermente diversa.
Queste due vulnerabilità non sono vulnerabilità del core WordPress.
Sono vulnerabilità del motore PHP su cui WordPress viene eseguito.
Un’installazione WordPress completamente aggiornata può quindi essere esposta se gira sopra una versione PHP vulnerabile.
È un buon esempio del perché la sicurezza di WordPress non possa essere ridotta a:
“WordPress, tema e plugin sono aggiornati.”
Il sito dipende anche da:
- PHP;
- web server;
- sistema operativo;
- database;
- librerie;
- configurazione dell’hosting.
Tutti questi componenti fanno parte della superficie di sicurezza.
Cosa fare oggi
Se gestisci uno o più siti WordPress o WooCommerce:
1. Controlla subito la versione PHP.
2. Se utilizzi PHP 8.2, 8.3, 8.4 o 8.5, assicurati di avere almeno:
8.2.35
8.3.36
8.4.27
8.5.123. Se utilizzi PHP 8.1 o precedente, verifica con il provider se è disponibile un backport e programma la migrazione verso una versione supportata.
4. Se gestisci direttamente il server, aggiorna i pacchetti e riavvia i worker PHP.
5. Controlla i log e testa le principali funzionalità del sito.
Perché questa vulnerabilità merita attenzione
Non tutte le CVE hanno lo stesso impatto.
In questo caso il progetto PHP parla esplicitamente di Remote Code Execution non autenticata e raccomanda l’aggiornamento immediato.
Inoltre, l’attacco può avvenire a livello del runtime PHP, prima o indipendentemente dalla logica di WordPress.
Questo rende poco utili molte delle difese normalmente considerate sufficienti a livello applicativo.
Firewall, plugin di sicurezza e aggiornamenti WordPress rimangono importanti, ma non sostituiscono la correzione del componente vulnerabile.
La priorità, in questo caso, è molto semplice:
verificare la versione PHP e applicare la patch.
Riferimenti ufficiali
- Security Advisory PHP:
https://www.php.net/archive/2026.php#2026-10-21-5 - Download PHP:
https://www.php.net/downloads.php - Versioni PHP supportate:
https://www.php.net/supported-versions.php - CVE-2026-109618 — advisory tecnico collegato dal PHP Security Team
- CVE-2026-109619 — advisory tecnico collegato dal PHP Security Team
Se gestisci un sito WordPress o WooCommerce e non sai se il tuo ambiente PHP è aggiornato o compatibile con una versione più recente, WPClinic può aiutarti a verificare configurazione, compatibilità e percorso di aggiornamento prima di intervenire in produzione.