Come correggere la falla PHP2Shell su un piccolo sito: la guida per freelance e piccoli negozi online

Prefetture e grandi gruppi hanno interi team per gestire la falla PHP2Shell. Tu, forse, no. Eppure un negozio WooCommerce con trenta clienti abituali, il sito vetrina di un artigiano o l’applicazione fatta in casa di uno sviluppatore freelance sono esposti esattamente allo stesso modo. Le due vulnerabilità corrette il 21 ottobre 2026 (CVE-2026-109618 e CVE-2026-109619) stanno dentro PHP: per loro un ministero e un fioraio sono la stessa cosa. Questa guida spiega passo dopo passo come capire se il tuo sito è già aggiornato, come aggiornare PHP in base al tipo di hosting, cosa fare se non puoi farlo subito e come verificare che nessun intruso sia passato prima della patch.

Se prima vuoi capire cos’è questa falla e perché tanti siti sono stati spenti, leggi il nostro articolo PHP2Shell: la falla di PHP che ha costretto ministeri ed enti pubblici a spegnere i siti.

Questa guida è pensata per:

• chi ha un piccolo sito WordPress, WooCommerce, PrestaShop, Joomla o Drupal;
• gli sviluppatori freelance che gestiscono i siti dei propri clienti;
• le piccole agenzie e le associazioni che hanno una VPS o un hosting condiviso.

Cosa ti serve: l’accesso all’area clienti del tuo hosting, oppure un accesso SSH se gestisci il server, e un backup recente. Metti in conto da un quarto d’ora (hosting condiviso già aggiornato) a due ore (VPS con più siti, o una versione di PHP datata).

Cosa tenere a mente prima di cominciare

Tre concetti da avere ben chiari, perché evitano la maggior parte degli errori che si vedono in giro in questi giorni.

1. Aggiornare WordPress, PrestaShop, temi o plugin non corregge PHP2Shell. WordPress.org l’ha confermato: per questo problema non è previsto alcun aggiornamento del core.
2. Le versioni sicure sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 (o successive). Il progetto PHP è categorico: nessuna impostazione sostituisce l’aggiornamento.
3. Un plugin di “modalità manutenzione” per WordPress non ti protegge. Funziona a sua volta in PHP, quindi la richiesta dell’attaccante arriva comunque a PHP, e con mod_php l’attacco può scattare prima ancora che il codice del sito venga eseguito. Ci torniamo al passo 6.

Passo 1: capire chi gestisce PHP sul tuo sito

È la domanda da cui dipende tutto il resto. Su un hosting condiviso non sei tu a installare PHP. Su una VPS nessuno lo farà al posto tuo.

Se non sai in quale casella rientri, guarda la fattura: un abbonamento “web hosting” da pochi euro al mese è quasi sempre un condiviso. Se un giorno hai ricevuto un indirizzo IP con un utente root, hai un server da gestire.

Passo 2: controllare la versione di PHP effettivamente in uso

La trappola numero uno è guardare il PHP sbagliato. Su un server spesso convivono più PHP: quello della riga di comando e quello che serve davvero le pagine (PHP-FPM o il modulo di Apache). Non sempre hanno la stessa versione.

Dall’interfaccia del sito

• WordPress: Strumenti, poi Salute del sito, scheda Info, sezione Server. La riga “Versione PHP” indica la versione usata dal sito.
• PrestaShop: Parametri avanzati, poi Informazioni, sezione “Informazioni sul server”.
• Joomla: Sistema, poi Informazioni di sistema.
• Drupal: Rapporti, poi Rapporto di stato.

Con un file phpinfo temporaneo

È il metodo più affidabile, perché mostra il PHP che esegue davvero le pagine. Crea nella root del sito un file con un nome difficile da indovinare, per esempio verif-7f3k2.php, con questo contenuto:

<?php phpinfo();

Aprilo nel browser, annota la versione mostrata in cima alla pagina e la riga “Server API” (FPM/FastCGI, Apache 2.0 Handler, LiteSpeed…), poi cancella subito il file. Un phpinfo dimenticato online regala parecchie informazioni a un attaccante.

Da riga di comando (VPS)

