PHP2Shell: la falla sotto il tuo WordPress

Ieri alle quattro del pomeriggio, ora italiana, il team che mantiene PHP ha pubblicato quattro aggiornamenti d’emergenza. Non per un’app, non per un plugin: per il linguaggio che fa girare il tuo sito.

Se hai un sito WordPress, Joomla o Drupal, sotto c’è PHP. Anche un gestionale online fatto su misura può usare PHP: chiedilo a chi lo gestisce. Secondo Wiz, la società di sicurezza che ha trovato le falle insieme a Calif e a OpenAI, PHP fa funzionare il 70% dei siti del mondo. E da ieri si sa che quasi tutte le versioni degli ultimi dieci anni hanno un buco che può permettere a uno sconosciuto di eseguire codice sul tuo server senza avere una password.

I buchi ci sono sempre. La notizia sta in come l’hanno trovato: ricercatori di sicurezza con l’aiuto di modelli AI, decisivi anche per costruire l’attacco che lo dimostra. E gli stessi modelli possono aiutare chi attacca.

Cosa è successo, in ordine

Le due falle hanno un nome tecnico ciascuna, CVE-2026-109618 e CVE-2026-109619, e un nome di battaglia insieme: PHP2Shell. Vuol dire, più o meno, «da PHP alla riga di comando»: chi le sfrutta passa da una richiesta web normale al controllo del server.

Il team di sicurezza di PHP le descrive così: tutte le installazioni che servono richieste web sono a rischio, PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto è su mod_php, dove è stato dimostrato un attacco in cui una singola richiesta, senza nessun accesso, può attivare l’attacco prima ancora che il codice del sito venga eseguito. Entrambe le falle hanno un punteggio di gravità di 9,2 su 10.

La storia è arrivata al pubblico in due tempi. Martedì 20 ottobre un post su Hacker News ha anticipato che due falle gravi di PHP sarebbero state rese note il 22. Quella sera PHP ha pubblicato un preavviso: aggiornamento in arrivo mercoledì 21 alle 14:00 UTC, con una riga che diceva tutto, «ci riserviamo di rilasciare prima se i dettagli diventano pubblici o se compaiono prove di sfruttamento». Il rilascio è arrivato puntuale, un giorno prima del previsto.

Chi le ha trovate? Tre squadre, nello stesso periodo. Calif, una piccola società californiana che fa «red teaming» con l’AI, cioè attacca i sistemi per trovare i punti deboli, ha individuato la prima falla usando GPT-5.6 Sol di OpenAI, dentro un programma di OpenAI che si chiama Patch the Planet. Wiz Research ha trovato entrambe in modo indipendente, usando il suo strumento Atlas, Gemini 4 Argon di Google e GPT-5.6 Sol. OpenAI ha coordinato per due mesi una coalizione di manutentori, ricercatori e fornitori di sicurezza per preparare le correzioni prima della divulgazione.

Un dettaglio che vale la pena tenere a mente. Secondo Fortune, che cita un post di Greg Brockman di OpenAI, il difetto era in PHP da quattordici anni. Una versione limitata era stata scoperta nel 2024 e giudicata poco importante. Quattordici anni sotto gli occhi di tutti. E due mesi, secondo OpenAI, per coordinare la risposta una volta trovato.

Perché riguarda anche un sito piccolo

La reazione più comune, quando esce una notizia così, è: «il mio sito è piccolo, chi vuoi che lo attacchi». È la reazione sbagliata, e questa volta per un motivo preciso.

Il difetto non sta nel tuo sito. Sta nel motore sotto. Wiz lo scrive con una frase che dovresti rileggere due volte: anche una semplice applicazione «Hello World», cioè una pagina che stampa due parole e basta, può essere vulnerabile se gira su una versione di PHP colpita. The Hacker News lo dice in un altro modo: la falla sta nel runtime di PHP, non nell’applicazione, quindi un sito è esposto anche quando il suo codice è perfetto.

