PHP2Shell: la falla critica di PHP che mette a rischio il tuo sito WordPress (e come aggiornare PHP)

Il 21 ottobre 2026 il team di PHP ha pubblicato un avviso che non si vede spesso: "update now", aggiorna adesso. Due vulnerabilità critiche, ribattezzate PHP2Shell, permettono a chiunque di eseguire codice sul server del tuo sito senza password e senza account. Gli attacchi sono già iniziati.

Il punto che molti non hanno capito è questo: il problema non è WordPress, né i plugin, né il tema. È PHP, il linguaggio su cui gira il sito. Quindi aggiornare WordPress dalla bacheca non serve a niente: va aggiornato il server.

In questa guida ti spiego come capire in due minuti se il tuo sito è esposto e cosa fare. In fondo trovi una sezione con i dettagli tecnici, per chi gestisce un server o vuole capire cosa succede sotto il cofano.

PHP2Shell in breve

• Cos'è: due falle in PHP, identificate come CVE-2026-109618 e CVE-2026-109619.

• Cosa permettono: di eseguire codice da remoto sul server, senza autenticazione. In pratica chi attacca può fare del tuo sito quello che vuole.

• Chi è coinvolto: tutti i siti che girano su PHP, quindi WordPress, WooCommerce, Joomla, Drupal, PrestaShop e moltissimi siti su misura, compresi quelli scritti in Laravel (come il sito di Techfly, che ho riscritto da WordPress a Laravel: anche lì sotto c'è PHP). Secondo le analisi dei ricercatori, sono vulnerabili le versioni di PHP dalla 5.4 alla 8.5.

• È già sfruttata? Sì. Amazon ha osservato un tentativo di attacco già il 17 ottobre, quattro giorni prima dell'annuncio, e dal 21 ottobre diversi gruppi di ricerca segnalano scansioni su larga scala.

• La soluzione: passare a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure a una versione della tua distribuzione Linux che contiene la correzione.

Perché riguarda anche il tuo sito (anche se è piccolo)

"Chi vuoi che attacchi proprio il mio sito?" È la frase che sento più spesso, ed è sbagliata. Questi attacchi non sono personali: sono programmi automatici che provano la stessa falla su milioni di siti, uno dopo l'altro. Non cercano te, cercano un server vulnerabile.

Una volta dentro, il tuo sito diventa uno strumento: invia spam, ospita pagine truffa, reindirizza i tuoi visitatori o sfrutta la tua reputazione su Google. Se vuoi farti un'idea di come si presenta un sito compromesso, l'ho spiegato nella guida su cosa fare se il sito è stato hackerato.

Come controllare la versione di PHP del tuo sito WordPress

Ci vogliono due minuti:

1. Entra nella bacheca di WordPress.

2. Vai su Strumenti → Salute del sito.

3. Apri la scheda Info e la sezione Server: lì trovi la versione di PHP.

Confronta il numero con questa tabella:

Se la tua versione è più bassa, non è detto che il sito sia vulnerabile. Molti hosting usano PHP fornito dalla distribuzione Linux, che applica la correzione senza cambiare il numero di versione. In questo caso l'unico modo per saperlo è chiedere al tuo hosting.

Cosa fare in base al tuo hosting

Hosting condiviso (Aruba, Netsons, Register, SiteGround e simili)

È il caso più comune. PHP lo aggiorna il provider per tutti i siti del server, ma spesso sei tu a scegliere quale ramo usare (8.1, 8.2, 8.3...).

• Cerca nel pannello di controllo la voce "Versione PHP", "Selettore PHP" o "Configurazione PHP".

• Se il tuo sito è ancora su PHP 8.1 o precedenti, passa a un ramo supportato (8.3 o 8.4 sono la scelta più sicura nel lungo periodo).

• Se non trovi informazioni, scrivi al supporto e chiedi in modo diretto: "Avete applicato le correzioni PHP del 21 ottobre 2026 per CVE-2026-109618 e CVE-2026-109619 sul server del mio sito?"

WordPress gestito

Di solito se ne occupa il provider. Controlla comunque le sue comunicazioni o il blog di stato, e verifica la versione dalla Salute del sito.

VPS o server dedicato

Qui nessuno lo fa al posto tuo. Vanno installati i pacchetti PHP aggiornati e riavviati tutti i processi PHP, altrimenti il server continua a usare il codice vecchio. Trovi i dettagli nella sezione tecnica più sotto.

Sito dietro Cloudflare

Cloudflare ha pubblicato regole del firewall per i vettori di attacco noti. Sono un aiuto, ma non sostituiscono l'aggiornamento.

Attenzione: aggiornare PHP può rompere il sito

Questo è il motivo per cui tanti siti restano su versioni vecchie: si cambia la versione di PHP e il sito mostra una pagina bianca o un errore critico. Succede quando un plugin o un tema è troppo vecchio per la nuova versione.

Per farlo senza sorprese:

1. Fai un backup completo (file e database) prima di toccare qualsiasi cosa.

2. Aggiorna WordPress, plugin e tema all'ultima versione.

3. Se puoi, prova prima su una copia del sito (molti hosting offrono un ambiente di staging).

4. Cambia la versione di PHP e controlla le pagine principali, il form di contatto e, se hai un e-commerce, il carrello e il pagamento.

5. Se qualcosa si rompe, torni alla versione precedente dal pannello e individui il plugin che dà problemi.

Se scopri che il sito si regge su plugin abbandonati e non può passare a un PHP recente, è un segnale che il sito ha bisogno di più di un aggiornamento. Ne parlo in come rinnovare un sito vecchio, lento e difficile da aggiornare.

E se il sito fosse già stato attaccato?

Aggiornare PHP chiude la porta, ma non caccia chi è già entrato. Se il tuo sito è rimasto su una versione vulnerabile dopo il 17 ottobre, controlla questi segnali:

• File PHP nuovi che non riconosci, soprattutto nella cartella wp-content/uploads.

• Utenti amministratori che non hai creato.

• Redirect strani quando apri il sito da smartphone o da Google.

• Pagine spam nei risultati di ricerca (cerca site:tuosito.it su Google).

• Email dall'hosting che segnalano invio di spam o consumo anomalo di risorse.

Se ne trovi anche uno solo, segui i passi della guida su cosa fare con un sito hackerato. E per ridurre i rischi in futuro, ho raccolto le migliori pratiche per la sicurezza su WordPress.

Per chi vuole i dettagli tecnici

Questa parte è per sviluppatori, sistemisti e curiosi. Se gestisci solo il sito dalla bacheca di WordPress, puoi saltarla.

Le due vulnerabilità

CVE-2026-109618, RCE tramite corruzione in caso di esaurimento della memoria. Quando PHP va in errore per memoria esaurita, l'esecuzione può interrompersi mentre i dati interni della richiesta sono inizializzati solo in parte. La fase di pulizia di fine richiesta tratta poi quei dati incompleti come validi. Chi attacca può provocare apposta l'esaurimento della memoria con una richiesta costruita su misura (per esempio un corpo POST molto grande o con molti campi) e sfruttare lo stato incoerente.

CVE-2026-109619, RCE tramite stato globale non ripulito. Una parte dello stato interno legato alla richiesta sopravvive dopo che la memoria che lo conteneva è stata liberata. Una richiesta successiva gestita dallo stesso processo può usare quello stato prima che l'inizializzazione normale lo azzeri. È una classica situazione da use-after-free: il processo worker che serve più richieste in sequenza diventa il veicolo dell'attacco. I percorsi confermati passano dalla funzione di session upload progress e, su PHP 8.5, dai backtrace degli errori fatali.

Gli avvisi ufficiali sono GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp. Il punteggio CVSS v4 riportato dai ricercatori è 9.2 per ciascuna.

Quali configurazioni sono a rischio

Secondo l'avviso di PHP, sono coinvolte tutte le installazioni che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto è su mod_php, per cui esiste un exploit dimostrato in cui una richiesta non autenticata fa partire l'attacco prima che venga eseguita qualsiasi riga di codice dell'applicazione. Per questo nessun plugin di sicurezza WordPress può bloccarlo: interviene troppo tardi.

PHP da riga di comando (CLI) che non serve richieste web non è il bersaglio principale, ma va aggiornato comunque insieme al resto.

Come verificare davvero cosa gira sul server

Il numero che vedi con php -v è quello della CLI, che può essere diverso da quello usato dal sito. Controlla sempre il binario che serve le pagine:

php -v

php-fpm8.3 -v # o php-fpm -v, a seconda della distribuzione

Su Debian e Ubuntu, se usi i pacchetti della distribuzione, verifica che la correzione sia stata applicata cercando i CVE nel changelog del pacchetto:

apt changelog php8.3-fpm | grep -E "CVE-2026-10961(8|9)"

Su RHEL, AlmaLinux e Rocky:

rpm -q --changelog php-fpm | grep -E "CVE-2026-10961(8|9)"

Se il numero di versione è vecchio ma il changelog contiene i due CVE, la correzione è stata "riportata" (backport) dalla distribuzione e sei a posto.

Se usi Docker, non basta riavviare il container: devi ricostruire l'immagine partendo da una base aggiornata e ridistribuirla.

Dopo l'aggiornamento: riavvia tutti i worker

Con PHP-FPM e mod_php i processi restano in memoria a lungo. Dopo l'aggiornamento dei pacchetti, riavvia il servizio (non basta un reload se il gestore dei pacchetti non l'ha fatto) e verifica che non ci siano processi avviati prima dell'aggiornamento:

