Allerta sicurezza · aggiornato il 22 ottobre 2026

PHP2Shell: una falla critica di PHP può consegnare il tuo sito a uno sconosciuto.

Q: Cos’è PHP2Shell?

È il nome dato a due vulnerabilità critiche di PHP, CVE-2026-109618 e CVE-2026-109619, pubblicate il 20 ottobre 2026. Permettono a chiunque di eseguire codice sul server senza password, mandando una richiesta costruita apposta. Hanno gravità 9.2 su 10 nella scala CVSS v4.0.

Q: Il mio sito WordPress è vulnerabile?

Se gira su una versione di PHP precedente a 8.2.35, 8.3.36, 8.4.27 o 8.5.12, sì. Il problema non è in WordPress né nei plugin ma nell’interprete PHP che li esegue, quindi aggiornare WordPress non basta: va aggiornato PHP sul server o sull’hosting.

Q: Quali sono le versioni di PHP corrette?

PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, rilasciate il 21 ottobre 2026. Per PHP 8.1, 8.0 e 7.4 il progetto ha pubblicato solo patch sorgente minime, che alcune distribuzioni Linux applicano senza cambiare il numero di versione. Per le versioni più vecchie non esiste correzione.

Q: Ho un hosting condiviso: devo fare qualcosa?

Sì, almeno controllare. Molti hosting aggiornano in automatico le versioni minori, ma se nel pannello hai scelto a mano un ramo vecchio come 7.4 o 8.0 resti su quello. Entra nel pannello, guarda la versione PHP impostata per ogni sito e, se è fuori supporto, passa a 8.3 o successiva dopo aver verificato che il sito funzioni.

Q: Basta aggiornare WordPress e i plugin?

No. Gli aggiornamenti di WordPress cambiano i file PHP del sito, non l’interprete che li esegue. La falla è nel modo in cui PHP gestisce la memoria durante le richieste, prima ancora che il codice di WordPress parta.

Q: Il controllo automatico di questa pagina è affidabile?

Dice la verità su quello che il server dichiara pubblicamente. Molti server nascondono la versione di PHP, ed è una buona pratica: in quel caso il controllo te lo segnala e la verifica va fatta dal pannello o dal server. Ogni risultato lo guardo comunque anche io prima di risponderti.

Q: Posso proteggermi senza aggiornare PHP?

Solo in parte e solo per pochi giorni. Disattivare session.upload_progress, impostare memory_limit a -1 con limiti a livello di container e limitare la dimensione delle richieste riduce l’esposizione a vettori specifici. Il progetto PHP e CISA sono chiari: l’unica correzione completa è l’aggiornamento.

Q: Come capisco se il mio sito è già stato attaccato?

Nei log cerca errori “Allowed memory size exhausted” con “Unknown on line 0”, crash dei processi con “Segmentation fault” e richieste POST di diversi megabyte con nomi di campo enormi. Il segnale più grave è un processo del web server che avvia una shell. Se trovi uno di questi indizi, aggiornare non basta: serve una bonifica.

Q: Quanto costa sistemare un sito vulnerabile?

Se il sito gira già su un ramo supportato, l’aggiornamento è spesso questione di minuti. Se invece è fermo a PHP 7.4 o 8.0, il lavoro vero è rendere compatibili codice, tema e plugin. Lavoro a 80 € più IVA all’ora per gli interventi brevi e a preventivo fisso sui lavori più lunghi, sempre concordato prima di iniziare.

Q: Gestisco molti siti per i miei clienti: come procedo?

Parti dall’inventario: per ogni sito annota hosting, versione PHP e chi può aggiornarla. Metti in cima quelli con PHP fuori supporto e quelli con dati di clienti o pagamenti. Se ti serve una mano a fare il giro di un portafoglio di siti, scrivimi l’elenco e ti dico come lo affronterei.

Due vulnerabilità appena pubblicate permettono di eseguire comandi sul server di un sito PHP senza password. Riguardano WordPress, WooCommerce, PrestaShop, Joomla, Laravel e qualsiasi gestionale scritto in PHP. Inserisci l’indirizzo del tuo sito: controllo la versione che dichiara e ti dico se sei esposto.

VulnerabilitàCVE-2026-109618
CVE-2026-109619

Gravità9.2 su 10
CVSS v4.0

Serve una password?No
basta una richiesta web

Già sfruttata?Sì
attacchi attivi dal 17 ottobre

Versioni corrette

