PHP2Shell: il tuo sito WordPress è a rischio? 7 controlli da fare subito

PHP2Shell comprende due vulnerabilità critiche di PHP che possono consentire l’esecuzione remota di codice senza autenticazione. Ecco come verificare in WordPress la versione PHP, quali release sono corrette e quali controlli eseguire subito.

PHP2Shell è il nome con cui vengono indicate due vulnerabilità critiche del runtime PHP, CVE-2026-109618 e CVE-2026-109619, corrette con aggiornamenti di emergenza pubblicati il 21 ottobre 2026. Entrambe sono classificate con punteggio CVSS v4.0 pari a 9,2 e possono consentire, in determinate condizioni, l’esecuzione remota di codice senza autenticazione con i privilegi del processo Web.

Per chi gestisce WordPress il punto decisivo è questo: PHP2Shell non è una vulnerabilità del core WordPress, di un tema o di un plugin. Il problema si trova nel motore PHP che esegue il sito. Di conseguenza, aggiornare soltanto WordPress o i plugin non corregge queste due falle se il server continua a utilizzare una versione PHP vulnerabile. Cloudflare conferma espressamente che i difetti risiedono nel runtime PHP e che aggiornare il solo codice dell’applicazione non basta.

Il PHP Project ha pubblicato le versioni corrette PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12 e ha dichiarato che non esiste una mitigazione completa alternativa all’aggiornamento. Puoi verificare direttamente le release correnti nella pagina ufficiale dei download PHP.

Nel frattempo Amazon Threat Intelligence ha riferito di aver osservato un tentativo di sfruttamento già il 17 ottobre, quattro giorni prima della divulgazione pubblica, mentre Cloudflare ha dichiarato di aver osservato traffico di attacco e variazioni dei payload dopo la disclosure.

Questo non significa che ogni sito WordPress sia stato compromesso o che ogni installazione PHP sia sfruttabile nello stesso modo. Significa però che chi amministra un sito esposto a Internet deve verificare subito quale versione PHP sta realmente eseguendo e, se necessario, intervenire.

PHP2Shell: cosa è successo il 21 ottobre 2026

PHP2Shell nasce da due vulnerabilità distinte nel runtime PHP. La prima, CVE-2026-109618, riguarda la gestione della memoria quando PHP incontra condizioni di out-of-memory durante l’elaborazione di una richiesta. La seconda, CVE-2026-109619, riguarda invece stato globale appartenente a una richiesta che può sopravvivere oltre il corretto ciclo di vita della memoria e venire riutilizzato successivamente.

Il risultato tecnico può essere molto grave. Gli advisory ufficiali indicano come impatto confermato l’esecuzione remota di codice senza autenticazione; per CVE-2026-109619 sono inoltre descritti scenari di memory disclosure e use-after-free. L’attaccante, se riesce a sfruttare la condizione vulnerabile, opera con i privilegi del worker Web che esegue PHP.

È importante comprendere anche cosa PHP2Shell non è. Il nome può far pensare a una shell già installata sul server, a una backdoor o a un malware specifico. Non è così. PHP2Shell è un’etichetta utilizzata per identificare queste vulnerabilità. L’eventuale installazione di una web shell o di altro codice malevolo sarebbe una conseguenza possibile di un attacco riuscito, non la vulnerabilità stessa.

Le correzioni sono state distribuite nelle release PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Per i rami supportati, una versione precedente alla relativa release corretta deve quindi essere considerata da aggiornare.

Perché PHP2Shell riguarda anche WordPress

WordPress è scritto principalmente in PHP. Quando un visitatore apre una pagina dinamica, il server Web e PHP cooperano per eseguire il codice dell’applicazione e produrre la risposta.

Per questo PHP2Shell può interessare anche un sito WordPress se l’ambiente che lo ospita utilizza una versione PHP vulnerabile. Il problema, però, resta nel runtime PHP e non nel codice WordPress. Questa distinzione evita due errori opposti.

Il primo errore è pensare che basti aggiornare WordPress, i plugin e il tema. Sono operazioni necessarie per la sicurezza generale del sito, ma non sostituiscono la patch PHP.