sudo systemctl restart php8.3-fpm

ps -o pid,lstart,cmd -C php-fpm8.3

Qualys ha segnalato casi in cui la CLI risultava aggiornata ma il worker PHP-FPM no: controlla entrambi.

Se non puoi aggiornare subito: mitigazioni temporanee

L'avviso ufficiale è chiaro: solo l'aggiornamento risolve il problema. Queste misure riducono l'esposizione a percorsi di attacco specifici ma non rendono sicura l'installazione:

• Per CVE-2026-109619: imposta session.upload_progress.enabled=0 in php.ini, nel pool FPM o nella configurazione del server, e riavvia ogni worker. Non usare ini_set() o il file .user.ini: vengono letti troppo tardi. Su PHP 8.5 imposta anche fatal_error_backtraces=0.

• Per CVE-2026-109618: l'avviso suggerisce memory_limit=-1 in modo che l'applicazione non possa sovrascriverlo (per esempio con php_admin_value nel pool FPM), un post_max_size basso (8M se non servono upload, 32M se servono), e limiti sul web server o sul proxy per dimensione delle richieste, numero di campi e di parti multipart, header e profondità di annidamento. È una scelta da valutare con attenzione, perché togliere il limite di memoria sposta il controllo a livello di container o cgroup.

• Firewall applicativo: le regole WAF pubblicate da Cloudflare e da altri vendor per i vettori noti aiutano a guadagnare tempo.