Quale PHP hai e cosa devi fare.

Il progetto PHP ha rilasciato le correzioni il 21 ottobre 2026. Se la tua versione è più bassa di quella in tabella, il sito è esposto.

Ramo	Prima versione corretta	Supporto	Cosa fare
PHP 8.5	`8.5.12`	Supportato fino al 2029	Aggiorna a 8.5.12
PHP 8.4	`8.4.27`	Supportato fino al 2028	Aggiorna a 8.4.27
PHP 8.3	`8.3.36`	Solo sicurezza fino al 2027	Aggiorna a 8.3.36
PHP 8.2	`8.2.35`	Solo sicurezza fino al 31/12/2026	Aggiorna ora e pianifica il passaggio a 8.4
PHP 8.1, 8.0, 7.4	`Solo patch sorgente`	Fuori supporto	Verifica il backport della distribuzione, poi migra
PHP 7.3 e precedenti	`Nessuna`	Fuori supporto	Migra a un ramo supportato o metti offline

Attenzione ai pacchetti di Ubuntu, Debian e Red Hat: spesso correggono la falla lasciando invariato il numero di versione. Una stringa come 8.1.2-1ubuntu2.x può essere già sistemata oppure no, e si scopre solo leggendo il changelog del pacchetto.

Cos’è successo

Il problema non è nel tuo sito. È nel motore che lo fa girare.

PHP è il linguaggio che esegue circa tre siti su quattro tra quelli di cui si conosce la tecnologia. Ogni volta che qualcuno apre una pagina, PHP riceve la richiesta, prepara la memoria, esegue il codice del sito e poi fa pulizia. PHP2Shell colpisce proprio la preparazione e la pulizia: due momenti in cui il codice di WordPress o del tuo gestionale non è ancora partito, o ha già finito.

La prima falla, CVE-2026-109618, sfrutta l’esaurimento della memoria mentre PHP legge una richiesta POST: PHP si interrompe lasciando una struttura a metà, e la routine di pulizia la tratta come valida. La seconda, CVE-2026-109619, sfrutta uno stato interno che sopravvive alla richiesta precedente e viene riusato da quella successiva sullo stesso processo. In entrambi i casi chi attacca riesce a far eseguire al server un comando suo.

Tradotto: il login del sito, il plugin di sicurezza e la password lunga dell’amministratore non servono. L’attacco avviene prima che entrino in gioco. Per questo la gravità è così alta e per questo CISA ha chiesto di mettere offline i sistemi che non si possono aggiornare.

Chi è esposto

Se il sito risponde con PHP, sei nel perimetro.

Siti WordPress, WooCommerce, Joomla, Drupal e PrestaShop su qualsiasi hosting.
Applicazioni Laravel, Symfony, CodeIgniter e gestionali PHP fatti su misura.
Server con Apache e mod_php: è la configurazione in cui il rischio è più alto.
Server con PHP-FPM, php-cgi, LiteSpeed o FrankenPHP: esposti anche loro.
Container Docker con immagini php: non ricostruite dopo il 21 ottobre.
Siti dimenticati: la vecchia landing, lo staging rimasto online, il blog che nessuno aggiorna più.

Verifica da solo

Quattro modi per scoprire la versione vera.

Il controllo automatico vede solo quello che il server dichiara. Se la versione è nascosta, ecco dove guardare.

Dal pannello dell’hosting

In cPanel cerca “Seleziona versione PHP” o “MultiPHP Manager”, in Plesk vai su “Impostazioni PHP” del dominio. Sui pannelli degli hosting italiani la voce sta di solito sotto “Hosting” o “Configurazione PHP”.

Da WordPress

Vai su Strumenti, Salute del sito, Informazioni, Server. Trovi la versione di PHP che sta davvero eseguendo il sito, non quella installata da qualche altra parte sul server.

Con un file temporaneo

Carica nella cartella del sito un file con <?php echo PHP_VERSION;, aprilo dal browser, annota la versione e cancellalo subito. Non usare phpinfo() lasciato online: regala informazioni a chi attacca.

Dal server

php -v mostra la versione da riga di comando, che può essere diversa da quella del web server. Controlla anche php-fpm -v e, su Debian o Ubuntu, il changelog del pacchetto per vedere se il backport è arrivato.

La prossima ora

Cosa fare adesso, in ordine.