Il secondo errore è affermare che qualsiasi sito WordPress sia automaticamente compromesso. La possibilità di sfruttamento dipende dalla versione PHP, dal tipo di server, dalla configurazione, dalle funzionalità raggiungibili e dalle condizioni necessarie per ciascun percorso di attacco. Le stesse advisory PHP distinguono scenari confermati e percorsi condizionali.

WordPress raccomanda attualmente PHP 8.3 o superiore. Chi vuole verificare i requisiti aggiornati può consultare direttamente i requisiti ufficiali di WordPress. WordPress precisa inoltre che le release PHP più vecchie e fuori supporto possono esporre il sito a vulnerabilità di sicurezza.

Chi vuole comprendere perché un sito WordPress compromesso possa diventare anche un vettore di altri attacchi può leggere il nostro approfondimento su ClickFix e il falso CAPTCHA, dove abbiamo analizzato campagne che hanno sfruttato anche siti WordPress già violati per mostrare false verifiche e distribuire malware.

1. Controlla quale versione PHP usa davvero il sito

Il primo controllo contro PHP2Shell non consiste nel guardare la versione del pannello hosting o quella installata sul proprio computer. Bisogna verificare la versione PHP utilizzata dal sito Web.

Su WordPress puoi entrare nel pannello amministrativo e aprire:

Strumenti → Salute del sito → Informazioni → Server

La documentazione ufficiale WordPress conferma che la schermata Salute del sito mostra informazioni tecniche sull’ambiente server, inclusa la configurazione PHP. Puoi consultare anche la guida ufficiale alla schermata Salute del sito.

Nella sezione Server viene mostrata la versione PHP effettivamente rilevata da WordPress. Questa è l’informazione più utile per un sito gestito tramite hosting condiviso perché descrive l’ambiente nel quale WordPress sta realmente funzionando.

Se hai accesso alla shell del server puoi anche eseguire:

php -v

ma attenzione: la versione PHP della riga di comando può essere diversa da quella usata dal Web server o da PHP-FPM. Su sistemi che ospitano più versioni PHP, controllare soltanto la CLI può quindi produrre una falsa sicurezza.

Per PHP2Shell il dato importante è la versione usata dalle richieste Web. Se WordPress mostra PHP 8.2.34, 8.3.35, 8.4.26 o 8.5.11, sei su una release precedente alla correzione del 21 ottobre e devi aggiornare.

Se invece il sito utilizza già PHP 8.2.35, 8.3.36, 8.4.27 o 8.5.12, contiene le patch pubblicate dal PHP Project per queste due CVE.

[INSERISCI QUI IMMAGINE INTERNA 1: controllo versione PHP in WordPress]

2. Confronta la versione con quelle corrette per PHP2Shell

Per evitare equivoci, il controllo può essere ridotto a una tabella molto semplice.

Ramo PHP	Prima versione corretta
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Se utilizzi uno di questi rami e la tua versione è inferiore alla corrispondente release corretta, l’aggiornamento è necessario.

Il PHP Project mantiene anche una pagina ufficiale con le versioni PHP attualmente supportate. Al 22 ottobre 2026, PHP 8.2 riceve soltanto aggiornamenti di sicurezza e raggiungerà la fine del supporto il 31 dicembre 2026; PHP 8.3, 8.4 e 8.5 hanno invece finestre di supporto più lunghe.

Questo punto è importante per chi si trova ancora su PHP 7.x, 8.0 o 8.1. Non basta cercare una build “equivalente” perché quei rami sono fuori supporto. In un ambiente di produzione bisogna pianificare la migrazione a una versione PHP supportata e compatibile con il proprio stack.

WordPress.org raccomanda PHP 8.3 o superiore. Chi è ancora su una release obsoleta non deve quindi limitarsi a pensare a PHP2Shell: l’assenza di manutenzione ufficiale espone anche a vulnerabilità future che potrebbero non ricevere alcuna correzione.

3. Se il PHP è gestito dall’hosting, verifica che la patch sia realmente attiva

Molti proprietari di siti WordPress non installano PHP direttamente. Il runtime viene gestito dal provider di hosting.

