PHP2Shell, la vulnerabilità critica di PHP: cosa rischia il tuo sito e cosa fare subito

Da qualche giorno non si parla d'altro: siti di notizie, newsletter tecniche, avvisi delle agenzie per la sicurezza informatica di mezzo mondo. Il nome scelto dai ricercatori, PHP2Shell, dice già il problema: da una richiesta web si arriva a una «shell», cioè alla possibilità di far eseguire comandi al server. E PHP non è un programma di nicchia: fa girare WordPress, Joomla, Drupal, PrestaShop, Magento, Moodle, la maggior parte dei gestionali scritti su misura e una quota enorme dei siti di piccole e medie imprese.

Qui mettiamo in fila quello che è certo, separandolo da quello che ancora non lo è, e soprattutto le cose da fare: capire che versione di PHP usa il tuo sito, a chi chiedere l'aggiornamento, come farlo su un server tuo e cosa controllare se il sito è rimasto scoperto per qualche giorno. Le versioni e le date le abbiamo verificate sul registro delle modifiche ufficiale di PHP e sugli avvisi di sicurezza delle distribuzioni Linux.

Cos'è PHP2Shell, in parole semplici

Ogni volta che qualcuno apre una pagina del tuo sito, il server avvia (o riprende) un processo PHP che legge la richiesta, prepara la pagina e poi fa pulizia, così da essere pronto per la richiesta successiva. PHP2Shell nasce proprio in questa fase di pulizia, in due modi diversi.

• CVE-2026-109618: quando PHP esaurisce la memoria mentre sta ancora preparando i dati di una richiesta, si interrompe a metà lavoro. Il riordino che segue tratta quei dati incompleti come se fossero validi.
• CVE-2026-109619: alcune informazioni legate a una richiesta sopravvivono alla liberazione della memoria che le conteneva. Se lo stesso processo serve una richiesta successiva, può usarle prima che vengano azzerate: è quello che i programmatori chiamano use-after-free.

In entrambi i casi chi attacca, con richieste costruite apposta, riesce a mettere le mani sulla memoria del processo e da lì a fargli eseguire istruzioni sue. Non serve un account, non serve un modulo di accesso, non serve nemmeno che il sito abbia una pagina vulnerabile: il punto debole è PHP stesso, prima ancora che parta il codice di WordPress o del gestionale. Una delle strade dimostrate passa per il caricamento con barra di avanzamento delle sessioni (session upload progress), una funzione poco usata ma accesa per impostazione predefinita.

La correzione ufficiale, firmata da cinque sviluppatori del progetto, cambia il modo in cui PHP reagisce all'esaurimento della memoria e azzera correttamente una serie di variabili interne all'inizio di ogni richiesta. Il registro ufficiale delle modifiche la riassume così: «Avoid state corruption via bailout», evitare che lo stato interno si corrompa quando PHP si interrompe di colpo.

Cosa è successo, giorno per giorno

La storia è stata movimentata: la notizia è uscita prima del previsto, i primi tentativi di attacco sono arrivati ancora prima e alcune notizie allarmanti dei primi giorni sono state poi ritirate. Ecco i passaggi confermati.

1. Agosto 2026I difetti vengono trovati, in modo indipendente, dalla società di sicurezza Calif e dai ricercatori di Wiz, e segnalati in privato al team di sicurezza di PHP. Le ricostruzioni sulle date esatte non coincidono del tutto.
2. 17 ottobreLe trappole di Amazon (MadPot) registrano un tentativo di sfruttamento quattro giorni prima della comunicazione pubblica.
3. 20 ottobreLa notizia trapela. Il progetto PHP annuncia un rilascio di sicurezza critico e lo anticipa.
4. 21 ottobreEscono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Ubuntu pubblica lo stesso giorno i pacchetti corretti, la CISA statunitense chiede di aggiornare subito e i fornitori di hosting iniziano la distribuzione.
5. 22-24 ottobreCircolano script di attacco pubblici e partono scansioni di massa. Il 24 ottobre, su un server trappola con Apache, mod_php e PHP 8.4.26, quindi una versione non aggiornata, gli attaccanti riescono a eseguire comandi. Intanto Palo Alto Networks e Sophos ritirano le prime segnalazioni di attacchi riusciti contro enti reali.
6. 26 ottobreNessuna compromissione su larga scala confermata, ma lo sfruttamento è passato dai tentativi ai comandi eseguiti. È il momento in cui chi non ha aggiornato rischia di più.