Tradotto: puoi aver aggiornato WordPress ieri, aver tolto i plugin inutili, avere una password lunga trenta caratteri. Non c’entra niente. Aggiornare WordPress non aggiorna PHP. PHP lo aggiorna il server, cioè il tuo hosting, o chi te lo gestisce.

E «piccolo» protegge poco. Wiz ha dimostrato di poter eseguire codice da remoto, senza autenticazione, sulle immagini ufficiali più recenti di WordPress, Drupal e Joomla, e spiega che i modelli AI rendono più facile adattare l’attacco a installazioni diverse. BleepingComputer cita una stima di VirusTotal: oltre 5 milioni di server PHP esposti su internet. Fortune cita un’analisi di Palo Alto Networks: 22,6 milioni di istanze potenzialmente vulnerabili. Sono stime su server e istanze, e servono a dare l’idea della scala. Dentro quella scala un sito piccolo, se gira su una versione colpita, è un indirizzo fra milioni, non un nome.

C’è poi un secondo danno, meno visibile del primo. Oltre a eseguire codice, un attaccante può leggere pezzi di memoria del server: Wiz dice che lì dentro possono esserci password, token di accesso, chiavi API e certificati di altre richieste. Il sito può restare in piedi senza che nessuno si accorga di niente, mentre qualcuno ha in mano password e chiavi che aprono altri servizi. Il buco silenzioso è peggio di quello rumoroso.

L’AI ha trovato la falla. Può anche usarla.

Qui sta la parte della notizia che fra un anno ricorderemo ancora.

Wiz paragona PHP2Shell a Heartbleed del 2014 e a Log4Shell del 2021, due falle che hanno cambiato il modo in cui si pensa la sicurezza. E spiega perché questa è diversa: i difetti erano lì da decenni, ma dimostrare che si potevano sfruttare richiedeva una catena di passaggi «al limite di quello che i ricercatori umani potevano praticamente fare». I modelli di frontiera hanno abbassato quella barriera. Hanno trasformato un difetto vecchio in un attacco funzionante «in ore», adattandolo a più applicazioni.

Il ragionamento di Wiz va fino in fondo, ed è il punto che ti riguarda. Un attacco di questo tipo deve essere adattato a ogni versione di PHP, a ogni configurazione, a come ogni server usa la memoria. Prima dell’AI era un lavoro da specialisti, lento, difficile da ripetere su molti bersagli. Adesso un modello può analizzare perché l’attacco è fallito, correggerlo e riprovare. Wiz lo dice senza giri: «questo cambia l’economia sia della scoperta sia dello sfruttamento». Le falle che sembravano troppo complicate da usare diventano bersagli possibili.

OpenAI dice la stessa cosa dal suo lato: l’episodio mostra come l’AI possa scoprire falle con impatto «su scala internet», ma «le stesse capacità possono aiutare gli attaccanti a sviluppare rapidamente strumenti offensivi». Per quanto ne sanno, questa volta l’AI dei difensori è arrivata prima. OpenAI chiama «finestra del difensore» il vantaggio che ne è venuto: manutentori e fornitori hanno potuto preparare correzioni e protezioni prima della divulgazione. E aggiunge una frase che vale come previsione: si aspettano che scoperte simili «aumentino bruscamente nei prossimi mesi».

La mia lettura è questa. Per anni la sicurezza di un sito piccolo si è retta su un ragionamento implicito: ci sono falle, ma sfruttarle costa troppo per prendersela con te. Wiz dice che quel costo è sceso e che, scendendo ancora, la complessità potrebbe smettere di essere una barriera. Ne avevo scritto pochi giorni fa a proposito dei siti scassinati dagli agenti AI: PHP2Shell è la stessa storia, ma un piano più in basso, nelle fondamenta.

Chi ha già staccato la spina

