Vulnerabilità WordPress: la falla PHP critica del 2026

Il 21 ottobre 2026 sono stati pubblicati due CVE critici per PHP: CVE-2026-109618 e CVE-2026-109619. È una vulnerabilità WordPress che in realtà non nasce in WordPress: nasce nel linguaggio su cui il sito gira. Permette l'esecuzione di codice da remoto senza autenticazione, e il punteggio CVSS v4 assegnato dal team PHP è 9,2 per entrambe. Qui entrano in scena WordPress, WooCommerce e migliaia di plugin, perché girano tutti su PHP.

Cosa dicono le fonti ufficiali

Le descrizioni nel registro NVD sono sintetiche:

CVE-2026-109618: PHP usa longjmp() per uscire dalle richieste quando la memoria si esaurisce; in alcuni contesti la memoria della richiesta resta non inizializzata e la pulizia successiva può portare a esecuzione di codice.
CVE-2026-109619: parte dello stato globale di PHP può continuare a puntare a memoria di una richiesta già liberata, e le richieste successive possono usarlo prima che sia reinizializzato.

I rami interessati sono PHP 8.2 prima della 8.2.35, 8.3 prima della 8.3.36, 8.4 prima della 8.4.27 e 8.5 prima della 8.5.12. Le versioni corrette sono state rilasciate il 22 ottobre 2026 (vedi il changelog di PHP).

Alcune guide di terzi indicano come vettore la funzione session.upload_progress: non compare nelle descrizioni ufficiali, quindi non trattarla come una protezione sufficiente.

Perché è grave

Tre elementi spiegano l'allarme. Primo: è pre-autenticazione, cioè non servono credenziali valide. Secondo: riguarda il motore PHP, non un singolo plugin, quindi può toccare ogni sito sui rami interessati. Terzo: è già sfruttata in natura. La CISA ha inserito entrambe nel catalogo KEV il 26 ottobre 2026, con scadenza di rimedio fissata al 29 ottobre per gli enti federali statunitensi.

Cosa fare subito: aggiorna PHP

La vera riparazione è l'aggiornamento del runtime:

Aggiorna PHP alla 8.2.35, 8.3.36, 8.4.27 o 8.5.12, o a una versione successiva.
Verifica con il tuo hosting quale versione gira davvero sul sito e se la correzione è stata applicata. In WordPress la versione di PHP è visibile in Strumenti, Salute del sito.
Se usi un ramo non più supportato, il fornitore non rilascia correzioni: pianifica il passaggio a un ramo supportato.
Aggiorna anche le immagini container, se il sito gira in container.

Se hai già subito un incidente, la priorità è isolare e verificare: una risposta all'incidente ordinata riduce danno e tempi di recupero.

Vulnerabilità WordPress e WooCommerce: il punto per chi vende online

Per uno store WooCommerce i dati a rischio non sono solo i file: ci sono i flussi di pagamento e le informazioni dei clienti. La messa in sicurezza non passa solo dall'aggiornamento del tema o dei plugin, ma dal runtime PHP del server. Molti siti restano esposti perché l'hosting o l'immagine container non è stata aggiornata.

Per fortuna la risposta è disciplina manutentiva: PHP allineato, plugin aggiornati, logging abilitato. Un servizio di manutenzione WordPress serve esattamente a questo: tenere aggiornati core, plugin e, soprattutto, l'ambiente di esecuzione. Puoi approfondire la sicurezza di WordPress nel dettaglio.

Come verificare se sei esposto

Parti da tre domande concrete. Che versione di PHP esegue il tuo sito? Il tuo hosting ha applicato le versioni corrette? Chi ti avvisa quando esce una correzione critica? Se una risposta è "non lo so", lì c'è il tuo primo intervento. Il meccanismo somiglia a quanto descritto per gli attacchi alla supply chain: un punto debole condiviso da moltissimi siti.

Come fare, passo per passo: aggiornare PHP senza rompere il sito