Fai l’elenco dei siti. Tutti, compresi staging, vecchie landing e sottodomini. Quello dimenticato è quello che ti frega.
Annota la versione PHP di ognuno. Usa il controllo qui sopra o uno dei quattro metodi.
Fai un backup completo. File e database, salvato fuori dal server. Prima di aggiornare, non dopo.
Aggiorna i rami supportati. 8.2, 8.3, 8.4 e 8.5 si aggiornano alla versione corretta senza cambiare ramo: il rischio di rompere il sito è basso.
Riavvia PHP-FPM o Apache. Finché i processi vecchi restano vivi, la versione vulnerabile continua a rispondere.
Per 8.1 e precedenti, decidi oggi. Migrazione pianificata, backport verificato o sito offline. Restare così com’è non è una delle opzioni.

Mitigazione temporanea

Se oggi proprio non puoi aggiornare

Queste impostazioni riducono l’esposizione a vettori noti. Non sono una correzione: comprano qualche giorno, non di più.

; php.ini, poi riavvia tutti i worker
session.upload_progress.enabled = 0
; solo PHP 8.5
fatal_error_backtraces = 0
; limite di memoria gestito dal container
memory_limit = -1
post_max_size = 2M

Aggiungi un limite alla dimensione delle richieste sul proxy o sul WAF e un limite di memoria al container. Non usare RLIMIT_AS.

Sei già stato colpito?

I segni da cercare nei log.

Nessuno di questi indizi da solo prova un attacco. Due insieme, sullo stesso orario, meritano un’analisi.

Errori Allowed memory size … exhausted con Unknown on line 0: PHP è andato in crisi prima di eseguire il sito.
Righe AH00052: child pid … exit signal Segmentation fault (11) nel log di Apache: spesso un tentativo fallito.
Richieste POST application/x-www-form-urlencoded di diversi megabyte con un nome di campo enorme.
Un processo apache2, php-fpm o www-data che avvia sh, bash, curl o wget.
File PHP nuovi in wp-content/uploads, utenti amministratori che non riconosci, cron job comparsi dal nulla.

Se ne trovi, aggiornare PHP chiude la porta ma non caccia chi è già entrato. Qui spiego come bonifico un sito compromesso →

Il punto vero

Aggiornare PHP non è sempre un clic.

Se il tuo sito gira già su PHP 8.2 o successivo, l’aggiornamento è una release di correzione: lo fa l’hosting o si fa in pochi minuti sul server, e il sito non se ne accorge.

Il problema sono i siti fermi a PHP 7.4, 8.0 o 8.1. Lì il salto è di ramo, e tra un ramo e l’altro PHP cambia funzioni, avvisi e comportamenti. Un tema comprato nel 2019, un plugin abbandonato, un gestionale scritto anni fa: è lì che il sito si rompe, con la pagina bianca o il famoso “errore critico”.

Il modo sicuro è sempre lo stesso: copia del sito in un ambiente di prova, aggiornamento di PHP lì, verifica dei flussi importanti come contatti, carrello e pagamento, correzione di quello che si rompe, poi passaggio in produzione con un backup pronto. È il lavoro che faccio ogni settimana, e ti dico prima quanto costa.

Cronologia

Come è andata, giorno per giorno.

17 ottobre 2026
AWS segnala i primi tentativi di sfruttamento, quattro giorni prima della divulgazione pubblica.
20 ottobre 2026
Il progetto PHP annuncia un rilascio di sicurezza per il giorno dopo alle 14:00 UTC e divulga le due vulnerabilità.
21 ottobre 2026
Escono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, più le patch minime per 8.1, 8.0 e 7.4. CISA chiede di aggiornare immediatamente, watchTowr e Datadog segnalano attacchi attivi e scansioni a tappeto.
22 ottobre 2026
Pubblico questa pagina con il controllo gratuito della versione PHP dichiarata dal tuo sito.

Come posso aiutarti

Dal controllo alla correzione, con il prezzo prima.

Controllo gratuito

Usi il form in cima alla pagina, guardo il risultato e ti rispondo entro 24 ore lavorative con cosa fare.

Controlla il sito →

Aggiornamento e verifica

Aggiorno PHP sul ramo supportato, riavvio i servizi e verifico che il sito risponda come prima. Di solito resta dentro un’ora di lavoro.

Migrazione da PHP vecchio

Porto il sito da 7.4, 8.0 o 8.1 a un ramo supportato, sistemando tema, plugin e codice in un ambiente di prova prima di toccare la produzione.

Assistenza WordPress →

Bonifica dopo un attacco