Per capire quanto sia seria una cosa, guarda chi ha già reagito.

Secondo The Hacker News, BambooHR, un servizio di gestione del personale, ha messo offline la piattaforma negli Stati Uniti, in Canada e in Irlanda, avvisando i clienti che le buste paga avrebbero subito ritardi, per precauzione. Nei Paesi Bassi, riporta l’emittente NOS, sono andati offline il portale dei cittadini MijnOverheid, l’identità digitale DigiD, il sito della camera bassa del parlamento, il centro nazionale di cybersicurezza e diversi sistemi scolastici. Fortune segnala Archive.org temporaneamente fuori servizio. Il National Cyber Security Centre britannico ha detto alle organizzazioni del Regno Unito di aggiornare subito o spegnere i sistemi con PHP finché non possono farlo.

Dall’altra parte, Cloudflare, che protegge milioni di siti, aveva già messo regole di firewall contro i metodi di attacco noti. Il suo CTO, Dane Knecht, ha confermato prima del rilascio delle patch che vedeva «i primi attacchi emergere» e che stavano aggiornando le protezioni «man mano che compaiono nuovi vettori». Protezioni temporanee, ha precisato: aggiornare resta l’unica cosa che conta.

Onestà sui numeri: nelle fonti raccolte fino alle 8 di stamattina, 22 ottobre, nessuna fonte indipendente aveva confermato una violazione riuscita. Il che non esclude intrusioni non ancora documentate. The Hacker News lo dice chiaro, e aggiunge che la società watchTowr, che ha riprodotto la prima falla, non vedeva sfruttamento in corso alle 11:26 UTC del 21 ottobre. Fortune riporta il racconto di un imprenditore che dice di aver subito un furto di codice e documenti, ma è un racconto di parte, non una conferma. Quindi: attacchi tentati sì, attacchi riusciti non dimostrati. Quanto vantaggio resti ai difensori, da qui in poi, nessuno lo sa.

Cosa fare oggi, in ordine

Niente panico, ma niente rinvii. La sequenza è questa.

1. Prima un backup. Le guide di Patch the Planet di OpenAI mettono backup e ripristino fra le cose da curare insieme alle patch: ti serve per tornare indietro se l’aggiornamento rompe qualcosa e per ripartire se scopri che qualcuno era già entrato.
2. Scopri che versione di PHP usa il tuo sito. Dentro WordPress: Strumenti, Salute del sito, scheda Informazioni, voce Server. Oppure nel pannello del tuo hosting, dove quasi sempre c’è una voce chiamata «versione PHP» o simile. Se la versione è 8.5.12, 8.4.27, 8.3.36 o 8.2.35, queste due falle sono chiuse. Se è più bassa, vai avanti, con una cautela: il fornitore potrebbe aver applicato la correzione lasciando un numero di versione più vecchio, quindi chiedigli conferma delle patch per entrambe le CVE.
3. Aggiorna PHP dal pannello dell’hosting. Molti hosting condivisi permettono di scegliere il ramo di PHP con un menu. Scegli una versione corretta e, fra queste, un ramo che resti supportato a lungo: 8.3, 8.4 o 8.5. The Hacker News ricorda due cose che il pannello a volte fa da solo e a volte no: dopo l’aggiornamento vanno riavviati i processi PHP, e la correzione aggiunge un nuovo limite rigido di memoria, quindi vanno ricontrollate le impostazioni memory_limit e post_max_size. Poi apri il sito e controlla le pagine principali.
4. Se la versione corretta non compare nel menu, scrivi all’hosting oggi. Chiedi, con queste parole: «Avete applicato le patch PHP2Shell (CVE-2026-109618 e CVE-2026-109619) sul mio hosting? Su quale versione di PHP gira il mio sito?». Un fornitore serio ha già una risposta pronta. Un fornitore che non sa di cosa parli ti ha appena detto una cosa importante su di sé.
5. Se sei su PHP 8.1 o più vecchio, il problema è doppio. Quelle versioni non ricevono più aggiornamenti dal progetto PHP. Il team ha pubblicato correzioni minime per 7.4, 8.0 e 8.1 per chi compila da sé o aspetta il fornitore, ma per un sito normale la strada è una: salire a una versione supportata. Era già in ritardo prima di ieri.
6. Attenzione alla data di scadenza. PHP 8.2 smette di ricevere correzioni di sicurezza il 31 dicembre 2026. La 8.2.35 chiude PHP2Shell, ma dal primo gennaio quel ramo resterà fermo davanti alla prossima falla: applica la patch oggi e pianifica con chi gestisce il sito il passaggio a 8.3, 8.4 o 8.5.
7. Se non puoi aggiornare subito, riduci l’esposizione, sapendo che non basta. Il team PHP indica due impostazioni: memory_limit a -1, fissato in modo che le applicazioni non possano cambiarlo, e session.upload_progress.enabled a 0 con riavvio dei processi. Ma lo scrive nelle note di ogni versione: «non esistono mitigazioni complete, aggiornare è l’unica scelta sicura». Una sviluppatrice del core, Gina Peter Banyard, ha risposto a chi proponeva quell’impostazione come rimedio: «l’unica mitigazione è aggiornare PHP. Purtroppo ne so troppo».
8. Se sospetti un’intrusione, fai controllare i segnali. Wiz suggerisce di cercare richieste di caricamento file insolite seguite da errori di memoria o da errori 500 ripetuti, cookie di risposta PHPSESSID insolitamente grandi o malformati, riavvii inspiegabili dei processi PHP. Sono tracce da tecnico; se non sai leggerle, chiedi a chi gestisce il tuo server di guardarle.