Scopri la versione in uso. In WordPress apri Strumenti, Salute del sito, Info. Dalla riga di comando di un server in cui hai accesso:
```
php -v
wp --info
```
php -v mostra la versione della riga di comando, che può differire da quella usata dal web server. wp --info (con WP-CLI) riporta anche il binario PHP in uso. Per essere certo di quella del sito, usa la scheda di Salute del sito.
Confronta con i rami corretti. 8.2.35, 8.3.36, 8.4.27, 8.5.12 o successive.
Fai un backup prima. File e database. Con WP-CLI:
```
wp db export backup-prima-aggiornamento.sql
```
Prova su una copia di staging. Aggiorna lì la versione di PHP, naviga le pagine principali, prova il login, il checkout e i form.
Aggiorna in produzione. Sull'hosting condiviso la versione si cambia dal pannello (per esempio MultiPHP Manager in cPanel o le impostazioni PHP in Plesk). Su un server tuo si aggiorna il pacchetto e si riavvia PHP-FPM:
```
sudo apt-get update
sudo apt-get install --only-upgrade php8.3-fpm
sudo systemctl restart php8.3-fpm
```
Sostituisci 8.3 con il tuo ramo. Il nome del pacchetto e del servizio varia tra le distribuzioni.
Controlla i log. Dopo l'aggiornamento guarda il log degli errori di PHP e quello del server per qualche ora.
Se usi i container, ricostruisci l'immagine scaricando la base aggiornata, poi rilascia:
```
docker build --pull --no-cache -t mio-sito:latest .
```
L'opzione --pull scarica l'ultima immagine di base, --no-cache evita di riusare strati vecchi.

Attenzione alle distribuzioni Linux

Debian, Ubuntu e Red Hat spesso correggono i difetti portando la correzione sulla versione che distribuiscono, senza cambiare il numero di versione del ramo. Un php -v più basso di quelli corretti elencati sopra non vuol dire per forza che sei esposto. Verifica nel registro delle modifiche del pacchetto:

apt changelog php8.3-fpm | grep -i "CVE-2026-10961"

Il comando cerca nel changelog i riferimenti ai due CVE (entrambi iniziano con CVE-2026-10961). Se non compare nulla, controlla l'avviso di sicurezza della distribuzione o chiedi al fornitore. Su sistemi basati su RPM usa rpm -q --changelog sul pacchetto PHP.

Checklist

Versione di PHP verificata dal sito, non solo da una riga di comando.
Ramo supportato e aggiornato, oppure correzione dichiarata dalla distribuzione.
Backup di file e database fatto prima dell'intervento.
Staging provato prima della produzione.
Immagini container ricostruite.
Log di PHP e del web server controllati dopo l'aggiornamento.
Plugin e temi compatibili con la nuova versione.
Un responsabile riceve gli avvisi di sicurezza di PHP e dell'hosting.

Errori da evitare

Aggiornare solo WordPress e i plugin e dimenticare il motore PHP.
Fidarsi di un messaggio dell'hosting senza chiedere la versione precisa.
Aggiornare in produzione senza copia di sicurezza.
Lasciare un ramo non più supportato "finché funziona".
Dimenticare i siti secondari, di test o in sottodominio, che girano su altri account.
Pensare che bastino i plugin di sicurezza: non correggono un difetto del linguaggio.

Consigli pratici

Se un plugin non funziona con la nuova versione, cerca un aggiornamento prima di tornare indietro. Tornare a una versione vulnerabile è l'ultima opzione.
Nel file php.ini imposta expose_php = Off: nasconde la versione di PHP nelle intestazioni HTTP. Non corregge la falla, ma non regala informazioni.
Usa l'ambiente di staging per provare le versioni di PHP future con anticipo, così il passaggio è più breve.
Segui gli annunci di sicurezza ufficiali di PHP e iscrivi un indirizzo condiviso alle comunicazioni dell'hosting.
Controlla anche gli strumenti da riga di comando, come WP-CLI e Composer, che usano la loro versione di PHP.
Dopo il passaggio, svuota OPcache o riavvia PHP-FPM: così ricarichi davvero il nuovo codice.

Domande frequenti

WordPress è vulnerabile di suo? No, la falla è in PHP. WordPress è coinvolto perché gira su PHP.

Se aggiorno WordPress sono al sicuro? No. Servono la versione corretta di PHP o la correzione della distribuzione.

Il mio hosting aggiorna da solo? Dipende dal fornitore e dal piano. Chiedi per iscritto la versione di PHP in uso e se le correzioni sono state applicate.

Che cos'è il catalogo KEV? È l'elenco della CISA delle vulnerabilità di cui è noto lo sfruttamento in natura. Per le due falle l'inserimento è del 26 ottobre 2026, come indicato sopra.

In sintesi

Questa vulnerabilità WordPress non è un bug del CMS: è una falla di PHP che WordPress e il suo ecosistema ereditano. Si chiude aggiornando il runtime. Rimandare, con due CVE già nel catalogo KEV, significa restare un bersaglio facile.