Se qualcuno è già entrato, cerco cosa ha lasciato, chiudo gli accessi, ripulisco e rimetto online un sito di cui ti puoi fidare.

Sito compromesso →

80 € più IVA all’ora per gli interventi brevi, preventivo fisso sulle migrazioni. Il prezzo lo sai prima di dirmi di sì.

Domande frequenti

Le domande che mi state facendo in questi giorni.

Cos’è PHP2Shell?

È il nome dato a due vulnerabilità critiche di PHP, CVE-2026-109618 e CVE-2026-109619, pubblicate il 20 ottobre 2026. Permettono a chiunque di eseguire codice sul server senza password, mandando una richiesta costruita apposta. Hanno gravità 9.2 su 10 nella scala CVSS v4.0.

Il mio sito WordPress è vulnerabile?

Se gira su una versione di PHP precedente a 8.2.35, 8.3.36, 8.4.27 o 8.5.12, sì. Il problema non è in WordPress né nei plugin ma nell’interprete PHP che li esegue, quindi aggiornare WordPress non basta: va aggiornato PHP sul server o sull’hosting.

Quali sono le versioni di PHP corrette?

PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, rilasciate il 21 ottobre 2026. Per PHP 8.1, 8.0 e 7.4 il progetto ha pubblicato solo patch sorgente minime, che alcune distribuzioni Linux applicano senza cambiare il numero di versione. Per le versioni più vecchie non esiste correzione.

Ho un hosting condiviso: devo fare qualcosa?

Sì, almeno controllare. Molti hosting aggiornano in automatico le versioni minori, ma se nel pannello hai scelto a mano un ramo vecchio come 7.4 o 8.0 resti su quello. Entra nel pannello, guarda la versione PHP impostata per ogni sito e, se è fuori supporto, passa a 8.3 o successiva dopo aver verificato che il sito funzioni.

Basta aggiornare WordPress e i plugin?

No. Gli aggiornamenti di WordPress cambiano i file PHP del sito, non l’interprete che li esegue. La falla è nel modo in cui PHP gestisce la memoria durante le richieste, prima ancora che il codice di WordPress parta.

Il controllo automatico di questa pagina è affidabile?

Dice la verità su quello che il server dichiara pubblicamente. Molti server nascondono la versione di PHP, ed è una buona pratica: in quel caso il controllo te lo segnala e la verifica va fatta dal pannello o dal server. Ogni risultato lo guardo comunque anche io prima di risponderti.

Posso proteggermi senza aggiornare PHP?

Solo in parte e solo per pochi giorni. Disattivare session.upload_progress, impostare memory_limit a -1 con limiti a livello di container e limitare la dimensione delle richieste riduce l’esposizione a vettori specifici. Il progetto PHP e CISA sono chiari: l’unica correzione completa è l’aggiornamento.

Come capisco se il mio sito è già stato attaccato?

Nei log cerca errori “Allowed memory size exhausted” con “Unknown on line 0”, crash dei processi con “Segmentation fault” e richieste POST di diversi megabyte con nomi di campo enormi. Il segnale più grave è un processo del web server che avvia una shell. Se trovi uno di questi indizi, aggiornare non basta: serve una bonifica.

Quanto costa sistemare un sito vulnerabile?

Se il sito gira già su un ramo supportato, l’aggiornamento è spesso questione di minuti. Se invece è fermo a PHP 7.4 o 8.0, il lavoro vero è rendere compatibili codice, tema e plugin. Lavoro a 80 € più IVA all’ora per gli interventi brevi e a preventivo fisso sui lavori più lunghi, sempre concordato prima di iniziare.

Gestisco molti siti per i miei clienti: come procedo?

Parti dall’inventario: per ogni sito annota hosting, versione PHP e chi può aggiornarla. Metti in cima quelli con PHP fuori supporto e quelli con dati di clienti o pagamenti. Se ti serve una mano a fare il giro di un portafoglio di siti, scrivimi l’elenco e ti dico come lo affronterei.

Fonti

Da dove vengono i dati di questa pagina.

Aggiorno questa pagina man mano che escono nuove informazioni. Ultimo aggiornamento: 22 ottobre 2026.

Non aspettare di scoprirlo dai log

Mandami l’indirizzo del sito. Ti dico se sei esposto e cosa costa sistemarlo.

Rispondo io, non un sistema automatico. Se preferisci, scrivimi su WhatsApp o chiamami al +39 352 020 3538.

Sfidami →