Chi rischia davvero

È vulnerabile ogni server che risponde a richieste web con una versione di PHP senza la correzione, in qualunque modalità. Il rischio però non è uguale per tutte: secondo il team di sicurezza di PHP la situazione più pericolosa è quella del modulo di Apache, mentre con PHP-FPM lo sfruttamento richiede condizioni in più.

In pratica riguarda quasi tutti i siti WordPress, gli e-commerce in PrestaShop, WooCommerce o Magento, le piattaforme di formazione in Moodle e i portali o gestionali scritti su misura in PHP. Wiz ha parlato del «70% di Internet» perché tanti sono i siti che usano PHP; l'unità di ricerca Unit 42 di Palo Alto Networks ha stimato oltre 22 milioni di installazioni esposte. Restano fuori i siti statici, quelli fatti solo di pagine HTML, che sul server non eseguono PHP.

Le versioni di PHP corrette

Il progetto PHP ha corretto i quattro rami ancora supportati. Se il tuo server usa uno di questi, la versione da raggiungere è quella della seconda colonna, o una successiva:

Fonte: registro delle modifiche di PHP (voce «Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp») e tabella delle versioni supportate su php.net. La 8.3.35 e le altre versioni precedenti non bastano.

Attenzione ai numeri di versione delle distribuzioni

Ubuntu, Debian, Red Hat e le altre distribuzioni Linux non inseguono le versioni di PHP: prendono la correzione e la applicano alla versione che già distribuiscono. Per questo un server aggiornato può continuare a mostrare un numero «vecchio». Un esempio vero: su Ubuntu 24.04 LTS la correzione è nel pacchetto 8.3.6-0ubuntu0.24.04.13, e php -v continua a dire 8.3.6. Su Ubuntu 22.04 il pacchetto corretto è 8.1.2-1ubuntu2.28, che è un PHP 8.1 con la correzione, anche se il progetto PHP non ne ha fatta una per quel ramo.

La regola quindi è semplice: su un server con i pacchetti della distribuzione non conta la cifra dopo l'8.x, conta che il pacchetto installato sia quello indicato nell'avviso di sicurezza della tua distribuzione. Più avanti trovi il comando per controllarlo.

Come controllare la versione del tuo sito

Ci sono tre modi, dal più semplice al più preciso. Il primo è alla portata di chiunque abbia un sito WordPress.

# quali servizi PHP-FPM sono attivi
systemctl list-units 'php*-fpm.service'

# versione installata e versione disponibile del pacchetto (esempio per PHP 8.3)
apt policy php8.3-fpm

# la correzione è nel pacchetto installato? (stampa la riga se c'è)
apt changelog php8.3-fpm | grep -m 2 CVE-2026-109618

Hosting condiviso: cosa chiedere al fornitore

