PHP2Shell: le falle critiche di PHP spiegate alle aziende, e cosa fare subito
Il 21 ottobre 2026 gli sviluppatori di PHP, il linguaggio su cui funzionano WordPress e gran parte dei siti web, hanno corretto
due vulnerabilità critiche nel suo motore.
Le falle, CVE-2026-109618 e CVE-2026-109619, sono state soprannominate PHP2Shell e hanno un punteggio di gravità
di 9.2 su 10: permettono di leggere la memoria di un server e, nei casi peggiori, di eseguirvi comandi senza alcuna password.
Le versioni sicure sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35: chi ha un sito aziendale deve verificare subito di averle.
Il punto più importante per chi gestisce un sito è questo: il problema non sta in WordPress né nei plugin, ma nel motore che li fa girare. Aggiornare il sito non basta, va aggiornato PHP sul server.
Cosa è successo
La correzione era prevista per il 22 ottobre, ma i dettagli sono trapelati in rete il giorno prima e PHP ha anticipato il rilascio di 24 ore.
Gli attacchi però erano cominciati anche prima.
| Quando (2026) | Cosa |
| 24 agosto | I ricercatori di Wiz segnalano le falle al team di sicurezza di PHP |
| 17 ottobre | Amazon registra un primo tentativo di attacco sui suoi server civetta, quattro giorni prima della divulgazione |
| 20 ottobre | I dettagli trapelano online; PHP annuncia un aggiornamento d’emergenza per il giorno dopo |
| 21 ottobre, mattina | Compaiono i primi exploit pubblici e Cloudflare segnala i primi attacchi contro i siti dei suoi clienti |
| 21 ottobre, pomeriggio | Escono le versioni corrette di PHP |
| 21–22 ottobre | Diverse società di sicurezza registrano tentativi di attacco su larga scala |
La preoccupazione è stata tale che nei Paesi Bassi alcuni servizi pubblici online, tra cui DigiD e MijnOverheid, sono stati spenti per precauzione fino all’arrivo della correzione.
Al momento non sono stati resi pubblici casi di violazioni riuscite. Amazon avverte però che, visto il tentativo del 17 ottobre, eventuali compromissioni possono essere precedenti all’avviso ufficiale.
Come funziona, in parole semplici
Un server che ospita siti in PHP usa dei «processi di lavoro» che servono una richiesta dopo l’altra, un po’ come una camera d’albergo che ospita un cliente dopo l’altro. A ogni cambio la camera viene svuotata, ma alla reception restano dei biglietti che dicono dove si trovano le cose dell’ospite.
L’attaccante manda al server una richiesta costruita apposta per mandarlo in crisi di memoria nel momento sbagliato.
PHP «caccia l’ospite» all’improvviso: svuota la camera ma dimentica di stracciare alcuni biglietti alla reception.
La richiesta successiva, sempre dell’attaccante, riempie quello spazio con dati falsi, e PHP li tratta come se fossero suoi.
Da qui due conseguenze:
- Fuga di informazioni. PHP può restituire all’attaccante pezzi della memoria del server, con password, chiavi di accesso e dati di altri utenti. È un meccanismo simile al celebre Heartbleed del 2014.
- Esecuzione di comandi. Nei casi più gravi l’attaccante riesce a far eseguire al server codice scelto da lui:
può installare programmi malevoli, rubare database o modificare il sito.
Tutto avviene prima ancora che il sito venga caricato: per questo né i plugin di sicurezza di WordPress né le password più robuste possono fermarlo.
Chi è a rischio
- Qualunque sito o gestionale in PHP con una versione precedente a quelle corrette: WordPress, WooCommerce, Joomla, Drupal, Magento, applicazioni su misura.
- I server più esposti sono quelli che usano Apache con il modulo PHP integrato (mod_php), dove l’attacco è stato dimostrato funzionante. Anche le configurazioni più moderne con PHP-FPM sono vulnerabili, con condizioni diverse.
- I siti su versioni vecchie (PHP 8.1 e precedenti) sono nella situazione peggiore: il progetto PHP non rilascia più
versioni ufficiali per loro. Per 7.4, 8.0 e 8.1 sono state pubblicate correzioni minime, che alcuni fornitori hanno distribuito;
per le versioni ancora più vecchie non c’è nulla. La soluzione vera è passare a una versione supportata.
Le versioni sicure
| Versione di PHP | Versione corretta | Aggiornamenti di sicurezza fino a |
| 8.5 | 8.5.12 | fine 2029 |
| 8.4 | 8.4.27 | fine 2028 |
| 8.3 | 8.3.36 | fine 2027 |
| 8.2 | 8.2.35 | 31 dicembre 2026 |
| 8.1 e precedenti | nessuna versione ufficiale | già scaduti |
Cosa fare adesso:
la checklist per le aziende
- Scoprire quale versione di PHP usa il sito. In WordPress si trova in Strumenti → Salute del sito → Info → Server; altrimenti si chiede al fornitore di hosting.
- Chiedere al fornitore una conferma scritta che PHP sia stato aggiornato a una delle versioni corrette e che i servizi siano stati riavviati.
- Se il sito usa PHP 8.1 o precedente, pianificare subito il passaggio a 8.4 o 8.5, insieme all’aggiornamento di WordPress, tema e plugin.
- Non fidarsi delle soluzioni «veloci» che girano in rete, come disattivare una singola impostazione di PHP: gli sviluppatori di PHP hanno chiarito che l’unica protezione completa è l’aggiornamento.
- Non scaricare i presunti exploit pubblici per «provare» il proprio sito: in rete ne circolano decine, molti non funzionano e alcuni sono di origine sconosciuta.
- Cambiare le credenziali più delicate salvate nel sito (chiavi dei pagamenti online, accessi a gestionali e servizi esterni) se il server è rimasto senza correzione nei giorni degli attacchi.
- Controllare con il proprio fornitore che non ci siano file sospetti o utenti amministratori sconosciuti comparsi dal 17 ottobre in poi.
Cosa ha fatto Omnia
per i propri clienti
Sul server di hosting di Omnia, entro la mattina del 22 ottobre:
- abbiamo installato le versioni corrette di PHP e aggiornato il pannello di gestione con la correzione rilasciata dal produttore;
- abbiamo rimosso le versioni di PHP fuori supporto, la 8.1 e le precedenti: restano solo 8.2, 8.3, 8.4 e 8.5, tutte nella versione corretta, e i siti che usavano le versioni vecchie sono stati spostati su una supportata.
Per policy non teniamo attivi siti su versioni di PHP senza aggiornamenti di sicurezza. La stessa regola varrà per PHP 8.2, che esce dal supporto il 31 dicembre 2026: i clienti interessati verranno contattati prima di fine anno.
Chi ha il sito da noi e dopo l’aggiornamento nota errori, pagine bianche o funzioni che non vanno può contattarci:
interveniamo noi.
PHP2Shell e NIS2
Per le aziende soggette alla direttiva NIS2, episodi come questo sono esattamente ciò che la norma chiede di saper gestire:
la gestione delle vulnerabilità e l’aggiornamento tempestivo dei sistemi fanno parte delle misure di sicurezza obbligatorie.
Se emerge un incidente significativo, scatta la pre-notifica al CSIRT Italia entro 24 ore.
Avere un inventario aggiornato di siti, server e versioni software fa la differenza tra un aggiornamento di un’ora e giorni di ricerche.
Domande frequenti su PHP2Shell
Il mio sito WordPress è a rischio? Sì, se il server usa una versione di PHP precedente a quelle corrette. Aggiornare WordPress e i plugin è utile, ma non risolve: serve aggiornare PHP.
Il mio sito è ospitato da Omnia: devo fare qualcosa? No, il server è già aggiornato. Se dopo il passaggio alla nuova versione di PHP notate errori o malfunzionamenti, contattateci.
Come capisco se il mio sito è stato attaccato? I segnali tipici sono file nuovi o modificati in cartelle dove non dovrebbero esserci, utenti amministratori sconosciuti ed errori ripetuti del server dal 17 ottobre in poi. Il controllo va fatto da chi gestisce il server.
Gli attacchi sono già in corso? Sì. Amazon ha registrato un primo tentativo il 17 ottobre, quattro giorni prima della divulgazione, e dal 21 ottobre diverse società di sicurezza osservano tentativi su larga scala. Al momento non sono stati resi pubblici casi di violazioni riuscite, ma è prudente considerarle possibili.
Uso un hosting economico: devo preoccuparmi? Dipende da quanto rapidamente il fornitore ha aggiornato i server. Chiedete una conferma scritta con la versione di PHP installata.
Perché se ne è parlato così tanto? Perché la falla è nel motore di PHP, che fa funzionare circa sette siti su dieci nel mondo, e perché i dettagli sono trapelati prima che la correzione fosse disponibile.
Non sai se i tuoi siti e i tuoi server sono aggiornati?
Omnia segue la sicurezza informatica delle aziende tra Pistoia, Prato e Firenze.
Clicca qua per contattarci o chiamaci allo 0573 1936474: verifichiamo noi versioni, configurazioni e segnali di compromissione.


