PHP2Shell: cos’è, quali versioni PHP sono vulnerabili e cosa fare su WordPress

Se gestisci un sito WordPress, la prima cosa da chiarire è questa: PHP2Shell non è una vulnerabilità di WordPress, di un plugin o di un tema. Il problema si trova nel runtime PHP che esegue l’applicazione sul server e, in determinate condizioni, può consentire l’esecuzione di codice da remoto senza autenticazione.

In pratica, PHP2Shell va trattato come una vulnerabilità PHP a livello server: il punto da verificare non è soltanto l’applicazione WordPress, ma il runtime che la esegue e lo stato reale della patch nell’ambiente hosting.

Questo cambia anche il modo in cui devi reagire. Aggiornare WordPress non corregge PHP2Shell. Installare un plugin di sicurezza non corregge PHP2Shell. E sapere semplicemente che il sito usa “PHP 8.x” non basta a stabilire se il server sia protetto.

Le prime versioni corrette sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Se il tuo sito utilizza una release precedente della stessa branch, devi verificare l’aggiornamento. Se l’hosting gestisce PHP per te, invece, devi accertarti che il provider abbia applicato la patch o un backport equivalente.

Il punto importante è quindi separare tre domande: quale PHP esegue realmente il sito, chi è responsabile della patch e come verificare che la correzione sia effettivamente attiva.

PHP2Shell in breve: cosa fare adesso

Se vuoi arrivare subito alla decisione, usa questo schema.

La pagina ufficiale PHP indica le release di sicurezza correnti e specifica che l’aggiornamento è la scelta sicura. Per i sistemi nei quali non puoi intervenire direttamente, la responsabilità pratica passa invece al provider.

Se non sai neppure quale versione stia usando WordPress, puoi partire dalla nostra guida su come controllare la versione PHP di un sito WordPress. Per PHP2Shell, però, quello è soltanto il primo controllo: dovrai poi capire se quella versione corrisponde davvero al runtime che serve le richieste web e se il provider ha applicato eventuali correzioni proprie.

Che cos’è PHP2Shell e perché il problema è nel runtime PHP

PHP2Shell è il nome con cui vengono indicate due vulnerabilità critiche del core PHP che possono portare, in condizioni specifiche, all’esecuzione di codice remoto.

Il dettaglio importante non è tanto memorizzare due identificativi quanto capire dove si trova il difetto.

Quando un visitatore apre una pagina WordPress, la richiesta attraversa il web server e arriva al runtime PHP. Solo dopo PHP esegue il codice di WordPress, del tema e dei plugin.

Con PHP2Shell alcuni percorsi vulnerabili possono entrare in gioco all’interno del runtime PHP stesso. In alcuni scenari il problema può quindi manifestarsi prima che il normale codice applicativo abbia la possibilità di intervenire.

È anche il motivo per cui questa vulnerabilità va trattata in modo diverso da un plugin WordPress vulnerabile.

Il problema legato all’out-of-memory

Il primo advisory ufficiale, descritto come RCE via OOM corruption, riguarda il modo in cui PHP può gestire alcune condizioni di esaurimento della memoria.

Semplificando molto il meccanismo: durante l’elaborazione di una richiesta, PHP può trovarsi in uno stato intermedio nel quale alcune strutture di memoria non sono ancora completamente inizializzate. Se l’elaborazione viene interrotta da una condizione di out-of-memory nel momento sbagliato, il successivo processo di shutdown può ritrovarsi a lavorare su uno stato non valido.

Non significa che qualsiasi errore “memory exhausted” consenta automaticamente un attacco. L’exploit richiede condizioni precise e la sua affidabilità dipende dall’ambiente, dal modo in cui PHP viene eseguito e da altri dettagli tecnici.

Il risultato potenziale, tuttavia, è serio: l’advisory ufficiale classifica la vulnerabilità come critica e conferma la possibilità di esecuzione di codice remoto.

Per chi gestisce un sito la conseguenza pratica è più semplice del meccanismo: non cercare di risolvere il problema aumentando o diminuendo casualmente <code>memory_limit</code>. Le modifiche di configurazione possono cambiare alcuni percorsi di rischio, ma non costituiscono la correzione completa.

Lo stato globale che può sopravvivere tra due richieste

Il secondo problema è descritto nell’advisory RCE via stale global state.