Una trappola che The Hacker News segnala: le distribuzioni Linux e i fornitori con supporto esteso hanno ricevuto le patch in anticipo, e un pacchetto può contenere la correzione pur mostrando un numero di versione vecchio. Chi amministra il server lo controlla nel registro delle modifiche del pacchetto, cercando la sigla CVE, non il numero; chi è su un hosting lo chiede al fornitore.

Come portarlo nel tuo lavoro

Chi mi legge non fa il sistemista. Fa il commercialista, l’artigiano, il consulente, la titolare di un negozio con un sito che qualcuno ha fatto anni fa e che «funziona». Allora la domanda è un’altra: cosa cambia nel modo in cui gestisci il tuo sito, da oggi.

Primo: il sito ha un proprietario, e sei tu. L’agenzia lo ha costruito, l’hosting lo ospita, il nipote lo aggiorna. Ma il nome sopra il sito, quello che i tuoi clienti leggono mentre lasciano i loro dati, è il tuo. Oggi è il giorno giusto per scoprire chi, fra tutte queste persone, ha il compito di aggiornare PHP. Se la risposta è «nessuno, mai pensato», hai trovato il problema vero, e PHP2Shell è solo il modo in cui si è fatto vedere.

Secondo: la manutenzione ha un prezzo, e adesso sai cosa compri. La voce «manutenzione annuale» è spesso la prima a sparire da un preventivo. Chiedi a chi te la propone cosa comprende: se dentro c’è «aggiornamento di PHP e controllo delle versioni», ha un valore che ieri non riuscivi a vedere. Se dentro c’è solo «aggiornamento plugin», ora sai che manca il pezzo sotto.

Terzo, ed è il punto che mi interessa di più: la sicurezza è diventata una questione di velocità. Per anni l’idea era: prima o poi aggiorno, come per la falla di Windows di due settimane fa. OpenAI prevede che le scoperte di questo tipo aumentino bruscamente nei prossimi mesi, e per queste due falle tutte le fonti dicono la stessa parola: subito. L’abitudine da costruire va oltre l’aggiornamento di oggi: è avere qualcuno che aggiorna sempre, e che davanti a una falla così lo fa il giorno stesso, senza che tu debba leggere Fortune per saperlo.

