Tra il 20 e il 21 ottobre 2026 il mondo dei siti web ha vissuto una di quelle giornate che mettono in allarme chiunque gestisca un server. Il nome in codice è PHP2Shell, e riguarda il linguaggio su cui girano WordPress, WooCommerce e buona parte del web.
Ecco i fatti, in ordine.
Dalla fuga di notizie alle patch
Tutto parte il 20 ottobre, quando in rete circola l’indiscrezione che il team di sicurezza di PHP stia per annunciare due vulnerabilità di esecuzione di codice da remoto. Nello stesso giorno il progetto PHP pubblica sul proprio sito un preavviso ufficiale: è in arrivo un rilascio di sicurezza straordinario, programmato per il 21 ottobre alle 14:00 UTC.
Le informazioni, che avrebbero dovuto restare riservate fino al rilascio, escono prima. Compaiono i numeri di identificazione delle due falle, CVE-2026-109618 e CVE-2026-109619, e circola lo screenshot di uno strumento di attacco chiamato proprio “PHP2Shell”, da cui il nome.
Il 21 ottobre arrivano le versioni corrette (PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35), insieme all’avviso di sicurezza ufficiale di PHP.
In Italia l’Agenzia per la Cybersicurezza Nazionale pubblica il bollettino tramite il CSIRT Italia (AL07/261021/CSIRT-ITA), poi aggiornato più volte nel corso della giornata con ulteriori dettagli tecnici.
Il messaggio è netto: aggiornare i sistemi e verificare eventuali compromissioni.
Cosa sono le due vulnerabilità
Entrambe hanno una gravità di 9,2 su 10 (CVSS v4.0) e permettono, almeno in teoria, di far eseguire codice arbitrario al server senza bisogno di password né di alcun accesso, con una semplice richiesta web costruita ad arte.
In termini tecnici, sono due vulnerabilità di tipo use-after-free: il programma continua a usare una porzione di memoria che era già stata liberata.
- CVE-2026-109618 nasce da una gestione non corretta delle condizioni di memoria esaurita, in cui PHP interrompe l’elaborazione della richiesta in modo da lasciare dati inconsistenti.
- CVE-2026-109619 riguarda lo stato interno di PHP che, dopo errori critici, timeout o altre condizioni particolari, può conservare riferimenti a memoria già liberata.
Un attaccante che le sfrutta può ottenere l’esecuzione di codice con i privilegi del processo PHP che serve il sito. Da lì le conseguenze sono quelle classiche: webshell nascoste, malware, accesso ai file e al database del sito, pagine alterate, spam inviato dal tuo dominio.
Il punto chiave: non è un problema di WordPress
Questa è la differenza rispetto ai problemi a cui siamo abituati. La falla non è in WordPress, in un plugin o in un tema. È nel motore PHP, quello che sta sotto qualsiasi sito scritto in PHP. Per questo può riguardare anche un sito curato, con tutti i plugin aggiornati.
L’avviso ufficiale del progetto PHP è chiaro: sono a rischio tutte le installazioni che servono richieste web, comprese le principali modalità di funzionamento (PHP-FPM, Apache con mod_php, php-cgi, LiteSpeed).
Il rischio è considerato più alto con Apache e mod_php, dove è stato dimostrato un attacco in cui una richiesta senza autenticazione può colpire il server prima ancora che parta il codice del sito. Per le altre modalità la valutazione è più cauta, ma il progetto raccomanda comunque di aggiornare subito.
Secondo quanto riportato da diverse testate di settore, i ricercatori che hanno individuato le falle avrebbero verificato la possibilità di eseguire codice su installazioni di WordPress e Drupal e su altre applicazioni molto diffuse, come Joomla, Magento, phpMyAdmin e Nextcloud.
Resta il punto essenziale: non conta il CMS che usi, conta la versione di PHP sul server.
Falsi rimedi e truffe: cosa evitare in questi giorni
Quando una falla di questo tipo diventa pubblica, scatta quasi subito una corsa. Da una parte chi la usa per scansioni massive alla ricerca di server non aggiornati, dall’altra chi sfrutta la notizia per truffare.
Nelle ore successive alla pubblicazione sono comparsi anche falsi PoC, cioè codice presentato come “exploit” o “scanner” che in realtà è fatto per infettare chi lo scarica e lo esegue. Se non sei un professionista della sicurezza, la regola è semplice: non scaricare né eseguire nulla che prometta di “testare PHP2Shell”.
Sul fronte degli attacchi, le prime ore sono state chiare: Cloudflare, uno dei principali servizi di protezione per i siti web, ha riferito di aver osservato traffico di attacco diretto ai propri clienti dopo la fuga di notizie e di aver visto gli aggressori modificare i tentativi per aggirare le difese.
Questo non significa che i siti siano stati compromessi, ma conferma che le scansioni erano già in corso e che la finestra utile per aggiornare era davvero breve.
Il nodo vero: non tutte le versioni di PHP sono ancora supportate
La parte che molti sottovalutano è questa: il progetto PHP ha rilasciato le correzioni per i rami ancora supportati, cioè dalla 8.2 alla 8.5 (versioni 8.2.35, 8.3.36, 8.4.27 e 8.5.12).
- Chi usa PHP 8.2 riceve il fix, ma il supporto di sicurezza di quel ramo termina il 31 dicembre 2026.
- Chi usa PHP 8.1 o versioni precedenti non riceve più aggiornamenti dal progetto. Per questi casi esistono soluzioni particolari: correttivi pensati per chi compila PHP dal codice sorgente, oppure patch fornite da alcune distribuzioni Linux e fornitori di supporto a lungo termine. Se il tuo sito è su un hosting condiviso, la domanda da fare al provider è: “Per la mia versione di PHP è stata applicata una correzione?” In assenza di una risposta chiara, l’unica strada sicura è passare a una versione supportata.
- Anche dove l’aggiornamento è stato installato, bisogna riavviare i servizi PHP, altrimenti il server continua a eseguire il vecchio codice.
Se non puoi aggiornare subito: un firewall davanti al sito
L’unica soluzione completa è aggiornare PHP, e il progetto lo dice chiaramente. Nell’attesa, però, un firewall per applicazioni web (WAF) posto davanti al sito può bloccare le richieste sospette prima che arrivino al server. Cloudflare ha attivato regole specifiche contro PHP2Shell per tutti i suoi clienti, anche con il piano gratuito, e consiglia comunque di aggiornare PHP.
Un firewall è un livello di difesa in più, non un sostituto dell’aggiornamento: gli aggressori provano continuamente a modificare i propri attacchi per aggirarlo. Per un sito che passa da un servizio di questo tipo conviene verificare che le protezioni siano attive. Un’altra misura che riduce l’esposizione è limitare gli upload non necessari e le loro dimensioni, come indicano anche i fornitori di sicurezza.
Vale anche per il tuo sito: alcune domande da farsi
Se hai un sito (un blog, un negozio WooCommerce, un portale di una testata, il sito di uno studio professionale) e non sei sicuro della risposta a queste domande, non sei il solo. È normale, ed è proprio per questo che vale la pena controllare.
- Quale versione di PHP sta usando il mio sito? Molti non lo sanno, e spesso non lo sa nemmeno chi l’ha costruito.
- Il mio hosting ha già applicato le correzioni e riavviato i servizi? Ricevere l’aggiornamento e renderlo operativo sono due cose diverse.
- Quella versione è ancora supportata? Se è fuori supporto, non esiste nessun fix da aspettare.
- Qualcuno controlla gli avvisi di sicurezza al posto mio? Se la risposta è “nessuno”, la sicurezza dipende dalla fortuna.
- Ho notato di recente qualcosa di strano? Rallentamenti, redirect inattesi, file sconosciuti, email di spam partite dal dominio.
Per i clienti di IlTuoSpazioWeb.it
I server su cui sono ospitati i siti che realizzo e gestisco, appoggiati a iltuospazioweb.it, hanno ricevuto le misure di sicurezza mentre venivano rilasciate le correzioni ufficiali.
Nelle prime ore, in attesa dei fix, ho attivato filtri di sicurezza temporanei a livello di server. Qualcuno può aver visto upload di immagini che non andavano a buon fine, moduli che non si inviavano o errori 415: erano gli effetti di quei filtri, non guasti del sito. Chi non ha notato nulla era protetto comunque, perché i filtri lavorano a monte.
Non era possibile scrivere a ciascun cliente nei momenti più concitati, perché la priorità era mettere in sicurezza le macchine. Le comunicazioni sono state pubblicate subito nell’area annunci di iltuospazioweb.it, e il supporto via ticket ed email è rimasto operativo per ogni richiesta.
Se hai ancora comportamenti anomali su moduli o upload, scrivimi con un ticket: potrebbe servire un controllo sul tuo sito. Grazie a chi ha segnalato i problemi con precisione: è stato molto utile.
Se vuoi capire a che punto è il tuo sito
Sono un webmaster a Roma, ma il lavoro si svolge online: il tuo sito può essere ospitato su qualsiasi server, in Italia o nel resto del mondo, e posso intervenire da remoto senza alcun problema.
Se hai anche solo un dubbio sulla versione di PHP in uso, sugli aggiornamenti applicati o su comportamenti strani del sito, posso fare una verifica dello stato del sito e del server e valutare con te le opzioni e i passi concreti, anche solo per confermare che sei a posto.
Se preferisci conoscermi prima di decidere, possiamo sentirci come ti è più comodo: una call su Google Meet, una chiamata su WhatsApp o una semplice telefonata.
Per una prima verifica o per qualsiasi dubbio, compila la pagina contatti: ti rispondo il prima possibile.
Chi vuole leggere i dettagli tecnici può consultare le schede ufficiali del team di sicurezza di PHP: CVE-2026-109618 e CVE-2026-109619 (in inglese).
Attenzione a non confondere PHP2Shell con wp2shell: quest’ultima è una vulnerabilità distinta, del core di WordPress, di cui ho parlato in questo articolo.