Qui il modello mentale utile è quello del worker PHP.

Un worker non nasce necessariamente da zero per ogni singola pagina richiesta. In molti ambienti rimane attivo e gestisce più richieste nel tempo. Alcuni dati globali devono quindi essere azzerati correttamente quando termina una richiesta.

Se uno stato appartenente alla richiesta precedente resta referenziato dopo che la relativa memoria è stata liberata, una richiesta successiva può trovarsi a interagire con informazioni che non dovrebbero più esistere.

È una classe di problema nota come use-after-free.

Perché diventi sfruttabile devono combinarsi più condizioni: serve qualcosa che lasci lo stato in una condizione problematica e un successivo percorso che lo utilizzi prima della normale reinizializzazione.

La patch interviene proprio su questo confine tra richieste.

Questa seconda vulnerabilità spiega anche perché non è sufficiente ragionare solo sulla singola pagina WordPress visitata. La questione riguarda il ciclo di vita del processo PHP, non la logica di un post, un tema o un plugin specifico.

Perché aggiornare WordPress, plugin e temi non corregge PHP2Shell

WordPress utilizza PHP, ma WordPress e PHP sono componenti distinti.

Puoi avere:

• WordPress aggiornato e PHP vulnerabile;
• PHP aggiornato e un plugin WordPress vulnerabile;
• entrambi aggiornati ma una configurazione server debole;
• una versione PHP apparentemente precedente ma corretta dal provider tramite backport.

È per questo che una buona strategia di sicurezza WordPress deve considerare anche il livello infrastrutturale.

Core, plugin e temi rimangono importanti, ma la patch di PHP2Shell deve avvenire sul componente PHP interessato.

Il confine è utile anche in fase diagnostica: se stai cercando una patch PHP2Shell nella dashboard degli aggiornamenti di WordPress, stai guardando nel posto sbagliato.

Quali versioni PHP sono vulnerabili e quali sono corrette

Per le branch attualmente interessate dagli aggiornamenti ufficiali, le prime release che includono le correzioni complete sono queste. Quando valuti le versioni PHP vulnerabili, confronta sempre la branch effettivamente usata dal sito con la prima release corretta della stessa linea:

Se utilizzi una release precedente all’interno della stessa branch, considera necessario un controllo immediato.

Esempio: PHP 8.4.26 precede 8.4.27, quindi non appartiene alla prima release ufficiale che incorpora la correzione completa.

Le prime release PHP che includono la correzione

La tabella serve per prendere una decisione, non per ridurre la verifica a un confronto numerico.

Se controlli il server e trovi PHP 8.3.35, la direzione è chiara: devi arrivare almeno a 8.3.36 oppure a una release successiva supportata.

Lo stesso vale per le altre branch.

Quando puoi scegliere liberamente, ha normalmente più senso restare su una branch PHP supportata e aggiornata invece di trasformare la patch di emergenza in un motivo per mantenere indefinitamente una versione legacy.

Il passaggio di versione va comunque gestito con criterio: backup, staging quando disponibile, verifica della compatibilità di temi e plugin, aggiornamento e controllo finale.

Versioni precedenti, backport e patch del provider

La situazione diventa meno lineare quando il server utilizza una branch precedente oppure un pacchetto PHP gestito dalla distribuzione Linux o dall’hosting.

In questi ambienti numero di versione upstream e stato di sicurezza del pacchetto non sempre coincidono perfettamente.

Un vendor può infatti applicare una correzione al proprio pacchetto senza adottare esattamente lo stesso versioning mostrato dal progetto PHP. Questa pratica viene generalmente indicata come backport.

Per questo, se utilizzi un server gestito da terzi, non dovresti concludere:

versione apparentemente precedente = sicuramente vulnerabile

ma neppure il contrario:

il provider penserà sicuramente a tutto = sicuramente protetto

La risposta corretta deve arrivare dalla documentazione del vendor, dal changelog del pacchetto o dal supporto dell’hosting.

Se il provider non fornisce informazioni sufficienti e non hai gli strumenti per verificare il runtime, può essere sensato richiedere un intervento di assistenza WordPress e sistemistica invece di modificare PHP alla cieca su un sito in produzione.

Perché conoscere il numero di versione può non bastare