Quarto: se lavori per clienti, questa è anche una notizia da comunicare. Un messaggio ai tuoi clienti con sito, oggi, che dice «c’è una falla grave in PHP, ho controllato il tuo sito, è aggiornato» vale più di dieci post sull’intelligenza artificiale. Chi si fa vivo prima della paura costruisce fiducia. Chi si fa vivo dopo, la ripara.

Un’ultima nota, sul lato buono della storia. Le stesse aziende che vendono AI l’hanno usata per trovare la falla, per quanto ne sanno, prima dei criminali, e hanno impiegato due mesi a coordinare correzioni, firewall e avvisi ai governi prima di dirlo al mondo. OpenAI dice di aver impegnato un miliardo di dollari per offrire accesso sovvenzionato a Daybreak, il suo strumento di sicurezza, alle organizzazioni che proteggono servizi essenziali con pochi mezzi. Puoi leggerla come generosità o come marketing: la mia lettura è che hanno capito che il prossimo PHP2Shell lo troverà qualcun altro, e vogliono essere ancora loro.

Le fondamenta, dice Brockman, erano crepate da quattordici anni. L’AI ha solo acceso la luce. Il resto è una telefonata al tuo hosting.

👉 Leggi anche: Microsoft 365: l’attacco lo guida un agente AI

Domande frequenti

Cos’è PHP2Shell?

È il nome dato a due falle critiche di PHP, CVE-2026-109618 e CVE-2026-109619, rese note il 21 ottobre 2026. Permettono a un attaccante senza credenziali di eseguire codice sul server o di leggere la memoria del processo PHP, dove possono esserci password e chiavi. Le hanno scoperte Calif, Wiz e OpenAI con l’aiuto di modelli AI.

Il mio sito WordPress è a rischio?

Se gira su una versione di PHP senza la correzione, sì. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; il fornitore può però aver applicato la correzione lasciando un numero di versione più vecchio, quindi in caso di dubbio chiedi conferma delle patch per entrambe le CVE. La falla è in PHP, non in WordPress: avere WordPress e i plugin aggiornati non basta. Controlla la versione in Salute del sito o nel pannello dell’hosting e aggiorna da lì.

Come aggiorno PHP se sono su un hosting condiviso?

Molti hosting condivisi permettono di scegliere la versione di PHP da un menu nel pannello di controllo. Se le versioni corrette non compaiono, scrivi al fornitore chiedendo se ha applicato le patch PHP2Shell. Se ti dice di no e non sa quando, è il momento di valutare un altro hosting.

Ci sono già stati attacchi?

Cloudflare ha confermato di vedere i primi tentativi di attacco già prima del rilascio delle patch. Al 21 ottobre nessuna fonte indipendente aveva confermato una violazione riuscita. Diverse organizzazioni, fra cui servizi pubblici olandesi e BambooHR, hanno spento i sistemi per precauzione.

Basta cambiare un’impostazione invece di aggiornare?

No. Il team PHP indica alcune impostazioni che riducono l’esposizione a certi percorsi d’attacco, ma scrive che non esistono mitigazioni complete: aggiornare è l’unica scelta sicura. L’impostazione sul caricamento dei file che era circolata prima della patch blocca solo alcune varianti.

Fonti

• PHP.net, annuncio ufficiale delle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35, 21 ottobre 2026
• Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, 21 ottobre 2026
• OpenAI, Patch the Planet: global response coordination as agents uncover critical vulnerabilities, 21 ottobre 2026
• OpenAI su X, il post dell’annuncio, 21 ottobre 2026
• BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws, 21 ottobre 2026
• The Hacker News, PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge, 21 ottobre 2026
• Fortune, AI tools discovered the PHP vulnerability that could take down 70% of the internet, 21 ottobre 2026