In questo scenario non serve scaricare manualmente i pacchetti da php.net. Bisogna invece controllare il pannello hosting, la documentazione del provider o aprire una richiesta di assistenza per sapere quale build è stata resa disponibile e quale è assegnata al dominio.

Il controllo non deve fermarsi alla frase “abbiamo aggiornato PHP”. Per PHP2Shell serve verificare il numero completo della versione attiva sul sito.

Se il provider dichiara di aver aggiornato PHP 8.4 ma WordPress continua a mostrare 8.4.26, la patch non è ancora quella richiesta. Se WordPress mostra 8.4.27, la correzione è presente per quel ramo.

Su VPS, server dedicati, container o infrastrutture gestite internamente, il processo dipende invece dal sistema operativo, dal repository utilizzato e dal modello di deployment. Dopo l’aggiornamento bisogna assicurarsi che i worker PHP e i servizi che gestiscono le richieste Web utilizzino effettivamente i nuovi binari.

Con PHP-FPM o altri modelli persistenti può essere necessario un reload o un riavvio dei servizi secondo le procedure previste dalla distribuzione o dal provider. L’obiettivo non è “riavviare a caso”, ma evitare che processi già in memoria continuino a utilizzare codice precedente.

4. PHP2Shell è già stato sfruttato? Cosa sappiamo davvero

Su una vulnerabilità così recente è facile trovare titoli che confondono tentativi, exploit, compromissioni riuscite e sistemi vulnerabili.

Amazon Threat Intelligence ha dichiarato di aver rilevato nel proprio ambiente MadPot un tentativo di sfruttamento riferibile a PHP2Shell il 17 ottobre 2026, quattro giorni prima della divulgazione pubblica. Amazon precisa che non è possibile stabilire se quel tentativo avrebbe avuto successo su un sistema reale.

Dopo la disclosure, Amazon ha osservato ulteriori proof of concept e tentativi provenienti da infrastrutture differenti e ha affermato che PHP2Shell viene ormai sfruttato ampiamente in the wild.

Cloudflare ha comunicato di aver osservato traffico di attacco verso i propri clienti e tentativi di modificare i payload per aggirare le protezioni. L’azienda aveva già predisposto regole WAF specifiche prima della divulgazione pubblica e continua a raccomandare l’aggiornamento PHP anche ai clienti protetti dal proprio firewall applicativo.

Questi dati giustificano un’azione rapida, ma non autorizzano a concludere che il proprio sito sia stato compromesso. Una vulnerabilità sfruttata attivamente aumenta il rischio; la compromissione di un singolo server deve essere dimostrata con evidenze specifiche.

Per PHP2Shell la data del 17 ottobre è però rilevante per chi deve fare incident response: Amazon consiglia di estendere almeno fino a quel giorno l’analisi retrospettiva dei log e delle attività sospette.

5. Controlla log, processi e modifiche anomale dal 17 ottobre

Se un server è rimasto esposto con una versione PHP vulnerabile, installare la patch interrompe il rischio futuro legato a queste CVE ma non dimostra che prima dell’aggiornamento non sia successo nulla.

Per questo il quinto controllo PHP2Shell riguarda la verifica degli indicatori di compromissione.

Amazon raccomanda di controllare i log Web alla ricerca di richieste POST sospette, attività legate a upload multipart, esecuzioni di processi inattesi e modifiche non previste ai file dell’applicazione. Gli indirizzi IP pubblicati nei report di threat intelligence vanno trattati come elementi investigativi, non come prova automatica di compromissione, perché alcuni appartengono a infrastrutture condivise o di anonimizzazione.

Su WordPress è inoltre prudente verificare se siano comparsi utenti amministratori sconosciuti, plugin non installati volontariamente, file modificati senza una spiegazione, attività cron anomale, nuove chiavi o script in directory nelle quali normalmente non dovrebbero comparire.

Questi controlli non sostituiscono un’analisi forense. Servono a individuare segnali che giustifichino ulteriori approfondimenti.

