Il 21 ottobre 2026 PHP ha corretto due falle critiche, chiamate PHP2Shell (CVE-2026-109618 e CVE-2026-109619), che permettono di eseguire codice sul server senza credenziali. Chi ha un sito WordPress su hosting condiviso deve fare tre cose oggi: verificare la versione PHP del sito, chiedere all’hosting quando installa le versioni corrette (8.5.12, 8.4.27, 8.3.36, 8.2.35), e nell’attesa ridurre l’esposizione con le mitigazioni indicate da PHP e spegnendo i siti che non servono.
In breve
- Gravità: fino a 9,2 punti su 10, senza bisogno di login.
- Tempi: 58 giorni tra la segnalazione a PHP (24 agosto 2026) e la correzione pubblica (21 ottobre 2026).
- Esposizione: oltre 5,1 milioni di host PHP esposti secondo la stima di VirusTotal.
- Versioni sicure: 8.5.12, 8.4.27, 8.3.36, 8.2.35; per 8.1 e precedenti il progetto PHP non rilascia più aggiornamenti.
- Mitigazioni:
post_max_sizea 8 MB (32 MB se il sito riceve file) esession.upload_progress.enabled = 0.
Cos’è PHP2Shell e perché riguarda il tuo sito WordPress?
PHP2Shell è il nome di due vulnerabilità di esecuzione di codice da remoto in PHP, il linguaggio su cui gira WordPress. Hanno gravità fino a 9,2 su 10 e non richiedono login: basta una richiesta al sito. Le ha trovate il gruppo di ricerca di Wiz, con l’aiuto di modelli di intelligenza artificiale, il 19 agosto 2026; la segnalazione a PHP è del 24 agosto, la correzione e l’annuncio pubblico del 21 ottobre: 58 giorni dopo. Secondo Wiz quasi ogni versione di PHP è toccata, fino alla 5.4, e ogni versione uscita nell’ultimo decennio ha almeno uno dei difetti (Wiz Research).
VirusTotal stima oltre 5,1 milioni di host PHP esposti, di cui circa 3,8 milioni con almeno una porta aperta (BleepingComputer). Il punto che interessa a un’azienda: sono a rischio tutte le installazioni PHP che servono richieste web, compresi PHP-FPM, Apache con mod_php, php-cgi e LiteSpeed (Canadian Centre for Cyber Security). Se il tuo sito è un WordPress, un WooCommerce o un modulo di contatto scritto in PHP, è nel perimetro.
Quali versioni di PHP sono corrette?
Le versioni che chiudono entrambe le falle sono queste (BleepingComputer, 21 ottobre 2026):
| Ramo PHP | Versione corretta | Cosa fare |
|---|---|---|
| 8.5 | 8.5.12 | aggiornare appena l’hosting la rende disponibile |
| 8.4 | 8.4.27 | aggiornare appena l’hosting la rende disponibile |
| 8.3 | 8.3.36 | aggiornare appena l’hosting la rende disponibile |
| 8.2 | 8.2.35 | aggiornare appena l’hosting la rende disponibile |
| 8.1 e precedenti | nessun aggiornamento dal progetto PHP | passare a un ramo supportato, o chiedere se il fornitore offre una correzione propria |
Per 7.4, 8.0 e 8.1 il progetto PHP ha pubblicato solo correzioni minime del codice sorgente, utili a chi compila PHP da sé. Alcune distribuzioni e fornitori con supporto esteso offrono correzioni proprie: vanno chiesti al fornitore. Un sito fermo su questi rami va spostato a 8.3 o superiore, dopo aver controllato che tema e plugin lo reggano.
Come controllo la versione PHP del mio sito?
Ci sono tre strade, dalla più semplice:
- Bacheca di WordPress: Strumenti → Salute del sito → Info → Server. La riga «Versione PHP» mostra il numero completo.
- Pannello dell’hosting: quasi tutti hanno una voce «Configurazione PHP» o «Selettore PHP» con il ramo scelto per ogni dominio.
- Chiedere al supporto il numero di versione esatto, non solo il ramo: «8.3» non basta, serve sapere se è 8.3.35 o 8.3.36.
Il numero di versione completo è quello che conta: il ramo giusto, con una versione ancora scoperta, resta vulnerabile.
Cosa fare se l’hosting non ha ancora aggiornato PHP?
Su un hosting condiviso PHP non lo installi tu: lo installa il fornitore, con i suoi tempi. Nell’attesa la patch esiste ma tu non puoi applicarla. È la situazione più comune per le piccole imprese. Le mosse, in ordine di effetto:
- Disattivare l’avanzamento dei caricamenti di sessione: impostare
session.upload_progress.enabled = 0. Su molti hosting si fa con un file.user.ininella cartella del sito o dal selettore PHP. - Abbassare il limite dei dati inviati:
post_max_sizea 8 MB, oppure a 32 MB se il sito riceve caricamenti di file (BleepingComputer). - Verificare sul vivo che i valori siano davvero attivi, non solo salvati nel pannello: un file di prova che stampa la configurazione, letto e cancellato subito.
Gli stessi sviluppatori di PHP avvertono che queste mitigazioni non bloccano del tutto lo sfruttamento: la sola cura completa resta la versione corretta di PHP.
Conviene spegnere i siti che non si possono aggiornare?
Per i siti che non portano lavoro, sì. Il centro nazionale di sicurezza informatica britannico (NCSC) ha avvisato le organizzazioni di aggiornare subito oppure di mettere offline i sistemi interessati finché non sono corretti (BleepingComputer).
La domanda giusta per un’azienda non è «spengo tutto?», ma «quali dei miei siti rendono?». Un vecchio negozio fermo con i pagamenti ancora collegati, una landing di una campagna finita, uno script PHP scritto anni fa per un modulo: sono superficie d’attacco senza ritorno. Per questi conviene una pagina statica di manutenzione che non esegue PHP, con una copia della configurazione per riaccenderli in un attimo. I siti che vendono restano accesi, con le mitigazioni.
Come sapere quando la patch è arrivata?
Non ci si affida alla memoria. Un promemoria quotidiano, o una richiesta scritta al supporto con la versione esatta da attendere, evita di scoprire la patch settimane dopo. Chi ha accesso al server può anche automatizzare il controllo: leggere ogni mattina la versione PHP installata e confrontarla con quelle corrette.
Quando la patch arriva si rimisura la versione dal sito, si tolgono le restrizioni che limitano gli utenti (per esempio i caricamenti grandi) e si decide se riaccendere i siti spenti o lasciarli spenti per sempre.
Dove serve l’AI e dove serve una decisione umana?
In questa vicenda l’intelligenza artificiale è su tutti e due i lati: modelli AI hanno aiutato a trovare le falle e ad adattare gli exploit a versioni diverse di PHP (Wiz Research). Dal lato della difesa, un agente può fare in poche ore il lavoro ripetitivo: misurare la versione su ogni sito, applicare le mitigazioni, verificarle, preparare il controllo quotidiano.
Le scelte con conseguenze restano umane. Spegnere un sito, cambiare il ramo PHP di un negozio con pagamenti attivi, aggiornare un tema su un sito vivo: sono decisioni del titolare. Su siti con plugin vecchi, gli aggiornamenti si provano prima su una copia di prova, mai direttamente sul sito vivo.
La lista di controllo per chi ha un sito WordPress
- Leggi la versione PHP completa di ogni sito che possiedi.
- Se è 8.1 o precedente, passa a 8.3 o superiore dopo un backup.
- Applica le due mitigazioni, poi verifica che siano attive.
- Elenca i siti che non portano clienti né vendite e spegnili con una pagina statica.
- Scrivi all’hosting chiedendo la data in cui installerà le versioni corrette.
- Controlla ogni giorno finché la patch non arriva, poi rimisura.
- Approfitta del momento per aggiornare tema e plugin, su una copia di prova.
Domande frequenti
Il mio sito è su un hosting gestito: devo fare qualcosa?
Sì, almeno verificare. Chiedi la versione PHP esatta e la data di aggiornamento: «ci pensiamo noi» non è una risposta verificabile.
Le falle sono già sfruttate?
Il direttore tecnico di Cloudflare ha confermato di osservare i primi attacchi contro entrambe le falle (BleepingComputer). Conviene comportarsi come se il tuo sito fosse nel mirino.
Un plugin di sicurezza per WordPress mi protegge?
Solo in parte. Le falle sono in PHP, sotto WordPress: un plugin può filtrare alcune richieste, ma non sostituisce la versione corretta.
I siti non WordPress sono al sicuro?
Lo sono se non usano PHP. Siti statici, siti in Python o in Node.js non sono toccati da PHP2Shell; i moduli di contatto scritti in PHP sì.
Cambiare ramo PHP può rompere il sito?
Può succedere con temi e plugin vecchi. Fai prima un backup, prova il cambio su una copia se l’hosting la offre, e controlla home, carrello e pagamento subito dopo.
Esistono aiuti per investire in sicurezza informatica?
Sì, nel 2026 ci sono voucher dedicati a cloud e cybersicurezza per le PMI: li abbiamo raccolti in Voucher cloud e cybersecurity 2026: come fare domanda.
Cosa fare adesso
Apri la bacheca del tuo sito e leggi la versione PHP: è un controllo di 2 minuti. Se è sotto le versioni corrette, applica le mitigazioni oggi e scrivi all’hosting. Se gestisci più siti e vuoi sapere quali sono esposti e quali conviene spegnere, possiamo fare la verifica insieme: parliamone. Per il quadro normativo su AI e dati che entra in vigore in questi giorni, vedi anche D.Lgs 179/2026 e AI Act.