# Versione di PHP da riga di comando
php -v

# Versione di PHP-FPM (adatta il numero del ramo)
php-fpm8.3 -v

# Debian / Ubuntu: versioni esatte dei pacchetti installati
dpkg -l | grep -E 'php[0-9.]+-(fpm|cli|common)|libapache2-mod-php'

Il caso particolare di Ubuntu e Debian

Qui il numero di versione può ingannare. Ubuntu integra le patch di sicurezza senza cambiare la versione principale: un Ubuntu 24.04 aggiornato mostra sempre PHP 8.3.6. Quello che conta è il numero del pacchetto. Secondo l’avviso USN-8948-1 pubblicato il 21 ottobre, tra le versioni corrette ci sono:

Per Debian 12 (bookworm), al momento delle nostre verifiche non era ancora uscito nessun avviso per php8.2: tieni d’occhio il security tracker di Debian, oppure passa al repository sury.org (vedi passo 4).

Un consiglio utile: per verificare che un pacchetto contenga davvero la correzione, cerca gli identificativi CVE nel suo changelog.

apt changelog php8.3-common | grep -m3 CVE-2026-10961

Passo 3: fare un backup prima di toccare qualsiasi cosa

Un aggiornamento di PHP all’interno dello stesso ramo (da 8.3.35 a 8.3.36, per esempio) rompe un sito molto di rado. Un cambio di ramo (da 8.1 a 8.3) può invece mandare in tilt un vecchio plugin o un modulo di pagamento. In entrambi i casi fai un backup di:

• file del sito (come minimo wp-content per WordPress, oppure l’intera cartella);
• database (esportazione da phpMyAdmin, o mysqldump via SSH);
• su una VPS, configurazione di PHP (/etc/php/) e del web server.

Quasi tutti gli hosting condivisi offrono backup automatici. Controlla che ce ne sia uno anteriore al 17 ottobre: ti servirà anche se più avanti dovessi scoprire un’intrusione.

Prendi anche l’abitudine di tenere una copia a casa, su un supporto da scollegare dopo l’uso. Un backup che resta collegato al server può essere cancellato o cifrato dalla stessa persona che l’ha compromesso. Un piccolo SSD esterno va benissimo per i file e per l’export del database.

Samsung T7 SSD esterno 1 TB

SSD tascabile veloce e robusto per tenere a casa una copia offline di file e database dei tuoi siti. Scollegato, è fuori dalla portata di un attaccante.

• AmazonVedi su Amazon

Passo 4: aggiornare PHP in base al tuo caso

Su un hosting condiviso (cPanel, Plesk, pannello proprietario)

Non hai il controllo sui binari di PHP, ma hai due leve.

La prima è verificare che il provider abbia davvero applicato la patch. Consulta la sua pagina di stato o le sue email. Non accontentarti di un generico “i nostri clienti sono protetti”: Clubic ha constatato presso o2switch, diverse ore dopo l’uscita della patch, che erano attive protezioni provvisorie mentre i binari installati erano ancora 8.3.35 e 8.4.26. Non è per forza una colpa, ma è una sfumatura importante. Protetto da un filtro non vuol dire aggiornato.

Nel dubbio, apri un ticket chiaro. Per esempio:

Buongiorno, potreste confermarmi che le versioni di PHP usate dal mio hosting per il dominio [nome dominio] includono la patch di sicurezza del 21 ottobre 2026 (CVE-2026-109618 e CVE-2026-109619), cioè PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o un pacchetto equivalente con la correzione portata all’indietro? Se non è ancora così, entro quando è previsto l’aggiornamento? Grazie mille.

La seconda leva è scegliere una versione supportata. In cPanel (“Selettore versione PHP” o “MultiPHP Manager”), in Plesk o nell’area clienti OVHcloud di solito puoi cambiare la versione di PHP del sito. Se sei ancora su 8.1 o precedenti, è il momento di passare a 8.3 o 8.4.

Attenzione: quando cambi versione dal selettore, controlla l’elenco delle estensioni PHP attive. I moduli non sempre si portano dietro. Clubic ha documentato un caso in cui sullo stesso account erano attive 66 estensioni per PHP 8.1 contro 34 per PHP 8.3. Basta un’estensione mancante (intl, imagick, soap, gd…) per mandare in crisi un modulo di fatturazione o di pagamento.

