PHP2Shell: cosa fare subito se il sito usa WordPress

PHP2Shell è una coppia di vulnerabilità critiche nel PHP stesso, rese pubbliche il 21 ottobre 2026 e valutate 9,2 sulla scala CVSS. Su un runtime PHP non aggiornato, un attaccante senza account può eseguire codice sul server o leggere la memoria che contiene password, token di sessione e chiavi API. I ricercatori lo hanno dimostrato su installazioni WordPress recenti. Aggiornare WordPress, il tema o i plugin non risolve il problema: va aggiornata la versione di PHP su cui gira il sito.

Questa guida spiega cos'è PHP2Shell, come verificare se il sito è colpito, cosa chiedere all'hosting e cosa fare se l'aggiornamento non è possibile in giornata.

Cos'è PHP2Shell

La ricerca di Wiz Research, OpenAI Codex Security e Calif ha individuato due classi collegate di bug di sicurezza della memoria nel motore di PHP:

• CVE-2026-109618, corruzione per esaurimento della memoria. Il modo in cui PHP gestisce l'esaurimento della memoria può corromperne lo stato. Un attaccante può sfruttarlo per eseguire codice come worker web di PHP, senza effettuare l'accesso.
• CVE-2026-109619, stato globale residuo tra una richiesta e l'altra. I dati di una richiesta possono sopravvivere fino alla successiva. Ne deriva un use-after-free che può far trapelare la memoria del worker o consentire l'esecuzione di codice.

Poiché la falla è in PHP, non serve che il codice del sito contenga un bug. Secondo i ricercatori, anche una pagina «Hello World» su una versione di PHP vulnerabile può essere esposta. WordPress, Drupal e Joomla sono stati semplicemente le applicazioni usate per dimostrare l'esecuzione di codice remoto senza autenticazione. Il team di PHP ha pubblicato le versioni corrette lo stesso giorno.

Per un sito WordPress contano soprattutto due conseguenze:

1. Presa di controllo del server. Eseguire codice come worker PHP di solito significa che l'attaccante può modificare file, aggiungere un amministratore, installare una backdoor o raggiungere il database.
2. Furto di dati silenzioso. La lettura della memoria funziona senza eseguire codice malevolo, quindi può lasciare poche tracce. La memoria di un worker PHP molto sollecitato può contenere password e cookie di altri visitatori, la password del database e chiavi API.

Il mio sito è colpito?

Quasi certamente, a meno che PHP non sia stato aggiornato il 21 ottobre 2026 o dopo. I ricercatori hanno trovato versioni vulnerabili fino a PHP 5.4. Queste sono le prime versioni corrette per ciascun ramo supportato:

PHP 8.1, 8.0 e tutte le versioni 7.x non sono più supportate dal progetto PHP e non compaiono nella tabella. Se il sito usa una di queste, non esiste una versione corretta da installare: occorre passare a un ramo supportato.

Per vedere la versione esatta in WordPress, aprire Strumenti → Salute del sito → Informazioni ed espandere Server. La riga «Versione PHP» mostra il numero completo, per esempio 8.3.36. Le prime due parti (8.3) non bastano: conta l'ultimo numero.

Come risolvere

L'unica soluzione completa è un runtime PHP aggiornato, seguito da un riavvio.

1. Aggiornare PHP su ogni runtime. Sul proprio server, installare i pacchetti aggiornati della distribuzione appena vengono pubblicati, oppure la release ufficiale da php.net. Con un hosting gestito o condiviso è il provider ad aggiornare PHP: conviene chiedere direttamente se il proprio piano usa già la versione corretta.
2. Riavviare PHP. Un nuovo pacchetto PHP non ha alcun effetto finché i processi in esecuzione non vengono sostituiti. Riavviare PHP-FPM, Apache con mod_php ed eventuali worker PHP sempre attivi.
3. Verificare il risultato. Ricontrollare Salute del sito. La versione di PHP deve ora essere pari o superiore alla versione corretta del proprio ramo.
4. Non dimenticare gli altri runtime. Siti di staging, una seconda versione di PHP selezionata nel pannello dell'hosting, il PHP usato per i cron job e per WP-CLI e le immagini dei container contano tutti.

Se il pannello dell'hosting offre un selettore della versione PHP, scegliere «8.3» o «8.4» è sicuro solo se il provider ha già installato la build corretta dietro quell'etichetta. Salute del sito dice come stanno davvero le cose.

Se non si può aggiornare oggi

I ricercatori elencano misure temporanee. Ognuna blocca alcuni percorsi d'attacco, nessuna li blocca tutti e alcune possono avere effetti sul sito, quindi vanno prima testate:

• fatal_error_backtraces = 0, se la versione di PHP lo supporta.
• Abbassare post_max_size e max_input_nesting_level quanto lo consentono moduli e upload, e impostare session.upload_progress.enabled = 0 se nulla usa l'avanzamento degli upload.
• Riciclare più spesso i worker PHP-FPM con un valore più basso di pm.max_requests (a scapito delle prestazioni).
• memory_limit = -1 elimina il percorso del limite di memoria su cui si basano alcuni attacchi, ma lascia l'esaurimento della memoria al sistema operativo. Va usato solo insieme a un limite a livello di sistema operativo come memory.max di cgroup v2, e non va mai sostituito con RLIMIT_AS o RLIMIT_DATA, che secondo l'avviso di sicurezza di PHP possono innescare lo stesso bug.

Nascondere gli errori di PHP (display_errors, error_reporting o @) non rientra tra queste misure: secondo il progetto PHP non serve.

I fornitori di firewall e CDN hanno pubblicato regole per PHP2Shell. Possono ridurre l'esposizione, ma i ricercatori sono chiari: una regola di protezione non sostituisce l'aggiornamento di PHP.

Segnali da tenere d'occhio

Nessuna singola riga di log dimostra un attacco. I ricercatori indicano segnali che meritano un approfondimento: cookie PHPSESSID insolitamente grandi o malformati nelle risposte, strane richieste multipart seguite da errori di limite di memoria o da raffiche di risposte HTTP 500, e worker PHP che vanno in crash o si riavviano senza motivo. La loro assenza non dimostra che il sito sia pulito, perché la lettura della memoria può non lasciare nulla nei log di WordPress.

Se compaiono questi segnali, la situazione va trattata come un possibile incidente. La nostra guida ai segnali di un sito WordPress hackerato aiuta nei primi controlli. Poiché la memoria trapelata può contenere segreti, dopo l'aggiornamento conviene cambiare la password del database, le chiavi e i salt in wp-config.php e tutte le chiavi API. Se possono essere stati esposti dati personali, parte il conto alla rovescia del GDPR: si veda la nostra guida alla notifica del data breach in 72 ore.

Da dove iniziare

1. Aprire Strumenti → Salute del sito → Informazioni → Server e annotare la versione esatta di PHP di ogni sito gestito.
2. Confrontarla con la tabella sopra. Tutto ciò che è inferiore alla versione corretta, o su PHP 8.1 o precedente, richiede un intervento oggi stesso.
3. Aggiornare PHP o chiedere all'hosting la versione corretta, poi assicurarsi che PHP-FPM o Apache vengano riavviati.
4. Ricontrollare Salute del sito e conservare lo screenshot come prova della correzione.
5. Esaminare i log alla ricerca dei segnali descritti sopra e rinnovare i segreti se qualcosa non torna.

Fonti: php2shell.com, annuncio della PHP Foundation, Wiz Research.