Il secondo problema è ancora più comune: potresti controllare il PHP sbagliato.

Su un server possono convivere più versioni PHP.

La shell può utilizzare una versione; il sito un’altra. Un dominio può essere associato a un pool PHP-FPM diverso da quello di un secondo dominio. Il pannello hosting può mostrare la versione configurata per l’account mentre una specifica applicazione segue una configurazione differente.

Quindi il controllo:

<code>php -v</code>

è utile, ma non dimostra da solo quale runtime stia elaborando le richieste HTTP del tuo WordPress.

Per PHP2Shell la domanda corretta non è semplicemente:

“Quale PHP è installato?”

ma:

“Quale PHP sta realmente eseguendo questo sito quando riceve una richiesta dal web?”

È una differenza piccola nella formulazione, ma enorme nella diagnosi.

Come verificare se il tuo sito è realmente esposto

La verifica dovrebbe procedere dal livello più semplice a quello più specifico.

L’obiettivo non è “testare l’exploit” contro il proprio sito. Non serve e introduce un rischio inutile. Devi invece identificare versione, runtime, modalità di esecuzione e stato della patch.

CERT-AGID ha raccolto anche strumenti per verificare l’esposizione a PHP2Shell con approcci che includono il controllo della versione dichiarata e verifiche remote non basate sull’esecuzione dell’exploit.

WordPress Site Health e pannello hosting: da dove partire

Su WordPress, il primo controllo accessibile è Strumenti → Salute del sito → Informazioni → Server.

Qui puoi individuare la versione PHP vista dall’installazione.

Il secondo controllo va fatto nel pannello dell’hosting: cPanel, Plesk o il pannello proprietario del provider possono indicare la versione associata al dominio.

Se entrambi mostrano una delle release corrette o una versione successiva, hai un buon primo segnale.

Se mostrano una release precedente, non fermarti al numero: verifica se il provider dichiara un backport.

Se i due pannelli mostrano informazioni diverse, quella discrepanza è già un motivo per approfondire.

PHP da riga di comando e PHP del sito possono essere diversi

Su VPS e server dedicati è frequente utilizzare la shell per controllare PHP.

Il problema è che <code>php -v</code> interroga normalmente PHP CLI, cioè l’interprete utilizzato dalla riga di comando.

Il sito potrebbe invece girare tramite PHP-FPM o un modulo del web server.

È quindi possibile ottenere una situazione come questa:

CLI aggiornata → runtime web ancora precedente

oppure l’opposto.

Per questo, dopo un aggiornamento, non considerare il lavoro concluso finché non hai verificato la versione nel contesto web effettivo.

È particolarmente importante sui server nei quali sono presenti più socket PHP-FPM, più pool o più versioni installate contemporaneamente.

PHP-FPM, mod_php, php-cgi, LiteSpeed e gli altri runtime

Il progetto PHP include tra gli ambienti da considerare PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed.

Non tutti hanno esattamente lo stesso percorso di sfruttamento o lo stesso livello di esposizione per ogni singolo meccanismo, ma il punto operativo resta invariato: se il runtime serve richieste web ed è interessato dalle versioni vulnerabili, va aggiornato.

L’advisory ufficiale considera particolarmente rilevante il caso di Apache con mod_php, per il quale è stato dimostrato un percorso di esecuzione remota prima dell’esecuzione del normale codice applicativo.

Questo non significa che FPM sia “sicuro per definizione”. Uno degli advisory descrive anche percorsi validati con worker FPM per la gestione dello stato tra richieste.

Quindi evita scorciatoie del tipo:

“Uso Nginx + PHP-FPM, il problema non mi riguarda.”

Non è una conclusione supportata dagli advisory.

Cosa cambia in base al tipo di hosting

PHP2Shell è uno di quei casi in cui due siti WordPress apparentemente identici possono richiedere azioni molto diverse.

La differenza è chi controlla PHP.

Hosting managed

In un hosting completamente gestito, l’utente spesso non installa né aggiorna direttamente il runtime.

Qui la cosa più utile non è forzare manualmente un cambio di versione dal pannello, ma verificare:

• advisory del provider;
• pagina di stato;
• comunicazioni di sicurezza;
• conferma del supporto;
• eventuale indicazione di patch o backport già applicato.

Un provider può intervenire sull’infrastruttura prima che il cliente veda un numero di versione diverso nel pannello.

