PHP2Shell, l'attacco è confermato: 35 shell sulle esche. Cosa deve fare chi ha un sito PHP o WordPress

Risposta diretta: PHP2Shell non è più un rischio teorico. Il 24 ottobre 2026 un ricercatore ha documentato 35 esecuzioni di comandi riuscite su tre server esca con PHP 8.4.26. Se il tuo sito gira su PHP, e WordPress, Joomla, Drupal, WooCommerce e PrestaShop girano su PHP, oggi devi fare tre cose: controllare la versione, aggiornare a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o farti confermare per iscritto dall’hosting che la correzione c’è), e disattivare session.upload_progress. Aggiornare WordPress o i plugin non serve: il difetto è in PHP.

Sono Andrea Baglioni, realizzo siti e gestisco server per PMI a Perugia e in tutta Italia. Non sono un’azienda di sicurezza informatica: questo articolo mette in fila cosa è confermato e cosa no, e cosa deve fare chi ha un sito. Numeri, date e versioni li ho riletti il 26 ottobre 2026 sulle fonti originali: gli avvisi di PHP, l’alert dell’Agenzia per la Cybersicurezza Nazionale (ACN) e il report del ricercatore.

Cosa è successo il 24 ottobre, e cosa non è successo

Adel Karimi, ricercatore di Perplexity, tiene in rete alcuni honeypot: server esca che sembrano normali siti PHP e registrano tutto quello che ricevono. Configurazione: PHP 8.4.26, cioè l’ultima versione 8.4 prima della correzione, con Apache e mod_php e un solo processo di lavoro. Il 24 ottobre ha pubblicato il report con le prove.

I numeri, così come li riporta:

• 35 shell aperte su 3 server esca. Per ognuna c’è la richiesta HTTP completa catturata in rete e, nello stesso istante, un /bin/sh avviato da un processo di Apache con l’utente del web server (Tetragon, lo strumento che osserva i processi dal kernel, l’ha registrato). Non sono crash scambiati per attacchi: è esecuzione di comandi.
• 2 indirizzi di origine. Il 15.204.59.70 ha ottenuto 3 shell su un server; il 162.35.99.94 ne ha ottenute 32 su tutti e tre. Il report precisa che sono due gruppi di indirizzi, non due attori: chi c’è dietro non si sa.
• 4 richieste per ogni attacco. Una richiesta che esaurisce la memoria di PHP, una che fa uscire un pezzo di memoria dentro un cookie di sessione enorme, un’altra che esaurisce la memoria, e l’ultima che esegue il comando calibrandosi sugli indirizzi appena ottenuti.
• Exploit pubblico. Il traffico corrisponde da vicino a un exploit già pubblicato su GitHub. Non serve un gruppo sofisticato per ripeterlo.

Cosa il report non dice, ed è scritto nel report stesso: la configurazione delle esche era volutamente favorevole all’attaccante (un solo processo di lavoro). Non misura quanto l’attacco funzioni su altre configurazioni, altre versioni o altri programmi. E sono esche: nessun sito reale risulta compromesso in quel report.

PHP2Shell in breve: due falle in PHP, più una terza

PHP2Shell è il nome dato a due vulnerabilità del motore di PHP, annunciate e corrette il 21 ottobre 2026. Sono state trovate da ricercatori di Calif.io, Wiz, OpenAI e Quarkslab. Il punto che conta per chi ha un sito: il difetto non è nel tuo codice né in WordPress, è in PHP. Wiz scrive che anche una semplice pagina “Hello World” su una versione vulnerabile può essere attaccata, e ha dimostrato l’esecuzione di codice senza login sulle immagini standard di WordPress, Drupal e Joomla.

C’è anche un effetto meno citato: Wiz ha dimostrato che un attaccante può leggere dalla memoria di PHP password, token e chiavi API, senza nemmeno arrivare a eseguire codice. Quindi, se il tuo sito è rimasto esposto, dopo l’aggiornamento conviene valutare il cambio delle password e delle chiavi usate dal sito (database, servizi di pagamento, email).

Le versioni corrette sono:

La cronologia, con le date

La frase di Amazon che terrei a mente: chi difende i sistemi non deve dare per scontato che la data della divulgazione pubblica sia la prima data di sfruttamento. Tradotto: se il tuo sito era esposto dal 17 ottobre, l’aggiornamento chiude la porta ma non ti dice se qualcuno è già entrato.

I numeri sull’Italia, letti con attenzione

Il 25 ottobre ACN ha pubblicato un nuovo alert con i dati del CSIRT Italia. La frase esatta: su 741.523 servizi PHP rilevati in Italia, 285.149 risultano utilizzare versioni potenzialmente vulnerabili, pari all’81,9% dei servizi per i quali è stato possibile identificare la versione.

Molti titoli l’hanno riassunta come “l’81,9% dei servizi PHP italiani è vulnerabile”. Non è quello che dice ACN, e la differenza conta:

• L’81,9% riguarda solo i servizi di cui si conosce la versione. Facendo il conto inverso, la versione era identificabile per circa 348.000 servizi, meno della metà di quelli rilevati. Il calcolo è mio, sui numeri di ACN.
• 285.149 su 741.523 è il 38,5% del totale rilevato. Gli altri servizi non è che siano sicuri: semplicemente non si vede la versione. VirusTotal, a livello mondiale, stima che circa 4 server PHP su 5 non la mostrino.
• Un “servizio” non è un sito. È un punto del server raggiungibile da internet: su un hosting condiviso un solo servizio può servire centinaia di siti, e un sito può comparire su più servizi.
• Il conto può includere server già corretti. Lo scrive ACN: alcune distribuzioni applicano la correzione senza cambiare il numero di versione.

Una testata ha scritto che “solo il 18% circa” ha aggiornato. Il numero corrisponde a 100 meno 81,9: è il complemento dello stesso dato, non una rilevazione separata, e per i motivi sopra non dice con precisione quanti hanno aggiornato.

Il succo resta quello di ACN: l’esposizione in Italia è alta e gli aggiornamenti vanno accelerati. L’Agenzia chiede di aggiornare subito, disattivare session.upload_progress.enabled, mettere i firewall applicativi (WAF) in modalità blocco dove hanno regole specifiche e, se non ci sono misure efficaci, valutare di mettere offline i servizi.

Il tuo sito è esposto? Il controllo in cinque minuti

1. Capisci se il sito usa PHP. WordPress, WooCommerce, Joomla, Drupal, PrestaShop, Magento: sì. Un sito statico (generato con Astro, Hugo o simili) o un sito su piattaforme come Shopify o Wix non dipende dal PHP che gestisci tu.
2. Leggi la versione. In WordPress: Strumenti, Salute del sito, scheda Info, sezione Server. Oppure dal pannello dell’hosting: in cPanel di solito è Select PHP Version o MultiPHP Manager.
3. Confronta con la tabella sopra. Prima di 8.5.12, 8.4.27, 8.3.36 o 8.2.35 vuol dire esposto, salvo conferma contraria del fornitore. 8.1, 8.0, 7.4 o più vecchie: esposto e senza correzione ufficiale.
4. Chiedi all’hosting. Il numero di versione può ingannare in entrambe le direzioni. La conferma deve arrivare da chi gestisce il server.
5. Guarda se hai altri siti o applicazioni PHP. Un vecchio sito dimenticato, un’area riservata, un gestionale con interfaccia web: PHP va aggiornato ovunque sia raggiungibile da internet.

Cosa fare, in ordine

