Cosa sono le due falle critiche di PHP emerse a ottobre 2026, chi è già al sicuro e come controllare il proprio sito anche senza essere sistemisti
Chi gestisce un sito WordPress da qualche anno ha sviluppato un riflesso quasi automatico: esce una vulnerabilità, si entra in bacheca, si clicca su “Aggiorna”, si torna a lavorare. Funziona con i plugin, con i temi, con il core. A luglio, quando è circolata la falla wp2shell, WordPress.org ha distribuito la correzione in automatico e la maggior parte dei siti è stata sistemata senza che nessuno muovesse un dito.
Con PHP2Shell quel riflesso non serve a niente. Il problema sta un piano più sotto, nel linguaggio con cui WordPress è scritto e che il server usa per farlo girare. E lì, dalla bacheca, non si arriva.
Che cos’è PHP2Shell
PHP2Shell è il soprannome dato a due vulnerabilità del motore di PHP, registrate come CVE-2026-109618 e CVE-2026-109619. Entrambe hanno un punteggio di gravità di 9,2 su 10 nello standard CVSS v4.0. Le correzioni ufficiali sono state pubblicate dal progetto PHP il 21 ottobre 2026.
Si tratta di difetti nella gestione della memoria all’interno del core di PHP, raggiungibili con normali richieste web e senza bisogno di autenticarsi. In pratica un attaccante, senza avere alcun account sul sito, può arrivare a eseguire codice sul server. Una delle due falle permette anche di leggere porzioni di memoria del processo, dove possono trovarsi password, token di autenticazione, chiavi API e certificati appartenenti ad altre richieste.
La portata è ampia per una ragione semplice: PHP alimenta circa il 70% dei siti web secondo le stime di W3Techs, e ogni versione rilasciata dal 2012 in poi contiene almeno uno dei due difetti. Questo non vuol dire che il 70% del web sia attaccabile, ma rende l’idea di quanto sia esteso il perimetro da controllare.
Chi l’ha scoperta, e perché se ne è parlato così tanto
La storia della scoperta ha attirato quasi più attenzione della falla stessa. Secondo il post di rilascio della PHP Foundation, la vulnerabilità è stata segnalata tre volte in modo indipendente: dalla società di sicurezza Calif l’11 agosto, da Wiz Research il 24 agosto e dal team Codex Security di OpenAI il 18 settembre. Il nome PHP2Shell viene da Wiz, che ha dichiarato di aver lavorato con la propria piattaforma Wiz Atlas affiancata da modelli di Google e OpenAI. È uno dei casi più citati del 2026 di ricerca sulle vulnerabilità condotta con l’aiuto dell’intelligenza artificiale.
La divulgazione coordinata, invece, è andata storta. Il 20 ottobre gli identificativi CVE hanno iniziato a circolare online con un orario di rilascio sbagliato e un punteggio errato di 10.0, costringendo il progetto PHP ad accelerare i tempi. Amazon ha poi riferito che un suo honeypot aveva registrato un tentativo di sfruttamento già il 17 ottobre, quattro giorni prima della pubblicazione ufficiale.
Le reazioni istituzionali sono state insolitamente nette. La divisione cybersecurity della NSA ha raccomandato di mettere offline i sistemi che non potevano essere aggiornati subito, e consigli simili sono arrivati dalla CISA americana, dal CERT dell’Unione europea e dal National Cyber Security Centre britannico. La Wikimedia Foundation ha spento in via precauzionale alcuni sistemi, e nei Paesi Bassi sono andati temporaneamente offline servizi pubblici come DigiD.
Perché aggiornare WordPress questa volta non basta
WordPress.org lo ha scritto senza giri di parole nel suo avviso del 21 ottobre: le vulnerabilità non sono specifiche di WordPress, riguardano qualsiasi server che ospita un’applicazione PHP, e nessun aggiornamento di WordPress è necessario o previsto. I ricercatori hanno dimostrato l’attacco sull’immagine ufficiale e aggiornata di WordPress, quindi un sito con core, temi e plugin all’ultima versione resta esposto se il PHP sottostante non è stato corretto.
C’è un dettaglio che spesso sfugge. I plugin di sicurezza, compresi i firewall applicativi più diffusi, girano dentro PHP. Quando l’attacco colpisce il motore stesso, in certe configurazioni prima ancora che il codice di WordPress venga caricato, il plugin interviene troppo tardi o non interviene affatto. Per lo stesso motivo la modalità manutenzione di WordPress non protegge: la richiesta viene gestita da PHP prima che WordPress decida cosa mostrare.
Diffidate quindi dei plugin “anti-PHP2Shell” e degli snippet copiati dai forum che promettono di chiudere la falla. Diverse fonti del settore, tra cui MalCare e Digidop, sconsigliano esplicitamente di installarli: nel migliore dei casi riducono un po’ il rischio, nel peggiore danno una falsa sensazione di sicurezza.
Chi è già protetto
Qui entra in gioco una distinzione che molti utenti italiani confondono ancora: quella tra WordPress.com e WordPress.org.
WordPress.org è il software libero che si scarica e si installa sul proprio hosting. WordPress.com è invece il servizio di Automattic che ospita siti WordPress già pronti, dal blog personale al sito aziendale. Automattic ha comunicato il 21 e il 22 ottobre che tutti i siti sulla sua infrastruttura, cioè WordPress.com, WordPress VIP, WP Cloud, Pressable e Tumblr, sono già protetti. Chi ha il sito lì non deve fare nulla, e anzi Automattic suggerisce di non aggiungere plugin di sicurezza ulteriori, perché alcuni possono interferire con le protezioni della piattaforma.
Anche diversi hosting gestiti hanno comunicato di aver applicato le correzioni a livello di server. Kinsta dichiara di aver aggiornato PHP su tutti gli ambienti, staging compresi, senza rilevare violazioni. SiteGround, molto usato anche in Italia, afferma di aver introdotto mitigazioni già il 20 ottobre e di aver applicato le patch ufficiali su tutti i server il giorno stesso del rilascio, senza richiedere interventi ai clienti. Cloudflare, dal canto suo, ha attivato di default regole del firewall contro gli attacchi noti sia per i clienti gratuiti sia per quelli a pagamento.
Sugli hosting condivisi più comuni in Italia il meccanismo è questo: dal pannello potete scegliere il ramo di PHP (per esempio passare dalla 7.4 alla 8.3), ma la patch di sicurezza dentro quel ramo la installa il provider.
Chi invece gestisce in autonomia un VPS o un server dedicato è responsabile dell’aggiornamento, e deve occuparsene subito.
Le versioni da cercare
Il progetto PHP ha rilasciato versioni corrette per i quattro rami ancora supportati: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Se il vostro sito gira su una di queste o su una successiva, la falla è chiusa.
Il problema vero riguarda chi è rimasto indietro. PHP 8.1 è uscito dal supporto il 31 dicembre 2025, e i rami precedenti ancora prima, quindi per loro non esiste un rilascio ufficiale. Data la gravità, il team PHP ha pubblicato delle correzioni minime a livello di codice sorgente per le versioni 7.4, 8.0 e 8.1, che alcune distribuzioni Linux e alcuni fornitori di supporto esteso hanno integrato nei propri pacchetti. Per la 7.3 e precedenti non c’è nulla: l’unica strada è migrare.
Non è una questione marginale. Secondo le statistiche pubblicate da WordPress.org nei giorni successivi al rilascio, circa un terzo dei siti WordPress gira ancora su PHP 8.1 o versioni più vecchie, con la 7.4 da sola intorno al 15%. Le stime variano leggermente a seconda di chi ha fatto il conteggio, ma l’ordine di grandezza è quello.
Anche chi è su PHP 8.2 farebbe bene a non rilassarsi troppo: il supporto di sicurezza per quel ramo termina il 31 dicembre 2026. WordPress oggi raccomanda PHP 8.3 o superiore, e questa è un’occasione ragionevole per allinearsi.
Come controllare il tuo sito WordPress
Il primo controllo si fa dalla bacheca. Andate in Strumenti, poi Salute del sito, poi nella scheda Info aprite la sezione Server: lì trovate la versione di PHP in uso. In alternativa, molti pannelli di hosting mostrano la versione completa nella pagina dedicata a PHP.
C’è però una trappola. Distribuzioni come Ubuntu, Debian e Red Hat applicano le correzioni di sicurezza senza cambiare il numero di versione principale. Un server Ubuntu 24.04 correttamente aggiornato può quindi mostrare PHP 8.3.6, un numero più basso di 8.3.36, pur avendo la patch. Il numero da solo, in questi casi, non dice tutta la verità.
Per questo il passaggio più affidabile per chi non gestisce il server è scrivere all’assistenza dell’hosting e chiedere una conferma scritta. Le domande utili sono tre: quale versione di PHP serve esattamente il mio sito, quando è stata applicata la correzione per CVE-2026-109618 e CVE-2026-109619, e se i processi PHP sono stati riavviati dopo l’aggiornamento. L’ultima domanda sembra pignola ma non lo è, perché un aggiornamento installato e mai caricato non protegge nessuno.
Se scoprite di essere su un ramo vecchio e volete passare a uno supportato, fatelo con un minimo di prudenza: backup completo, aggiornamento di WordPress, temi e plugin alla versione più recente, prova su un ambiente di staging se l’hosting lo offre, e solo dopo il cambio di versione in produzione. Se qualcosa si rompe, WordPress.org suggerisce di chiedere all’hosting di ripristinare la versione precedente di PHP e poi recuperare il backup.
Se non puoi aggiornare subito
Il progetto PHP ha indicato alcune misure temporanee per ridurre l’esposizione, ma insiste su un punto: solo l’aggiornamento è una soluzione completa. Tra le contromisure più citate c’è la disattivazione di session.upload_progress, una funzione che WordPress non usa, e l’adozione di regole specifiche sul web server o sul firewall. Sono interventi da affidare a chi amministra il server, non da improvvisare.
Per un sito che gestisce dati di clienti, ordini o account, e che gira su una versione di PHP senza correzione disponibile, vale la pena considerare seriamente il consiglio delle agenzie di sicurezza: meglio qualche ora offline che un server compromesso.
Dopo la patch
Una volta aggiornato PHP, la porta è chiusa. Resta però una domanda scomoda: qualcuno è entrato prima? I dettagli tecnici sono circolati prima della correzione e i tentativi di sfruttamento sono iniziati presto, quindi l’aggiornamento non dimostra che il sito sia rimasto intatto.
Qualche controllo di buon senso aiuta. Verificate che non ci siano utenti amministratori sconosciuti, che nella cartella degli upload non compaiano file PHP che non avete messo voi, che non siano stati aggiunti cron o file sospetti. E visto che una delle due falle consente di leggere la memoria del server, cambiare le password del database, le chiavi API dei servizi collegati e i sali di WordPress è una precauzione che costa poco rispetto a ciò che protegge.
Una lezione che va oltre questa falla
PHP2Shell ricorda una cosa che chi lavora con WordPress tende a dimenticare: un sito è fatto di più strati, e quello che si vede in bacheca è solo il più alto. Sotto ci sono PHP, il web server, il sistema operativo, e ognuno ha qualcuno che dovrebbe occuparsene. Sapere chi è quel qualcuno, nel vostro caso specifico, è la vera informazione utile da portarsi a casa da questa vicenda. Con un hosting gestito e serio, molti clienti non si sono nemmeno accorti di nulla. Con un VPS lasciato a sé stesso o un PHP fermo alla 7.4, la storia è stata diversa.
Domande frequenti
Il mio sito è su WordPress.com: devo fare qualcosa per PHP2Shell?
No. Automattic ha confermato che tutti i siti ospitati sulla sua infrastruttura, inclusi WordPress.com, WordPress VIP, WP Cloud, Pressable e Tumblr, sono già protetti.
Aggiornare WordPress e i plugin risolve PHP2Shell?
No. La falla è nel motore di PHP e WordPress.org ha dichiarato che nessun aggiornamento del core è necessario o previsto. Serve aggiornare PHP sul server.
Quali versioni di PHP correggono PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, rilasciate il 21 ottobre 2026. Per 7.4, 8.0 e 8.1 esistono solo correzioni a livello di sorgente o pacchetti di distribuzioni e fornitori di supporto esteso.
Ho un hosting condiviso: chi deve aggiornare PHP?
Il provider. Voi potete scegliere il ramo dal pannello, ma la patch dentro il ramo la installa l’hosting. Chiedete una conferma scritta con la versione esatta e la data dell’intervento.
Un plugin di sicurezza può proteggermi da PHP2Shell?
Non in modo affidabile, perché i plugin girano dentro PHP e l’attacco colpisce il motore stesso. Firewall esterni come Cloudflare possono bloccare gli attacchi noti, ma restano una protezione temporanea in attesa dell’aggiornamento.