Se trovi modifiche sospette, non limitarti a cancellare il singolo file. Conserva i log e le evidenze, isola l’ambiente se necessario, cambia le credenziali dopo aver messo sotto controllo il sistema e valuta un ripristino da una copia affidabile.

[INSERISCI QUI IMMAGINE INTERNA 2: timeline PHP2Shell 17–21 ottobre 2026]

6. Non affidarti solo a WAF, plugin di sicurezza o backup

Un Web Application Firewall è utile come difesa aggiuntiva. Cloudflare, per esempio, ha distribuito protezioni specifiche contro PHP2Shell per i clienti che utilizzano il proprio WAF. Chi utilizza Cloudflare può approfondire il funzionamento delle protezioni nella spiegazione tecnica pubblicata da Cloudflare.

La stessa Cloudflare, però, dice chiaramente che i clienti devono comunque correggere PHP. Il PHP Project è ancora più netto: non esistono mitigazioni complete e l’aggiornamento è l’unica soluzione affidabile per entrambe le vulnerabilità.

Questo significa che un plugin di sicurezza WordPress non può “patchare” il runtime PHP sottostante. Può bloccare comportamenti sospetti, monitorare file o applicare regole a livello applicativo, ma non sostituisce il codice corretto del motore PHP.

Anche un backup non corregge PHP2Shell. Il backup serve per recuperare dati e configurazioni dopo un incidente; non impedisce a un server vulnerabile di essere attaccato.

Le mitigazioni temporanee descritte negli advisory tecnici possono ridurre specifici percorsi di sfruttamento, ma non coprono tutti gli scenari. Se non puoi aggiornare immediatamente un sistema esposto, ENISA raccomanda di valutare l’isolamento dell’applicazione dalla rete pubblica finché non sia possibile applicare le correzioni. Puoi consultare il comunicato congiunto ufficiale ENISA sulle vulnerabilità PHP.

È una misura drastica, ma coerente con una vulnerabilità critica per la quale il produttore dichiara assente una soluzione completa alternativa alla patch.

7. Dopo PHP2Shell, controlla l’intera catena WordPress

Una volta verificato e corretto PHP2Shell, il lavoro non dovrebbe terminare.

WordPress, tema, plugin e PHP formano una catena. Un runtime aggiornato non compensa un plugin vulnerabile e un WordPress aggiornato non compensa un PHP fuori supporto.

Il controllo finale dovrebbe quindi comprendere lo stato degli aggiornamenti del core WordPress, dei plugin attivi, del tema, delle estensioni PHP, del certificato HTTPS, delle credenziali amministrative e delle procedure di backup.

WordPress dispone già della schermata Salute del sito, che segnala anche versioni PHP obsolete, problemi con gli aggiornamenti automatici, moduli mancanti e altre condizioni rilevanti per sicurezza e funzionamento.

Prima di cambiare ramo PHP su un sito importante, crea un backup verificato e, se possibile, testa l’aggiornamento in staging. La priorità in presenza di PHP2Shell resta comunque applicare la correzione: il test di compatibilità deve aiutare a farlo in sicurezza, non diventare un motivo per lasciare indefinitamente online una versione vulnerabile.

Se vuoi approfondire le buone pratiche generali di protezione, su Helpsystem Informatica trovi anche la guida Come difendersi dagli Hacker?, con indicazioni su aggiornamenti, autenticazione e comportamento prudente.

[INSERISCI QUI IMMAGINE INTERNA 3: checklist sicurezza WordPress dopo PHP2Shell]

PHP2Shell e PHP 8.2: attenzione alla prossima scadenza

C’è un ulteriore elemento che riguarda chi risolve PHP2Shell scegliendo PHP 8.2.35.

La versione 8.2.35 contiene la patch e quindi corregge le due vulnerabilità trattate in questo articolo. Tuttavia il ramo PHP 8.2 raggiungerà la fine del supporto di sicurezza il 31 dicembre 2026.

Chi oggi aggiorna da 8.2.34 a 8.2.35 risolve l’emergenza immediata, ma dovrebbe già pianificare il passaggio a un ramo più recente.

