Vulnerabilità critiche di PHP mettono a rischio i siti WordPress
Le vulnerabilità critiche di PHP identificate come CVE-2026-109618 e CVE-2026-109619 possono esporre i siti WordPress anche quando WordPress Core, plugin e temi sono completamente aggiornati. PHP, il linguaggio di programmazione in cui è scritto principalmente WordPress, ha pubblicato correzioni di emergenza il 21 ottobre 2026. Entrambe le falle hanno un punteggio di gravità Common Vulnerability Scoring System (CVSS) v4.0 pari a 9,2 su 10 e possono consentire la remote code execution, cioè permettere a un attaccante di far eseguire comandi al server senza prima effettuare l'accesso.
Si tratta di falle di PHP a livello server, non di debolezze di WordPress stesso. Pertanto, l'aggiornamento di WordPress non installa le patch necessarie. Le prime versioni di PHP che includono le correzioni sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le distribuzioni Linux e i fornitori di supporto a lungo termine possono aggiungere le stesse patch a pacchetti che mantengono numeri di versione principali meno recenti; gli amministratori devono quindi verificare la revisione completa del pacchetto confrontandola con l'avviso di sicurezza del fornitore. Dopo l'installazione, PHP deve essere riavviato affinché ogni processo attivo carichi il codice corretto. I container, che racchiudono un'applicazione insieme al relativo runtime e alle dipendenze, devono essere ricostruiti e distribuiti nuovamente a partire da un'immagine aggiornata.
Lo sfruttamento riuscito darebbe a un attaccante gli stessi privilegi di accesso a file e dati disponibili per il sito web. Secondo gli avvisi del progetto PHP, ciò potrebbe consentire la lettura delle credenziali del database, il furto dei dati del sito, la modifica dei file del sito o l'installazione di una backdoor persistente, ossia un accesso nascosto progettato per sopravvivere dopo l'intrusione iniziale. PHP ha confermato la remote code execution per entrambe le vulnerabilità e ha confermato che una modalità di attacco relativa a CVE-2026-109618 viene eseguita prima che WordPress inizi a funzionare. Questa distinzione è importante perché uno strumento di sicurezza che opera soltanto all'interno di WordPress potrebbe non rilevare mai la parte iniziale di una richiesta di questo tipo.
Le due vulnerabilità arrivano all'esecuzione di codice in modi diversi. Con CVE-2026-109618, PHP può gestire in modo errato i dati quando una richiesta esaurisce la memoria disponibile. La memory corruption risultante, cioè la modifica non sicura dei dati nella memoria di lavoro, può consentire a un attaccante non autenticato di eseguire codice. Con CVE-2026-109619, un PHP worker, uno dei processi che gestiscono le richieste dei siti web, può continuare a utilizzare informazioni lasciate da una richiesta completata. Una richiesta successiva assegnata allo stesso worker può utilizzare questi dati obsoleti per eseguire codice.
CrowdStrike riferisce che il suo exploit privato per le vulnerabilità ha funzionato in modo affidabile sui sistemi Intel/AMD e Arm, anche contro PHP worker appena riavviati. Wordfence ha dichiarato di non aver testato in modo indipendente tale exploit non pubblicato. È già in circolazione materiale pubblico di proof of concept, ossia codice dimostrativo destinato a mostrare se una falla può essere attivata, ma Wordfence ha avvertito che alcuni esempi e commenti sono incompleti, fuorvianti o errati. La necessità di adattare un exploit a uno specifico server non dimostra che un'installazione priva di patch sia sicura.
Il team Wordfence Threat Intelligence ha esaminato le patch di PHP e ha iniziato i test di laboratorio entro poche ore dalla loro pubblicazione. In un ambiente PHP 8.5.11 appositamente configurato che utilizzava Apache, software che accetta e gestisce le richieste web, il suo proof of concept per CVE-2026-109619 è arrivato tramite HTTP e ha creato un file di testo temporaneo. Ciò ha confermato l'esecuzione di codice in quell'ambiente di laboratorio. Lo stesso test ha causato il crash di una normale build ottimizzata di PHP 8.5.11 invece di eseguire codice, mentre la versione corretta PHP 8.5.12 è rimasta stabile.
Per CVE-2026-109618, la versione vulnerabile PHP 8.5.11 ha smesso di funzionare durante il test, mentre PHP 8.5.12 ha elaborato normalmente la stessa richiesta di proof of concept. In test separati effettuati con WordPress 7.1.3 e un pacchetto Ubuntu PHP 8.5.4 interessato, richieste appositamente costruite hanno causato malfunzionamenti o riavvii di PHP in alcune configurazioni. Wordfence non ha ottenuto in modo indipendente l'esecuzione di codice per quella CVE. Questi risultati preliminari mostrano che il comportamento varia tra build e configurazioni server, ma un crash al posto dell'esecuzione di codice non dimostra che un server interessato sia sicuro.
PHP 8.1 e i branch precedenti non ricevono più release dal progetto PHP. Un fornitore di sistemi operativi o di supporto a lungo termine potrebbe continuare a distribuire le patch, ma gli operatori devono ottenere una conferma esplicita. In caso contrario, il sito deve essere trasferito a un branch PHP supportato. I proprietari dei siti possono vedere la versione che serve effettivamente WordPress in Strumenti > Salute del sito > Informazioni > Server. Il risultato dell'esecuzione di `php -v` da un prompt dei comandi non è sufficiente, perché un server può utilizzare una versione di PHP per i comandi e un'altra per i siti web.
I clienti di servizi di hosting gestito devono chiedere se il servizio PHP che gestisce il loro sito dispone delle patch per entrambe le CVE e se è stato riavviato. Gli operatori che gestiscono autonomamente i server devono aggiornare PHP e riavviare Apache, PHP-FPM, un servizio che esegue i processi PHP, oppure qualsiasi altro servizio PHP attivo. Le agenzie e i fornitori di hosting devono controllare ogni sito di produzione, staging site, cioè una copia separata utilizzata per i test, indirizzo origin diretto e container meno recente, invece di verificare soltanto il dominio pubblico principale. Successivamente, devono confermare sia la versione indicata in Salute del sito sia la revisione completa del pacchetto tramite il provider di hosting, gli strumenti per i pacchetti del sistema operativo o il fornitore dell'immagine del container.
A titolo precauzionale, Wordfence consiglia di conservare i backup e preservare i log del web server, di PHP, del firewall e del sistema relativi almeno alle 48 ore precedenti la release del 21 ottobre e fino all'applicazione delle patch e al riavvio di PHP. Se l'aggiornamento è stato ritardato, gli amministratori devono esaminare tali registri alla ricerca di attività insolite per il sito e indagare su qualsiasi elemento sospetto. Log apparentemente puliti non possono dimostrare che non si sia verificato uno sfruttamento. Le raccomandazioni temporanee di PHP possono ridurre l'esposizione a specifiche modalità di attacco quando non è possibile applicare immediatamente le patch, ma sono incomplete, possono interferire con le normali funzioni del sito e non sostituiscono l'aggiornamento.
Wordfence Firewall protegge l'application layer di WordPress, la parte che elabora le richieste specifiche di WordPress, utilizzando Wordfence Threat Intelligence. Non sostituisce gli aggiornamenti e i controlli per PHP, il web server, il sistema operativo e il network edge, ossia i sistemi esterni attraverso i quali il traffico raggiunge il sito. I clienti Wordfence Care e Wordfence Response possono contattare il relativo team di incident response se sospettano una compromissione; Wordfence afferma che Response è disponibile 24 ore su 24, 7 giorni su 7, 365 giorni l'anno, con un tempo di risposta di un'ora.
Questo incidente mostra inoltre l'importanza dei servizi gestiti per i proprietari che non amministrano direttamente PHP: AEU Hosting fornisce hosting WordPress gestito e protetto end to end. Indipendentemente dal modello di hosting, la risposta essenziale consiste nell'installare un pacchetto di cui sia stata confermata l'inclusione di entrambe le correzioni, riavviare PHP e verificare l'esatto servizio e pacchetto che gestiscono il sito web.