Vulnerabilità critiche di PHP: cosa devono sapere i proprietari di siti WordPress

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

Il 21 ottobre 2026 PHP ha rilasciato delle patch per due vulnerabilità critiche. L'aggiornamento di WordPress o dei plugin non le risolve. Scopri come verificare se il tuo ambiente di hosting è interessato e quali misure adottare.

In breve: cosa è successo

Il 21 ottobre 2026, il progetto PHP ha rilasciato delle correzioni per due vulnerabilità critiche nel runtime di PHP, CVE-2026-109618 e CVE-2026-109619, entrambe classificate 9.2 secondo CVSS v4.0. In determinate condizioni, queste vulnerabilità consentono a un utente malintenzionato non autenticato di eseguire codice sul server web. Si tratta di falle in PHP stesso, non nel core di WordPress, nei temi o nei plugin, quindi la correzione deve essere fornita da una versione di PHP aggiornata installata sul server.

Azione consigliata: chiedi al tuo provider di hosting di confermare che la versione di PHP utilizzata per il tuo sito sia stata aggiornata per entrambe le vulnerabilità. Se gestisci il server autonomamente, installa un pacchetto PHP aggiornato e riavvia PHP.

Gli avvisi del progetto PHP li denominano RCE tramite corruzione OOM (CVE-2026-109618) e RCE tramite stato globale obsoleto (CVE-2026-109619). In entrambi i casi, una richiesta che fallisce nel momento sbagliato può lasciare dati interni in uno stato non valido che PHP utilizzerà in seguito.

Un attacco riuscito esegue del codice con i privilegi dell'account con cui viene eseguito PHP. A seconda di come è configurato il server, questo potrebbe consentire a un aggressore di leggere wp-config.php e le credenziali del database in esso contenute, accedere o modificare il database, oppure modificare i file e i contenuti del sito. Un worker PHP compromesso non concede automaticamente all'aggressore l'accesso root al server.

Stato di sfruttamento (al 21 ottobre 2026)

La PHP Foundation ha dichiarato che il suo team di sicurezza non ha trovato un exploit funzionante nel codice proof-of-concept (PoC) apparso prima del rilascio, ma che lo sviluppo del PoC ha subito un'accelerazione. Il 21 ottobre, Cloudflare, che si riferisce alle vulnerabilità come "php2shell", ha segnalato di aver osservato traffico di attacco diretto ai suoi clienti e che gli aggressori stavano modificando i loro payload per tentare di aggirare le sue protezioni. Nessuna delle due fonti riporta una compromissione confermata e andata a buon fine. Il traffico di attacco dimostra che gli aggressori stanno attivamente tentando di violare la sicurezza, ma ciò non conferma di per sé che un sito sia stato effettivamente compromesso. Aggiorneremo questa sezione man mano che la situazione si evolve.

Chi potrebbe essere interessato?

Potenzialmente, qualsiasi sito web servito da una build PHP non aggiornata è interessato, indipendentemente dalle versioni di WordPress, temi e plugin in esecuzione. L'avviso del progetto PHP riguarda tutte le installazioni PHP che gestiscono richieste web, incluse PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed.

Il progetto PHP considera il rischio più elevato per mod_php, dove è stata dimostrata una vulnerabilità che può essere attivata da una richiesta non autenticata prima ancora che venga eseguito il codice dell'applicazione. Ciò non significa che altre configurazioni siano sicure. Ogni installazione di PHP che gestisce richieste web necessita di questa correzione.

Come verificare la versione di PHP e lo stato delle patch

Nella dashboard di WordPress, vai su Strumenti → Stato del sito → Informazioni ed espandi la sezione Server . Qui troverai la versione di PHP e l'API del server (SAPI) di PHP utilizzata per ospitare il tuo sito. La maggior parte dei pannelli di controllo per l'hosting mostra le stesse informazioni. Se utilizzi WP Cerber, anche in WP Cerber → Strumenti → Diagnostica troverai la versione di PHP e l'API del server.

Le seguenti versioni upstream del progetto PHP contengono le correzioni:

Importante: queste sono versioni upstream, non un test universale di versione minima. Le distribuzioni Linux e i fornitori di supporto a lungo termine (LTS) commerciali possono effettuare il backport delle correzioni nelle build che mantengono un numero di versione precedente, incluse le build dei rami supportati 8.2, 8.3 e 8.4. Ad esempio, Ubuntu 24.04 LTS mantiene i suoi pacchetti PHP 8.3 con una stringa di versione basata su 8.3.6 e distribuisce entrambe le correzioni nella versione del pacchetto 8.3.6-0ubuntu0.24.04.13. Lo stato di salute del sito da solo non può stabilire se una build di un fornitore contiene entrambe le correzioni. Controlla l'avviso di sicurezza del fornitore o il registro delle modifiche del pacchetto, oppure chiedi al tuo host. Non passare a un repository di pacchetti PHP di terze parti solo perché il tuo numero di versione è inferiore alla versione corretta upstream.

PHP 7.4, 8.0 e 8.1. Le build patchate di questi rami, basate sui backport del codice sorgente del progetto PHP, risolvono entrambe le vulnerabilità con una mitigazione minima per le versioni fuori supporto, più limitata rispetto alla correzione completa rilasciata nelle versioni 8.2 e successive. Grazie a questa mitigazione, un processo PHP che esaurisce la memoria viene terminato immediatamente, quindi un sito che supera il limite di memoria potrebbe mostrare un errore generico del server anziché la schermata di errore critico di WordPress. Su tali build, lo stato del sito potrebbe mostrare lo stesso numero di versione prima e dopo l'aggiornamento, quindi si consiglia di verificare la correzione con il proprio provider di hosting o nel registro delle modifiche del pacchetto. L'aggiornamento a un ramo supportato rimane la raccomandazione.

Il supporto per PHP 8.2 terminerà a breve. Il supporto di sicurezza del progetto PHP per PHP 8.2 terminerà il 31 dicembre 2026. Se effettuate l'aggiornamento da PHP 7.4, 8.0 o 8.1, scegliete PHP 8.3 o versioni successive, eseguite prima un backup del sito e verificate la compatibilità del tema e dei plugin. In alternativa, richiedete al vostro provider di hosting una build patchata del vostro ramo corrente.

Perché la correzione deve essere applicata sul server

Il codice vulnerabile fa parte del runtime PHP che esegue WordPress, non di WordPress stesso.

• L'aggiornamento di WordPress non risolve queste vulnerabilità di PHP. L'aggiornamento del core di WordPress, dei temi o dei plugin non modifica l'ambiente di runtime di PHP.
• I plugin di sicurezza non possono risolvere i problemi in fase di esecuzione. Alcuni percorsi di sfruttamento possono essere eseguiti prima del caricamento di WordPress, impedendo così a qualsiasi plugin di analizzare la richiesta. Le regole del firewall per applicazioni web (WAF) a livello di hosting o di rete possono ridurre alcuni percorsi di attacco, ma non sostituiscono completamente l'applicazione delle patch.
• Le modifiche apportate all'interno del sito non rappresentano una soluzione affidabile. L'avviso del progetto PHP sconsiglia di affidarsi a ini_set() o ai file .user.ini di FPM per applicare le misure di mitigazione della configurazione, e lo stesso vale per le impostazioni PHP modificate in wp-config.php o tramite un plugin. Anche le misure a livello di server descritte nell'avviso riducono solo l'esposizione a specifici percorsi di attacco e non rendono l'installazione sicura.

Nota per gli utenti di WP Cerber: WP Cerber viene eseguito all'interno di WordPress. Non può applicare patch a PHP e non può analizzare una richiesta che sfrutta una di queste vulnerabilità prima del caricamento di WordPress. Per lo stesso motivo, i log di WP Cerber potrebbero non registrare un tentativo di questo tipo, quindi un log senza voci sospette non dimostra che il sito non sia stato preso di mira. WP Cerber protegge comunque WordPress a livello di applicazione, ma non sostituisce l'aggiornamento di PHP.

Cosa fare adesso

Se non gestisci il server

Questo vale per l'hosting condiviso e gestito, dove il provider è responsabile della manutenzione del runtime PHP. Chiedi loro di confermare che la versione di PHP utilizzata per il tuo sito web contenga le correzioni per entrambe le vulnerabilità. Puoi inviare questa domanda così com'è:

La versione di PHP che gestisce il mio sito web è aggiornata contro le vulnerabilità CVE-2026-109618 e CVE-2026-109619? I processi worker di PHP pertinenti sono stati riavviati per caricare la versione aggiornata?

Se gestisci un server VPS o dedicato

1. Aggiorna PHP. Installa la versione aggiornata del repository principale, oppure una distribuzione o un pacchetto del fornitore il cui avviso o registro delle modifiche confermi la presenza di entrambe le correzioni.
2. Riavvia PHP. Riavvia o ricarica PHP-FPM, Apache o qualsiasi altro servizio che esegue PHP per i tuoi siti. I processi in esecuzione continuano a utilizzare il vecchio binario finché non vengono riavviati.
3. Verifica. Controlla in Integrità del sito che la build PHP prevista sia ora in esecuzione su ciascun sito. Quindi conferma separatamente, nell'avviso del fornitore o nel registro delle modifiche del pacchetto, che il pacchetto installato contenga entrambe le correzioni. Integrità del sito mostra la versione in esecuzione, ma non può dimostrare che sia incluso un backport. Il comando php -v potrebbe segnalare un'installazione di PHP diversa da quella in esecuzione sul tuo sito web, quindi non fare affidamento solo su di esso.

Qualunque sia il tuo caso, conserva un backup recente che sai di poter ripristinare. Se sospetti che il sito sia stato compromesso prima dell'aggiornamento di PHP, tieni presente che l'aggiornamento di PHP non rimuove malware o backdoor. In tal caso, contatta prima il tuo provider di hosting, perché l'accesso ottenuto tramite PHP potrebbe non essere limitato ai file di WordPress. Per la pulizia dell'installazione di WordPress, consulta la nostra guida Cosa fare se il tuo sito WordPress è stato hackerato .

Domande frequenti

Il mio computer o il mio browser sono a rischio quando visito un sito web infetto?

Non direttamente. Le vulnerabilità risiedono nel codice PHP del server web, non nei dispositivi o nei browser dei visitatori. Un sito compromesso tramite queste vulnerabilità, tuttavia, potrebbe essere modificato per diffondere contenuti dannosi, esponendo quindi i visitatori a rischi indiretti.

Devo reinstallare WordPress?

No, non per risolvere queste vulnerabilità. Vengono corrette aggiornando PHP sul server e la reinstallazione di WordPress non modifica PHP. Una reinstallazione può comunque essere necessaria per ripulire un sito compromesso.

Posso risolvere questo problema senza l'aiuto del mio provider di hosting?

Dipende dal fatto che tu controlli o meno l'ambiente di runtime PHP. Su un server VPS o dedicato, puoi installare autonomamente i pacchetti aggiornati. Su un hosting condiviso o gestito, il controllo di PHP è affidato al provider. Molti pannelli di controllo consentono di passare a una versione diversa di PHP per un sito, ma la disponibilità delle patch in quella versione dipende comunque dal provider.

Fonti

• Progetto PHP, Avviso di sicurezza: vulnerabilità critiche di esecuzione di codice in remoto, aggiornare ora , 21 ottobre 2026.
• Progetto PHP, GHSA-w8hw-w9fx-j79w: Esecuzione remota di codice (RCE) tramite corruzione OOM (CVE-2026-109618) , 21 ottobre 2026.
• Progetto PHP, GHSA-6wmf-4rv5-p3rp: Esecuzione di codice remoto tramite stato globale obsoleto (CVE-2026-109619) , 21 ottobre 2026.
• La PHP Foundation, l'aggiornamento di sicurezza di PHP rilasciato oggi e come stiamo rafforzando la sicurezza di PHP , 21 ottobre 2026.
• Progetto PHP, versioni supportate .
• php-src commit 712e60f: Evita la corruzione dello stato tramite bailout , la mitigazione minima per le versioni di fine ciclo di vita.
• Repository RPM di Remi, registro delle modifiche di php74-php , voce per 7.4.33-31, 21 ottobre 2026.
• Ubuntu, pagine sullo stato della sicurezza per CVE-2026-109618 e CVE-2026-109619 , 21 ottobre 2026.
• Cloudflare, Cloudflare implementa protezioni contro la vulnerabilità php2shell , 21 ottobre 2026.