1. Aggiorna PHP a una versione corretta. Su hosting condiviso di solito basta selezionare la versione dal pannello. Prima prova il sito su una copia di prova, se ce l’hai: un salto da 7.4 a 8.x può rompere temi e plugin vecchi.
2. Riavvia tutti i processi PHP. Su un server o VPS l’aggiornamento non vale finché i processi vecchi restano in memoria. Se usi container, ricostruisci l’immagine: correggere solo il container in esecuzione lascia esposta l’immagine.
3. Disattiva l’upload progress delle sessioni. session.upload_progress.enabled=0 in php.ini o nella configurazione del server, poi riavvio. PHP stesso lo consiglia fino alla prossima release, per la terza falla senza patch. È una funzione che quasi nessun sito usa. Su hosting condiviso, se il pannello non permette di cambiarla, chiedilo all’assistenza.
4. Se hai un WAF, attiva le regole specifiche. Cloudflare, per esempio, ha regole dedicate, ma scrive che coprono solo i siti che usano il nome predefinito del campo di upload progress. Il WAF riduce il rischio, non sostituisce l’aggiornamento.
5. Se sei su 8.1 o precedente, pianifica il passaggio a una versione supportata. Se servono settimane, chiedi al fornitore una correzione applicata alla tua versione. Se non è possibile, ACN dice di valutare di mettere il sito offline fino all’aggiornamento: è drastico, ma per un e-commerce con dati dei clienti va considerato sul serio.
6. Controlla i log da metà ottobre. ACN raccomanda un’analisi a ritroso. Le tracce indicate da ACN e dal report Karimi sono qui sotto.
7. Cambia password e chiavi se il sito è rimasto esposto: utenti del database, chiavi API, credenziali SMTP. La falla può far uscire dati dalla memoria anche senza eseguire codice.

Cosa cercare nei log

Se gestisci tu il server, o puoi chiederli all’hosting:

• errori PHP del tipo Allowed memory size of ... bytes exhausted con in Unknown on line 0, soprattutto se ripetuti e ravvicinati;
• processi di Apache o PHP terminati con Segmentation fault, magari a raffica;
• richieste POST multipart molto pesanti (nel report fino a circa 33 MB), senza User-Agent, seguite da cookie di sessione enormi;
• processi sh, curl o wget avviati dal web server, connessioni in uscita che non ti aspetti, file del sito modificati.

Un dettaglio del report: nell’ultima richiesta dell’attacco il processo di Apache muore subito dopo aver aperto la shell, quindi nel registro degli accessi quella riga manca. Cercare solo gli errori 500 non basta.

Se trovi segnali di compromissione, aggiornare non basta: il sito va controllato da capo (file, utenti amministratori, attività pianificate) oppure ripristinato da un backup precedente al 17 ottobre e poi aggiornato.

Le tre domande da fare al tuo hosting

Copia e incolla, se vuoi:

1. “La versione PHP del mio sito contiene la correzione per CVE-2026-109618 e CVE-2026-109619? Se il numero di versione non è 8.5.12, 8.4.27, 8.3.36 o 8.2.35, me lo confermate per iscritto?”
2. “Avete disattivato session.upload_progress.enabled, come raccomandano PHP e ACN per CVE-2026-115560?”
3. “Avete trovato nei log del mio spazio segnali di tentativi di sfruttamento dal 17 ottobre in poi?”

Un hosting serio risponde in giornata. Se la risposta è vaga, o se scopri che il tuo sito gira ancora su PHP 7.4 senza che nessuno te l’abbia detto, è un’informazione utile anche per il futuro.

Il mio caso, com’è oggi

Questo sito è generato con Astro: le pagine che leggi sono file HTML già pronti, non passano da PHP a ogni visita. Per questo PHP2Shell non lo tocca. Non lo dico per vantarmene: un sito statico ha altri limiti (niente area riservata o carrello senza servizi esterni) e non protegge il resto, cioè email, gestionale, altre applicazioni sullo stesso server. Per i siti vetrina e aziendali è la strada che consiglio, perché toglie di mezzo PHP, database e plugin da aggiornare; quando conviene e quando no lo spiego in WordPress o Astro: quando cambiare sito.

Per chi deve restare su WordPress, per esempio per un e-commerce WooCommerce, la lezione di questa settimana è un’altra: serve qualcuno che sappia su che versione di PHP gira il sito e che possa aggiornarla in giornata. Su un server o una VPS gestita quel qualcuno deve esserci per contratto, non per buona volontà.

Cosa non sappiamo ancora