Su una VPS Debian o Ubuntu

# 1. Aggiornare l'elenco dei pacchetti
sudo apt update

# 2. Installare gli aggiornamenti (PHP compreso)
sudo apt upgrade

# 3. Riavviare PHP-FPM (adatta il numero di versione)
sudo systemctl restart php8.3-fpm

# 4. Se usi Apache con mod_php, riavvia Apache
sudo systemctl restart apache2

Se usi il repository di Ondřej Surý (ppa:ondrej/php su Ubuntu, packages.sury.org su Debian), bastano gli stessi comandi: il repository ha pubblicato le versioni dalla 8.2.35 alla 8.5.12 il 21 ottobre e ha portato la correzione all’indietro fino a PHP 5.6.

Su una VPS AlmaLinux, Rocky Linux o Red Hat

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd

# Verificare che la correzione sia presente nel changelog del pacchetto
rpm -q --changelog php-common | grep -m3 CVE-2026-10961

Attenzione: se i tuoi pacchetti PHP arrivano dal repository comunitario Remi, sappi che il progetto PHP aveva avvisato che non sarebbe stato aggiornato il giorno stesso dell’uscita della patch. Controlla a che punto è e, se non arriva nulla, passa ai pacchetti della tua distribuzione o a un’altra fonte.

Con Docker

Riavviare un container non basta: bisogna ricostruire l’immagine partendo da un’immagine di base aggiornata.

# Scaricare l'immagine ufficiale aggiornata (esempio con PHP 8.4 FPM)
docker pull php:8.4-fpm

# Ricostruire le immagini forzando il download delle basi
docker compose build --pull --no-cache

# Riavviare i servizi
docker compose up -d

# Controllare la versione nel container
docker compose exec app php -v

Pensa anche alle immagini costruite mesi fa che girano ancora in produzione senza che nessuno le tocchi. Sono le più pericolose.

Con Ploi, Laravel Forge, RunCloud o Plesk

Laravel Cloud si aggiorna da solo. Su Laravel Forge l’aggiornamento si fa dalla dashboard del server. RunCloud ha messo il pannello in manutenzione per aggiornare PHP: quando torna disponibile, controlla la versione dei tuoi server. Plesk ha pubblicato le versioni corrette di PHP dalla 8.2 alla 8.5, e cPanel i suoi pacchetti aggiornati, anche per 8.1, 8.0 e 7.4.

In locale (XAMPP, WAMP, Laragon, MAMP)

La macchina di sviluppo di norma non è esposta su Internet, quindi l’urgenza è minore. Aggiorna comunque appena il tuo strumento propone la nuova versione, soprattutto se hai già aperto la postazione a test esterni o a un tunnel tipo ngrok.

Passo 5: riavviare tutti i processi PHP e controllare

Un PHP aggiornato ma non riavviato continua a far girare il vecchio codice in memoria. Il progetto PHP insiste: va riavviato ogni worker.

Una volta riavviato tutto:

1. ricrea il file phpinfo temporaneo (passo 2), controlla la versione e poi cancellalo;
2. prova le pagine vitali: home, login, modulo di contatto, carrello, pagamento in modalità test;
3. tieni d’occhio i log degli errori per un’ora.

# Seguire in tempo reale gli errori di PHP-FPM (il percorso può variare)
sudo tail -f /var/log/php8.3-fpm.log

Passo 6: se oggi non puoi aggiornare

Succede: hosting in ritardo, vecchio sito di un cliente che non regge un ramo nuovo, fornitore irraggiungibile. Il bollettino ufficiale di PHP elenca alcune misure che riducono l’esposizione senza eliminarla. Da usare solo nell’attesa.

Le impostazioni raccomandate da PHP

Contro CVE-2026-109619, disattiva il tracciamento dell’avanzamento degli upload. WordPress non lo usa, quindi per la maggior parte dei siti la disattivazione non ha conseguenze.

; php.ini o configurazione applicata prima dell'elaborazione della richiesta
session.upload_progress.enabled = 0