Perciò, su managed hosting, la conferma del provider può essere più significativa del semplice numero mostrato nell’interfaccia.

Se la documentazione è chiara e conferma la remediation, non ha senso applicare workaround arbitrari che potrebbero entrare in conflitto con l’ambiente gestito.

Hosting condiviso con cPanel o Plesk

Su un hosting condiviso hai spesso la possibilità di scegliere PHP da un pannello, ma non controlli realmente il sistema operativo e i pacchetti sottostanti. Per una vulnerabilità PHP di questo tipo, quindi, la versione mostrata dal pannello va letta insieme alle informazioni del provider su patch e backport.

La procedura ragionevole è:

1. controllare quale versione usa il dominio;
2. verificare se è disponibile una release corretta;
3. effettuare un backup;
4. cambiare versione se necessario;
5. verificare frontend, backend, form, checkout e funzioni critiche;
6. controllare nuovamente la versione vista dal sito.

Se il pannello non offre ancora una release corretta, chiedi al provider se il pacchetto corrente contiene un backport.

Non passare invece a una release completamente diversa senza valutare la compatibilità del sito solo perché il numero è più alto. Security update e major upgrade non sono necessariamente la stessa operazione.

VPS, server e container gestiti direttamente

Se amministri direttamente l’infrastruttura, la responsabilità è tua.

Devi verificare almeno:

• pacchetto PHP installato;
• repository da cui proviene;
• runtime associato al web server;
• servizi e pool PHP-FPM;
• immagini container;
• worker già avviati;
• eventuali versioni PHP parallele.

Dopo l’aggiornamento, effettua il reload o restart previsto dalla tua distribuzione e verifica che i processi attivi stiano effettivamente usando il codice aggiornato.

Nel caso dei container, aggiornare il Dockerfile senza ricostruire e ridistribuire l’immagine non cambia i container già in esecuzione.

Allo stesso modo, aggiornare il pacchetto sul nodo host non corregge automaticamente un’immagine PHP che incorpora una propria copia del runtime.

Qui la remediation è quindi:

sorgente corretta → build corretta → deploy corretto → runtime verificato

non semplicemente “ho lanciato il comando di aggiornamento”.

Patch, mitigazioni e controlli dopo l’aggiornamento

Una delle parti più delicate di PHP2Shell è distinguere correzione completa e riduzione temporanea del rischio. Con PHP2Shell, un workaround può ridurre uno specifico percorso di esposizione senza eliminare il difetto nel runtime.

Gli advisory ufficiali sono molto chiari: aggiornare a una release che contiene la patch è la mitigazione completa.

Le modifiche di configurazione possono eliminare uno specifico percorso già noto, ma non garantiscono di coprire tutte le condizioni possibili.

Aggiornare PHP resta la correzione principale

Se puoi aggiornare, fallo.

Le release corrette modificano il runtime per eliminare le condizioni che permettono ai due problemi di diventare sfruttabili.

Dopo l’update:

• riavvia o ricarica i worker quando necessario;
• controlla la versione nel contesto web;
• verifica i pool PHP-FPM;
• controlla che non esistano virtual host o siti rimasti su una branch diversa;
• ricostruisci eventuali immagini container;
• esegui un test funzionale dell’applicazione.

La domanda finale non è “l’aggiornamento è terminato senza errori?”, ma:

“Tutte le richieste web del sito stanno ora raggiungendo un runtime corretto?”

session.upload_progress: la mitigazione temporanea da conoscere

Il progetto PHP ha pubblicato anche un advisory informativo che suggerisce temporaneamente di impostare:

<code>session.upload_progress.enabled=0</code>

fino al successivo normale bugfix release, per ridurre un ulteriore percorso di rischio collegato alla gestione delle sessioni durante gli upload.

Questa impostazione era già indicata tra le mitigazioni dell’advisory sullo stato globale.

Due precisazioni sono importanti.

La prima: non sostituisce l’aggiornamento PHP.

La seconda: se la tua applicazione utilizza esplicitamente la funzionalità di upload progress delle sessioni PHP, disabilitarla può modificarne il comportamento. Va quindi applicata consapevolmente e, su hosting gestiti, seguendo le indicazioni del provider.