C'è anche una terza falla, CVE-2026-115560, per cui non esiste ancora una correzione. Secondo PHP è sfruttabile solo con una combinazione insolita: l'applicazione deve impostare session.serialize_handler su php_binary o php_serialize e poi cambiarlo in php a runtime con ini_set() prima di session_start(), con l'upload progress ancora attivo. La stessa impostazione session.upload_progress.enabled=0 la neutralizza. La correzione completa arriverà con il prossimo rilascio regolare.

PHP 8.1 e versioni più vecchie

PHP 8.1 e precedenti non ricevono più aggiornamenti ufficiali. Data la gravità, il team di PHP ha pubblicato patch minime solo in forma di codice sorgente per 7.4, 8.0 e 8.1, utili a chi compila PHP da sé. Alcune distribuzioni e vendor con supporto esteso offrono correzioni riportate. Per tutti gli altri, la strada è passare a un ramo supportato. E ricorda che anche PHP 8.2 esce dal supporto il 31 dicembre 2026: se devi comunque migrare, conviene andare direttamente su 8.3 o 8.4.

Cosa cercare nei log dopo il 17 ottobre

Se il server è rimasto vulnerabile, oltre ai controlli lato WordPress visti sopra:

• processi figli anomali generati dai worker PHP (shell, curl, wget, interpreti);

• richieste POST molto grandi o con un numero insolito di campi o parti multipart, soprattutto su URL che normalmente non le ricevono;

• errori "Allowed memory size exhausted" concentrati nel tempo, che possono indicare tentativi sulla prima falla;

• connessioni in uscita verso indirizzi sconosciuti dal server web;

• file modificati di recente fuori dagli aggiornamenti: find /var/www -name "*.php" -newermt 2026-10-17.

Gli exploit pubblici che circolano su GitHub non servono per questa verifica, e alcuni repository di "proof of concept" su vulnerabilità famose contengono a loro volta malware. Per i controlli usa le fonti ufficiali di PHP, della tua distribuzione e dei vendor di sicurezza.

Domande frequenti

Devo aggiornare WordPress per proteggermi da PHP2Shell?

No. WordPress.org ha precisato che non serve nessun aggiornamento di WordPress. La falla è in PHP, quindi va aggiornato PHP sul server. Tenere aggiornati WordPress e plugin resta comunque importante, anche perché un sito aggiornato regge meglio il passaggio a un PHP più recente.

Come faccio a sapere quale versione di PHP usa il mio sito?

Dalla bacheca di WordPress vai su Strumenti, poi Salute del sito, scheda Info e sezione Server. Puoi vedere la stessa informazione anche nel pannello di controllo del tuo hosting.

La mia versione di PHP è più bassa di quelle indicate: sono vulnerabile?

Non per forza. Molte distribuzioni Linux applicano la correzione senza cambiare il numero di versione. Chiedi al tuo hosting se ha applicato le correzioni del 21 ottobre 2026 per CVE-2026-109618 e CVE-2026-109619.

Un plugin di sicurezza come Wordfence mi protegge?

Non da questa falla. Su alcune configurazioni l'attacco parte prima che WordPress e i suoi plugin vengano caricati. I firewall a livello di server o di rete, come quello di Cloudflare, possono aiutare, ma la vera soluzione è aggiornare PHP.

Aggiornare PHP può rompere il mio sito?

Sì, se un plugin o il tema sono troppo vecchi per la nuova versione. Per questo prima di cambiare versione conviene fare un backup completo, aggiornare plugin e tema e, se possibile, provare su una copia del sito.

Vuoi che controlli io il tuo sito?

Mi occupo di siti web e di sicurezza, compresi test di penetrazione: so come ragiona chi attacca perché faccio lo stesso lavoro, ma per conto di chi deve difendersi. Se non sai che versione di PHP usa il tuo sito, se hai paura che l'aggiornamento rompa qualcosa o se vuoi sapere se qualcuno è già entrato, contattami. Controllo versione, configurazione e segnali di compromissione e ti dico cosa va fatto, senza giri di parole.

Se la tua azienda lavora con clienti soggetti alla NIS2, un controllo documentato come questo è anche una delle prove che ti verranno chieste: ne ho parlato in NIS2 e la scadenza del 31 ottobre. Trovi tutti i dettagli sul servizio nella pagina dedicata al penetration testing per siti web.