; Solo su PHP 8.5
fatal_error_backtraces = 0

In un pool PHP-FPM la forma consigliata è quella che impedisce all’applicazione di modificare il valore:

php_admin_flag[session.upload_progress.enabled] = off

Il progetto PHP precisa di non contare su ini_set() né su un file .user.ini per questa impostazione: intervengono troppo tardi. Poi riavvia tutti i worker.

Contro CVE-2026-109618, PHP consiglia di ridurre la dimensione massima delle richieste. Per un sito senza upload di file, post_max_size = 8M; se gli upload servono, post_max_size = 32M, con upload_max_filesize più basso. PHP cita anche la rimozione del limite di memoria (memory_limit=-1) compensata da un limite a livello di container o di sistema. È un’impostazione per chi conosce bene il proprio server: fatta male, apre la strada ai crash.

Mettersi dietro Cloudflare

Cloudflare ha attivato regole contro PHP2Shell su tutti i piani, gratuito compreso, già dal 21 ottobre. Per approfittarne il dominio deve passare dal suo proxy (la nuvola arancione nella scheda DNS). Sui piani a pagamento verifica che le regole gestite siano impostate per bloccare e non solo per registrare.

Due limiti da conoscere: un attaccante che conosce l’indirizzo IP reale del tuo server può aggirare Cloudflare, e Cloudflare stesso ricorda che PHP va comunque aggiornato. Se puoi, limita l’accesso diretto al server ai soli indirizzi di Cloudflare.

Una vera pagina di manutenzione, a livello di server

Se decidi di spegnere il sito, come hanno fatto molte amministrazioni, fallo a monte di PHP, così che le richieste non arrivino mai all’interprete. Basta una pagina HTML statica.

Con Apache, nel .htaccess nella root (crea prima un file maintenance.html):

RewriteEngine On
# Facoltativo: lasciare passare il tuo indirizzo IP
# RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ - [R=503,L]
ErrorDocument 503 /maintenance.html

Con Nginx, nel blocco server del sito:

error_page 503 /maintenance.html;
location = /maintenance.html {
    root /var/www/maintenance;
    internal;
}
location / {
    return 503;
}

Poi sudo nginx -t && sudo systemctl reload nginx. Il codice 503 segnala ai motori di ricerca un’indisponibilità temporanea, e questo protegge il posizionamento se lo stop non dura giorni.

Passo 7: lasciarsi alle spalle PHP 8.1, 8.0 o 7.x

Se il tuo sito gira ancora su un ramo abbandonato, PHP2Shell è il segnale che non si può più rimandare. Il progetto PHP ha pubblicato solo correzioni minime in forma di codice sorgente per 7.4, 8.0 e 8.1. Alcune distribuzioni, il repository sury.org, cPanel o i fornitori di supporto esteso (ELTS) offrono pacchetti corretti, ma è solo una proroga.

Il metodo più sicuro per migrare:

1. crea una copia di staging del sito (molti hosting la offrono con un clic, oppure c’è un plugin di duplicazione);
2. porta la copia su PHP 8.3 o 8.4;
3. prova tutto quello che porta soldi o contatti: carrello, pagamento, moduli, area clienti, fatture;
4. attiva la visualizzazione degli errori solo sulla copia, e correggi o sostituisci i plugin che danno problemi;
5. passa il sito in produzione, poi ripeti i test.

Se parti da lontano, non puntare su PHP 8.2: la fine del supporto è fissata al 31 dicembre 2026. Meglio fare la migrazione una volta sola.

Passo 8: verificare che nessun intruso sia passato prima della patch

Aggiornare chiude la porta. Non fa uscire chi fosse già entrato. I primi tentativi di attacco sono stati individuati da Cloudflare la mattina del 21 ottobre, prima della pubblicazione della patch, e watchTowr ha osservato uno sfruttamento reale lo stesso giorno. Un negozio online, anche piccolo, ha quindi tutto l’interesse a fare un controllo veloce.

Le verifiche di base

Per WordPress, con WP-CLI:

# Elencare gli amministratori: ce n'è qualcuno che non conosci?
wp user list --role=administrator

# Verificare l'integrità dei file del core di WordPress
wp core verify-checksums