• Quanti siti reali siano stati compromessi: nessun numero pubblico affidabile.
• Quanto l’attacco funzioni su configurazioni diverse da quella delle esche (più processi di lavoro, PHP-FPM, versioni diverse). PHP considera esposte tutte le installazioni che rispondono a richieste web, con il rischio più alto per mod_php.
• Chi ci sia dietro gli indirizzi del report e come qualcuno avesse informazioni sull’exploit già il 17 ottobre.
• Quando arriverà la correzione per CVE-2026-115560: PHP dice “con la prossima release ordinaria”.

Aggiornerò questo articolo quando escono dati nuovi.

Il prossimo passo

Se non sai su che versione di PHP gira il tuo sito, o l’hosting non ti risponde, in 20 minuti guardiamo insieme versione, configurazione e cosa chiedere al fornitore. Scrivimi dai contatti o su WhatsApp.

Per approfondire:

• Siti web per PMI: come li costruisco e cosa costano
• Server e VPS gestiti: aggiornamenti, backup e monitoraggio
• WordPress o Astro: quando cambiare sito
• Quando rifare il sito web: i segnali da non ignorare

Domande frequenti

Il mio sito WordPress è a rischio per PHP2Shell?

Dipende dalla versione di PHP che lo fa girare, non da WordPress. Se il server usa una versione precedente a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, e il fornitore non ha applicato una correzione equivalente, va considerato esposto. Wiz ha dimostrato l’esecuzione di codice senza login su un’installazione standard di WordPress. Aggiornare WordPress o i plugin non basta: la correzione riguarda PHP.

Come controllo la versione PHP del mio sito?

Nel pannello di WordPress vai su Strumenti, Salute del sito, scheda Info, sezione Server: trovi la versione PHP. In alternativa la vedi nel pannello dell’hosting (in cPanel di solito alla voce Select PHP Version o MultiPHP Manager). Il numero da solo può ingannare, perché alcuni fornitori applicano la correzione senza cambiarlo: chiedi conferma scritta all’hosting.

Ci sono siti veri compromessi con PHP2Shell?

Al 26 ottobre 2026 non ho trovato conferme pubbliche di siti reali compromessi. Le esecuzioni di codice confermate sono le 35 shell registrate il 24 ottobre sui server esca (honeypot) del ricercatore Adel Karimi. Amazon però scrive che le falle sono ormai sfruttate su larga scala e che non è chiaro quanti attacchi vadano a segno: l’assenza di conferme non è una prova che non stia succedendo.

Disattivare session.upload_progress basta?

No. Impostare session.upload_progress.enabled=0 chiude alcune strade note e copre anche la terza falla, CVE-2026-115560, che al 26 ottobre non ha ancora una patch. Ma PHP e ACN lo indicano come misura in più, non come sostituto dell’aggiornamento. La correzione completa delle due falle principali è solo nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

Ho PHP 7.4 o 8.1: cosa faccio?

PHP non rilascia correzioni ufficiali per la 8.1 e le versioni precedenti, perché sono fuori supporto: lo ricorda anche l’alert ACN. Le strade sono due: passare a una versione supportata, provando prima il sito su una copia di prova, oppure ottenere dal fornitore la conferma scritta di una correzione applicata alla versione che usi. Se nessuna delle due è possibile in tempi brevi, ACN raccomanda di valutare di mettere il sito offline fino all’aggiornamento.

Il mio sito è su Aruba o su un altro hosting condiviso: cosa faccio?

Su un hosting condiviso, che sia Aruba, Register, SiteGround o un altro fornitore, PHP lo aggiorna il fornitore, ma spesso sei tu a scegliere quale versione usare dal pannello. Al 26 ottobre 2026 non ho trovato una comunicazione pubblica di Aruba su PHP2Shell, quindi non posso dirti se e quando ha aggiornato: va chiesto a loro. Controlla la versione in WordPress (Strumenti, Salute del sito, Info, Server), sceglila corretta dal pannello se è possibile, poi scrivi all’assistenza e chiedi tre cose: se la versione che usi contiene la correzione per CVE-2026-109618 e CVE-2026-109619, da quando, e se hanno disattivato session.upload_progress. Tieni la risposta per iscritto.