Il PHP Project indica PHP 8.3 con supporto di sicurezza fino al 31 dicembre 2027, PHP 8.4 fino al 31 dicembre 2028 e PHP 8.5 fino al 31 dicembre 2029.

Non significa che tutti debbano passare immediatamente a PHP 8.5. La versione da scegliere dipende dalla compatibilità del sito e del software utilizzato. Significa però che restare su un ramo prossimo alla fine del ciclo di vita crea un’altra scadenza operativa a brevissimo termine.

Per un sito WordPress moderno, WordPress.org raccomanda già PHP 8.3 o superiore.

Come verificare PHP2Shell in meno di due minuti su WordPress

Se vuoi fare soltanto il controllo essenziale, entra in WordPress e apri:

Strumenti → Salute del sito → Informazioni → Server

Leggi la versione PHP.

Se trovi PHP 8.2, assicurati che sia almeno 8.2.35. Se trovi PHP 8.3, deve essere almeno 8.3.36. Se trovi PHP 8.4, deve essere almeno 8.4.27. Se trovi PHP 8.5, deve essere almeno 8.5.12.

Se la versione è inferiore, entra nel pannello hosting o contatta il provider e chiedi l’attivazione della release corretta.

Dopo l’aggiornamento torna nella stessa schermata e verifica che WordPress mostri davvero la nuova versione. Non dare per scontato che aver selezionato un valore nel pannello hosting significhi che il sito lo stia già utilizzando.

Se il sito era esposto con una versione vulnerabile almeno dal 17 ottobre, valuta anche la revisione dei log e delle modifiche al filesystem, soprattutto se il server è direttamente raggiungibile da Internet.

Domande frequenti su PHP2Shell

PHP2Shell è una vulnerabilità di WordPress?

No. PHP2Shell riguarda il runtime PHP. Un sito WordPress può essere interessato perché WordPress viene eseguito attraverso PHP, ma aggiornare solo il core WordPress non corregge CVE-2026-109618 e CVE-2026-109619.

Basta aggiornare plugin e tema?

No. Plugin e tema devono comunque essere mantenuti aggiornati, ma le due vulnerabilità sono nel motore PHP. Serve una versione PHP che includa le patch.

Quali versioni PHP correggono PHP2Shell?

Per i rami supportati trattati dall’advisory, le prime versioni corrette sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12.

Il mio sito è sicuramente compromesso se usava una versione precedente?

No. Essere vulnerabili e risultare compromessi non sono la stessa cosa. Tuttavia sono stati osservati tentativi di sfruttamento già prima della disclosure pubblica, quindi un sistema esposto merita verifiche più approfondite.

Cloudflare o un WAF bastano a proteggermi?

No. Possono aggiungere un livello di difesa e ridurre il rischio di alcuni exploit, ma sia Cloudflare sia il PHP Project raccomandano comunque di applicare la patch.

Se uso hosting condiviso devo fare qualcosa?

Sì: devi almeno verificare la versione PHP effettivamente usata dal sito. Se l’hosting gestisce il runtime, sarà il provider ad applicare materialmente la patch, ma è comunque necessario verificare che il dominio stia utilizzando una release corretta.

La conclusione: PHP2Shell va verificato, non drammatizzato né ignorato

PHP2Shell è una vulnerabilità seria perché colpisce il runtime PHP e può consentire esecuzione remota di codice senza autenticazione. Il punteggio CVSS 9,2, le patch di emergenza e gli avvisi coordinati di PHP Project, ENISA, AWS e Cloudflare giustificano pienamente una verifica immediata.

Allo stesso tempo, è sbagliato trasformare l’allarme in una conclusione automatica secondo cui tutti i siti WordPress sarebbero già compromessi.

La risposta corretta è operativa: identificare la versione PHP realmente usata dal sito, confrontarla con le release corrette, aggiornare senza affidarsi a mitigazioni parziali, verificare che i processi Web stiano utilizzando la nuova build e controllare le attività sospette se il sistema è rimasto esposto.

Per PHP2Shell la verifica richiede pochi minuti. Rimandarla, invece, significa lasciare online un componente per il quale il produttore ha già dichiarato che l’aggiornamento è l’unica soluzione completa.