# Verificare i plugin provenienti dalla directory ufficiale
wp plugin verify-checksums --all

Su qualsiasi tipo di sito:

# File PHP modificati negli ultimi dieci giorni
find /var/www -type f -name "*.php" -mtime -10

# File PHP nella cartella dei media: non è mai normale
find /var/www -path "*uploads*" -type f -name "*.php"

Controlla anche:

• le attività pianificate (crontab -l per ogni utente, e i cron di WordPress);
• i log di accesso intorno al 20, 21 e 22 ottobre: richieste POST molto pesanti verso indirizzi insoliti, picchi di errori 500;
• i log di PHP: una valanga di messaggi “Allowed memory size exhausted” in un breve lasso di tempo merita un controllo più attento;
• le connessioni in uscita inattese dal server.

Cambiare i segreti, per precauzione

La seconda falla può far trapelare dati presenti in memoria. Se il server è rimasto esposto senza patch, cambiare gli elementi sensibili costa poco:

• le chiavi di sicurezza di WordPress in wp-config.php (disconnette tutti, ed è voluto);
• la password del database;
• le chiavi API dei pagamenti (Stripe, PayPal), dell’invio email e dei servizi di terze parti;
• le chiavi dell’API REST di WooCommerce, se le usi.

Già che ci sei, attiva l’autenticazione a due fattori sull’area clienti dell’hosting, sul registrar e sull’account amministratore del sito. Una chiave di sicurezza fisica è la soluzione più solida: senza di lei, una password rubata non basta più per entrare.

Yubico YubiKey 5 NFC, chiave di sicurezza

Chiave fisica che conferma l accesso al tuo account Google via NFC o USB. Protegge l account che sincronizza i tuoi contatti.

• AmazonVedi su Amazon

Se trovi qualcosa

Non cancellare tutto in preda al panico. Metti il sito in manutenzione a livello di server (passo 6), conserva una copia dei file sospetti e dei log, poi ripristina un backup pulito precedente al 17 ottobre prima di rimettere il sito online. Per un sito che tratta dati personali di clienti europei, il GDPR impone di notificare la violazione all’autorità competente entro 72 ore quando presenta un rischio per le persone: in Italia è il Garante per la protezione dei dati personali, in Francia la CNIL. In Italia puoi segnalare l’incidente anche al CSIRT Italia dell’ACN, mentre in Francia il servizio cybermalveillance.gouv.fr può indirizzarti verso fornitori specializzati.

Passo 9: non rivivere tutto questo alla prossima falla

PHP2Shell non sarà l’ultimo allarme. Qualche abitudine semplice cambia tutto:

• su una VPS Debian o Ubuntu, attiva gli aggiornamenti di sicurezza automatici con unattended-upgrades;
• iscriviti agli avvisi del CSIRT Italia (o del CERT-FR se lavori in Francia) e alla pagina di stato del tuo hosting;
• tieni aggiornato un elenco dei tuoi siti, con hosting e versione di PHP, soprattutto se gestisci siti di clienti;
• pianifica fin da ora l’abbandono di PHP 8.2 prima del 31 dicembre 2026;
• prova a ripristinare i backup almeno una volta a trimestre.

Per andare oltre sul fronte WordPress, la nostra selezione dei migliori plugin per proteggere un sito WordPress completa bene questa guida, e se il tuo hosting ti ha deluso durante questa crisi, il nostro confronto delle migliori società di hosting WordPress ti aiuterà a cambiarlo.

Proteggere anche la postazione da cui gestisci i siti

Un promemoria che vale per tutti i freelance: il server non è l’unico punto d’ingresso. Dal 21 ottobre girano finti messaggi di hosting che spingono a “installare la patch PHP” tramite un link trappola. Se il tuo computer viene infettato, l’attaccante si prende gli accessi SSH, FTP e le password di amministrazione, e a quel punto aggiornare PHP serve a poco. Nessun antivirus corregge PHP2Shell su un server, ma una suite di sicurezza recente, con firme e filtri anti-phishing aggiornati di continuo, protegge il computer che custodisce le chiavi dei tuoi siti. Ecco la nostra selezione, prezzi rilevati il 23 ottobre 2026.