È esattamente il tipo di workaround che non dovrebbe essere copiato in <code>php.ini</code> senza sapere cosa sta facendo l’applicazione.

Un WAF può aiutare, ma non sostituisce la patch

Un Web Application Firewall può bloccare determinate richieste malevole, applicare virtual patching, rate limiting o regole specifiche.

Può quindi essere utile nel contenimento.

Ma un WAF lavora sul traffico che riesce a riconoscere e filtrare. Non modifica la gestione interna della memoria di PHP.

Per questo:

WAF = ulteriore strato di difesa

non:

WAF = PHP2Shell risolto

La distinzione è particolarmente importante quando iniziano a circolare regole di emergenza. Una regola può proteggere dal pattern di exploit conosciuto in quel momento e lasciare aperti altri percorsi dello stesso difetto.

La patch del runtime chiude il problema alla fonte.

Se sospetti che il server sia già stato attaccato

Applicare la patch risolve l’esposizione futura, ma non dimostra che il sistema non sia stato toccato in precedenza.

Allo stesso tempo, vedere una richiesta sospetta nei log non significa automaticamente che l’attacco sia riuscito.

Amazon Threat Intelligence ha dichiarato di aver osservato tentativi di sfruttamento di PHP2Shell prima della disclosure pubblica. I ricercatori stessi distinguono però i tentativi osservati dalla prova che questi avrebbero avuto successo su sistemi reali.

È una distinzione che conviene mantenere anche sul proprio server.

Cosa cercare nei log

Dopo aver corretto il runtime, verifica almeno:

• errori PHP insoliti o ripetitivi;
• errori fatali e condizioni di memoria anomale;
• richieste multipart insolite;
• picchi di richieste verso endpoint che accettano upload;
• processi PHP con comportamento inatteso;
• file nuovi o modificati senza una causa nota;
• account amministrativi non riconosciuti;
• cron job o task schedulati sconosciuti;
• connessioni di rete in uscita non spiegabili;
• modifiche sospette a <code>php.ini</code>, pool PHP-FPM o configurazione del web server.

L’assenza di anomalie non è una prova matematica di mancata compromissione, soprattutto se i log disponibili sono incompleti o poco dettagliati.

Serve però a distinguere una normale operazione di patching da un possibile incidente che richiede analisi aggiuntive.

Quando passare dalla patch all’incident response

Se trovi soltanto una versione PHP interessata, aggiornarla e verificare il runtime è una remediation.

Se trovi invece file sconosciuti, processi anomali, account creati senza autorizzazione, web shell, modifiche non spiegabili o altre evidenze di persistenza, il problema cambia natura.

Non stai più gestendo soltanto una vulnerabilità: stai gestendo una possibile compromissione.

In quel caso la priorità diventa preservare le evidenze, analizzare i log, identificare la persistenza, ruotare le credenziali pertinenti e determinare l’estensione dell’incidente.

Su WordPress, una scansione dell’installazione e dei file applicativi può essere parte di questo processo. Se emergono indicatori concreti, la nostra guida/servizio sulla rimozione malware da WordPress descrive il tipo di intervento necessario per passare dalla semplice patch alla bonifica.

Evita invece di reinstallare o cancellare immediatamente tutto appena vedi una richiesta sospetta: potresti eliminare informazioni utili a capire cosa sia realmente successo.

Conclusione

PHP2Shell richiede una risposta rapida, ma soprattutto una diagnosi corretta.

Non partire da WordPress: parti da PHP.

Prima identifica il runtime che serve realmente il sito. Poi verifica se appartiene a una release corretta o se il provider ha applicato un backport. Il modo corretto di leggere le versioni PHP vulnerabili è quindi sempre contestuale: branch, runtime web e stato della correzione devono concordare. Se amministri direttamente il server, aggiorna anche i worker e controlla che il traffico web raggiunga davvero il runtime nuovo.

Le mitigazioni temporanee e il WAF possono ridurre il rischio, ma non sostituiscono la patch.

Infine, separa sempre due problemi diversi: essere stati esposti e essere stati compromessi. Una versione vulnerabile richiede remediation; segnali concreti di intrusione richiedono invece incident response.

È questa distinzione — runtime, patch effettiva e stato del sistema — che permette di affrontare PHP2Shell senza sottovalutarlo e senza trasformare un rischio tecnico reale in allarmismo.