Su un hosting condiviso PHP non lo installi tu e non puoi aggiornarlo: lo fa il fornitore su tutti i server, e spesso non puoi nemmeno toccare la configurazione di PHP (su OVHcloud, per esempio, il php.ini è comune a tutta l'infrastruttura). I fornitori seri si sono mossi subito. OVHcloud, per esempio, ha aperto sul suo forum ufficiale un avviso dedicato ai correttivi sugli hosting web: secondo l'avviso e le cronache dei giorni successivi, le versioni corrette sono state distribuite sui cluster dal 21 ottobre, i rami più vecchi sono seguiti nei giorni dopo e intanto sono state attivate regole di filtraggio. Anche CloudLinux, Plesk e molti fornitori italiani hanno pubblicato i loro avvisi.

Quello che puoi fare tu è verificare, senza dare niente per scontato:

1. Controlla la versione con la Salute del sito e annotala con la modalità (SAPI).
2. Cerca l'avviso del tuo fornitore: pagina di stato, blog, forum o area clienti. Deve citare CVE-2026-109618 e CVE-2026-109619.
3. Se l'avviso non c'è o non parla della tua versione, scrivi all'assistenza con il messaggio qui sotto.
4. Se usi PHP 8.1 o una versione più vecchia, chiedi esplicitamente se per quella versione esiste una correzione. Se non esiste, il passaggio a una versione supportata non è più rimandabile (ne parliamo più avanti).

Una nota per chi su OVHcloud cambia versione da sé: la versione si sceglie dallo Spazio Cliente o modificando il file .ovhconfig, e i due modi sono equivalenti. Se nello spazio ci sono più file .ovhconfig, per esempio lasciati da vecchie installazioni in sottocartelle, conta quello nella cartella principale: la guida ufficiale di OVHcloud lo spiega nel dettaglio.

VPS e server dedicati: aggiornare passo per passo

Se il server è tuo, l'aggiornamento è tuo. Sono pochi comandi, ma l'ordine conta: prima la copia, poi l'aggiornamento, poi il riavvio, poi la verifica.

sudo apt update
sudo apt upgrade

sudo dnf upgrade --refresh 'php*'

docker compose build --pull
docker compose up -d

# PHP-FPM su Ubuntu e Debian (un comando per ogni versione installata)
sudo systemctl restart php8.3-fpm

# Apache con mod_php
sudo systemctl restart apache2

# AlmaLinux, Rocky Linux, Red Hat
sudo systemctl restart php-fpm httpd

Le misure temporanee e i loro limiti

Se per qualche ora o qualche giorno non puoi aggiornare, ci sono contromisure che riducono il rischio. Nessuna lo azzera, e il team di PHP lo dice chiaramente: l'unica soluzione completa è l'aggiornamento.

• Spegnere il caricamento con barra di avanzamento delle sessioni. Nel php.ini del server (su Ubuntu e Debian, per PHP-FPM, in /etc/php/8.3/fpm/php.ini) si imposta session.upload_progress.enabled = Off e si riavvia PHP. Chiude una delle strade note, non tutte: secondo un ricercatore l'altro difetto passa dall'elaborazione dei moduli con file allegati, qualunque sia questa impostazione. Su un hosting condiviso di solito non si può fare.
• Firewall applicativo (WAF). Cloudflare, AWS e diversi fornitori di hosting hanno pubblicato regole che bloccano le richieste di attacco conosciute. Aiutano contro gli script che girano oggi, ma una variante nuova può passare.
• Limitare la dimensione delle richieste. Abbassare il limite del server web (client_max_body_size su Nginx, LimitRequestBody su Apache) e di PHP (post_max_size) rende più difficile provocare l'esaurimento della memoria. Va tarato sui caricamenti che il sito deve accettare.
• Isolare i servizi che non servono al pubblico. Pannelli di amministrazione, ambienti di prova e vecchi sottodomini dimenticati con PHP vanno chiusi o protetti con una password del server web finché non sono aggiornati.

Il sito gira su una versione vecchia di PHP?

Qui sta il problema vero per molte aziende. Se il tuo sito, il tuo e-commerce o il gestionale aziendale gira ancora su PHP 7.4, 8.0 o 8.1, per quei rami il progetto PHP non ha pubblicato versioni corrette, al massimo correzioni da applicare e compilare a mano: arrivano già pronte solo da alcune distribuzioni Linux, a volte con abbonamenti di supporto esteso, e da alcuni fornitori di hosting, non da tutti. Con PHP 7.3 o più vecchio le probabilità di trovarne una sono ancora più basse.

La tentazione è cambiare versione dal pannello e via. Su un sito che non è stato aggiornato per anni, è il modo più rapido per ritrovarsi con una pagina bianca o un «errore critico». Tra una versione e l'altra PHP toglie funzioni e diventa più severo. Qualche esempio concreto:

• con PHP 7.0 sono sparite le vecchie funzioni mysql_* per il database, ancora presenti in molti portali e gestionali scritti su misura;
• con PHP 8.0 sono state tolte each() e create_function(), usate da temi e plugin datati, e molti avvisi sono diventati errori che fermano la pagina;
• con PHP 8.2 le proprietà create al volo negli oggetti sono deprecate e riempiono i log di avvisi, segno che il codice va rivisto prima del passo successivo.

Per questo il passaggio va fatto con metodo, meglio se da un webmaster professionista che conosce sia PHP sia la piattaforma del sito:

1. Copia completa di file e database, e una copia di prova del sito (staging) su cui lavorare senza toccare quello vero.
2. Inventario di versione di WordPress o del CMS, tema, plugin ed eventuale codice su misura, con l'ultima data di aggiornamento di ognuno.
3. Analisi della compatibilità del codice con la versione di PHP di arrivo, con strumenti automatici e a mano dove serve.
4. Aggiornamento e correzioni sulla copia di prova: CMS, plugin e tema prima, poi PHP, poi la correzione di quello che si rompe, leggendo il registro degli errori.
5. Prove delle funzioni che contano: moduli, carrello, pagamenti, area riservata, esportazioni del gestionale.
6. Passaggio in produzione in un orario tranquillo, con la copia pronta per tornare indietro, e controllo dei log nei giorni successivi.

Se il sito è rimasto scoperto: cosa controllare

Aggiornare chiude la porta, ma non dice se qualcuno è già passato. Se il tuo server ha usato una versione senza correzione dopo il 21 ottobre, e a maggior ragione se usa mod_php, vale la pena di dare un'occhiata. Non esiste ancora un elenco affidabile di tracce lasciate da chi sfrutta PHP2Shell, quindi si guardano i segnali classici di un'intrusione:

• file PHP comparsi di recente dove non dovrebbero esserci, soprattutto nella cartella dei caricamenti (wp-content/uploads su WordPress) o con nomi che imitano quelli di sistema;
• utenti amministratori che non riconosci, password cambiate, plugin installati da nessuno di voi;
• operazioni pianificate nuove (crontab dell'utente del sito, cron di WordPress) e processi con nomi strani che consumano processore;
• redirect verso altri siti, pagine di spam indicizzate su Google, avvisi di sicurezza in Search Console o email rifiutate perché il server finisce nelle liste nere;
• nei log del server web, molte richieste dallo stesso indirizzo con caricamenti di file verso pagine qualsiasi, seguite da errori di memoria esaurita nel registro di PHP.

Se trovi qualcosa, non limitarti a cancellare il file: chi entra lascia di solito più di una porta aperta. La procedura completa, dalla copia delle prove al ripristino, è nella nostra guida al sito WordPress hackerato; se i visitatori finiscono su altri siti, leggi anche quella sul sito che reindirizza ad altro sito. E se il server è un VPS, è l'occasione per rivedere firewall e accessi.

Trovata con l'aiuto dell'intelligenza artificiale

PHP2Shell ha anche un lato curioso: è stata trovata con l'aiuto dell'intelligenza artificiale. Calif ha raccontato di averla individuata durante un'analisi del codice fatta con un modello di OpenAI, e Wiz ha intitolato il suo rapporto proprio sull'AI che scopre il difetto. Non è un dettaglio da addetti ai lavori. Se gli strumenti automatici trovano più in fretta i difetti nascosti da anni, li troveranno anche chi attacca: il tempo tra l'annuncio e i primi attacchi, qui di pochi giorni (e qualcuno ci ha provato ancora prima), è destinato ad accorciarsi.

La conseguenza pratica per chi ha un sito è una sola: gli aggiornamenti del server non possono più aspettare la manutenzione di fine mese. Serve qualcuno, il fornitore di hosting o il tecnico di fiducia, che li applichi entro pochi giorni e lo confermi. Se non sai chi se ne occupa sul tuo sito, oggi è un buon giorno per scoprirlo. Per capire quale soluzione ti lascia più controllo, leggi il nostro confronto tra hosting condiviso e VPS. Le altre novità sull'intelligenza artificiale le trovi nella nostra sezione AI.

Conclusioni

PHP2Shell è grave per tre motivi insieme: colpisce il motore di quasi tutti i siti dinamici, non chiede password e dal 24 ottobre ha già prodotto comandi eseguiti su server trappola. La buona notizia è che la correzione esiste dal 21 ottobre ed è un normale aggiornamento di manutenzione, che non cambia il funzionamento dei siti. Su un hosting condiviso basta farsi confermare dal fornitore che l'ha installata; su un VPS bastano pochi comandi e un riavvio.

Il caso difficile è quello dei siti fermi su versioni di PHP vecchie, per cui la correzione ufficiale non c'è. Lì l'aggiornamento non si improvvisa: va preparato su una copia, con le correzioni al codice che servono, e fatto da chi sa rimettere le mani sul sito se qualcosa si rompe. Rimandarlo però ora costa di più che farlo.

PHP è un marchio del PHP Group; Ubuntu è un marchio di Canonical; OVHcloud, Cloudflare, Amazon Web Services, Wiz, Palo Alto Networks e gli altri nomi citati appartengono ai rispettivi titolari. Questa guida è indipendente e non usa loghi di terzi. Le informazioni sugli attacchi sono aggiornate al 26 ottobre 2026: se la situazione cambia, aggiorneremo la pagina.