La cassetta degli attrezzi dello sviluppatore freelance

Ecco l’attrezzatura che consigliamo a un freelance o a un piccolo negozio online per non farsi trovare impreparati al prossimo allarme: backup che restano fuori portata, account blindati da una chiave fisica, un’alimentazione protetta per il piccolo server dell’ufficio e un buon libro per passare senza ansie a PHP 8.

La checklist veloce

Per chi ha letto di corsa, ecco l’essenziale:

• ☐ So chi gestisce PHP sul mio sito (il provider o io).
• ☐ Ho controllato la versione effettivamente in uso (e poi ho cancellato il phpinfo).
• ☐ Versione 8.5.12, 8.4.27, 8.3.36, 8.2.35 o pacchetto di distribuzione corretto.
• ☐ Tutti i processi PHP sono stati riavviati.
• ☐ Le pagine vitali (pagamento, moduli) funzionano.
• ☐ Nessun amministratore sconosciuto, nessun file PHP sospetto.
• ☐ Chiavi e password sensibili cambiate se il server è rimasto esposto.
• ☐ L’abbandono di PHP 8.1 o 8.2 è in agenda.

Domande frequenti

Il mio piccolo sito interessa davvero ai pirati?

Sì. Gli attacchi di questo tipo sono automatizzati: bot che scandagliano Internet in cerca di server vulnerabili, senza guardare quanto è grande il sito. Un piccolo e-commerce ha dati dei clienti, un server utilizzabile per mandare spam e un dominio con una reputazione da sfruttare.

Il mio hosting dice che sono protetto: devo fare qualcosa?

Controlla comunque la versione di PHP del sito e chiedi se la patch è installata o se si tratta di una protezione temporanea. Poi, se gestisci un negozio online, fai i controlli del passo 8.

Basta un plugin di sicurezza per WordPress (Wordfence, Sucuri…)?

No. Questi plugin girano dentro PHP e non sostituiscono l’aggiornamento dell’interprete. Un firewall esterno come Cloudflare aggiunge protezione, ma non corregge la falla.

Come faccio a sapere se il mio sito è stato violato tramite PHP2Shell?

Non esiste un segnale unico. Gli indizi più comuni sono un account amministratore sconosciuto, file PHP recenti in cartelle insolite, redirect strani, un avviso di Google Search Console o un aumento improvviso delle risorse consumate dal server.

PHP 8.3.35 è sicuro?

No. Quella versione di settembre correggeva altre falle. Per il ramo 8.3 serve PHP 8.3.36 o un pacchetto di distribuzione che integri esplicitamente entrambe le correzioni.

Devo mettere il sito in manutenzione?

Se il sito è già aggiornato, no. Se non lo è e non riesci ad aggiornarlo in tempi brevi, è quello che raccomandano l’ANSSI francese e l’NCSC britannico, a patto di farlo a livello di web server o di Cloudflare, non con un plugin di WordPress.

In sintesi

Per un piccolo sito, correggere PHP2Shell spesso si riduce a una verifica e a una email al provider. Per una VPS, a un aggiornamento dei pacchetti e a un riavvio. Il lavoro vero, quello che si tende a dimenticare, è controllare dopo che nessuno sia entrato nei pochi giorni in cui la porta è rimasta aperta. Prenditi un’ora per farlo: ci vuole sempre meno che ricostruire un negozio online violato.

Hai avuto problemi ad aggiornare PHP, un plugin che non vuole saperne di funzionare con la 8.3 o un hosting che non risponde? Scrivicelo nei commenti, aggiorneremo la guida con le vostre segnalazioni.

Fonti: bollettino di sicurezza ufficiale di php.net (21 ottobre 2026), avviso Ubuntu USN-8948-1, security tracker di Debian, indicazioni di WordPress.org, Cloudflare, CloudLinux, Plesk e cPanel, verifiche pubblicate da Clubic. Guida aggiornata il 23 ottobre 2026.

In qualità di Affiliato Amazon, Wanda-techs riceve un guadagno dagli acquisti idonei. Questo non influisce sulla nostra analisi indipendente né sul prezzo che paghi.