In questa guida (7)
Il 21 ottobre 2026 il progetto PHP ha rilasciato una patch di emergenza per due vulnerabilità critiche, ribattezzate PHP2Shell, che permettono di eseguire codice su un server senza alcuna credenziale. Riguardano ogni sito basato su PHP, non un singolo CMS: WordPress, PrestaShop, Joomla, WooCommerce e installazioni personalizzate. Ecco cosa sono, chi è davvero a rischio, perché un firewall applicativo da solo non basta e cosa fare subito.
Il 21 ottobre 2026 il progetto PHP ha rilasciato una patch di emergenza per due vulnerabilità critiche, ribattezzate PHP2Shell, che permettono di eseguire codice su un server senza alcuna credenziale. Riguardano ogni sito basato su PHP, non un singolo CMS: WordPress, PrestaShop, Joomla, WooCommerce e installazioni personalizzate sono interessati allo stesso modo se la versione PHP sottostante non è aggiornata. Ecco cosa sono, chi è davvero a rischio e cosa fare subito.
Cos'è PHP2Shell
PHP2Shell è il nome con cui la comunità di sicurezza ha indicato due vulnerabilità distinte nel cuore di PHP, il linguaggio su cui gira la maggior parte dei siti e degli ecommerce al mondo: WordPress, PrestaShop, Joomla, WooCommerce, Magento, e moltissime applicazioni su misura. Le due falle, identificate come CVE-2026-109618 e CVE-2026-109619, hanno entrambe un punteggio di gravità CVSS 9.2 su 10 e permettono a un attaccante di eseguire codice sul server senza bisogno di nessuna credenziale, nessun accesso amministrativo, nessuna password.
I dettagli tecnici sono trapelati online il 20 ottobre 2026, prima della divulgazione coordinata prevista. Il progetto PHP ha reagito rilasciando le patch il giorno successivo, il 21 ottobre alle 13:30 UTC. Secondo i ricercatori che monitorano la rete con reti di sensori dedicate, lo sfruttamento attivo di queste falle è iniziato lo stesso giorno della patch: significa che, mentre leggi questa pagina, ci sono tentativi di attacco automatizzati in corso contro siti non aggiornati.
Chi è a rischio
Il rischio non dipende dal CMS che usi, ma dalla versione di PHP su cui quel CMS gira.
| Versione PHP | Stato | Cosa fare |
|---|---|---|
| 8.5, precedente a 8.5.12 | Vulnerabile | Aggiornare a 8.5.12 |
| 8.4, precedente a 8.4.27 | Vulnerabile | Aggiornare a 8.4.27 |
| 8.3, precedente a 8.3.36 | Vulnerabile | Aggiornare a 8.3.36 |
| 8.2, precedente a 8.2.35 | Vulnerabile | Aggiornare a 8.2.35 |
| 8.1 e versioni precedenti | Fuori supporto ufficiale, nessuna patch prevista per questa falla | Verificare con chi gestisce l'hosting, pianificare l'aggiornamento |
| PHP 7.x e PHP 5.x | Fine vita da anni, nessuna patch mai arrivata per questa vulnerabilità | La versione va sostituita, non solo aggiornata |
Un dettaglio che riguarda molte piccole e medie imprese italiane: una quota non piccola di siti aziendali gira ancora su versioni PHP datate, spesso senza che il proprietario del sito lo sappia. Verificare la propria versione oggi è un controllo che richiede pochi minuti.
Come funziona l'attacco, in breve
Le due vulnerabilità sfruttano meccanismi interni di PHP diversi tra loro.
CVE-2026-109618. PHP interrompe una richiesta quando supera il limite di memoria configurato. Se l'interruzione arriva in un momento preciso, ad esempio durante l'elaborazione di un upload di file malformato ad arte, alcune strutture dati restano inizializzate solo a metà. La fase di pulizia successiva tratta quei dati incompleti come validi, aprendo la strada all'esecuzione di codice.
CVE-2026-109619. Riguarda un riferimento a dati di una richiesta precedente, legato alla funzione di upload progress di PHP, che resta attivo più a lungo di quanto dovrebbe sullo stesso processo worker. Una richiesta successiva può accedere a quel riferimento prima che venga reinizializzato, un errore noto come use-after-free, con conseguenze che vanno dalla lettura di memoria altrui fino all'esecuzione di codice.
In entrambi i casi, il risultato per un attaccante è lo stesso: la possibilità di caricare ed eseguire una webshell, uno script che gli permette di controllare il server da remoto. Lo abbiamo trattato più nel dettaglio nell'articolo su cos'è una webshell e come si blocca.
Cosa fare subito
Verifica la versione PHP del tuo sito. Chiedilo a chi gestisce l'hosting, oppure controlla direttamente nel pannello se hai accesso.
Se sei su PHP 8.2, 8.3, 8.4 o 8.5 ma non sull'ultima patch, aggiorna subito alla versione corretta indicata nella tabella sopra.
Se sei su PHP 8.1 o precedente, non esiste una patch per questa falla specifica. Valuta un hosting che applichi gli aggiornamenti per te, o pianifica l'aggiornamento della versione PHP come priorità, non come attività rimandabile.
Nel frattempo, se chi gestisce il tuo hosting o il tuo firewall applicativo ha già distribuito una regola specifica per questo exploit, verificane l'attivazione, ma considerala una misura ponte, non una sostituta della patch.
Controlla i log del server per richieste anomale verso endpoint di upload nei giorni successivi al 20 ottobre 2026, la data in cui i dettagli tecnici sono trapelati prima della patch ufficiale.
Perché un firewall applicativo da solo non basta
Un firewall applicativo (WAF) può ridurre il rischio, ma qui vale la pena essere precisi: secondo l'avviso ufficiale di CISA, l'agenzia statunitense per la sicurezza informatica, un WAF "può fornire una certa protezione fino a quando i sistemi non vengono aggiornati", definendolo esplicitamente una misura secondaria. L'aggiornamento della versione PHP resta quello che CISA chiama "the essential fix", la correzione essenziale.
Il motivo è tecnico: diversi ricercatori di sicurezza hanno osservato che le richieste usate per sfruttare PHP2Shell sono piccole, circa 450 byte, e hanno l'aspetto di un normale upload multipart. Le regole generiche di un WAF, quelle basate sulla dimensione della richiesta o sul riconoscimento di pattern di attacco noti come SQL injection o cross-site scripting, non sono pensate per intercettare questo tipo di richiesta: serve una regola scritta apposta per il pattern specifico di questo exploit. Lo stesso vale per l'articolo che abbiamo dedicato a come funziona un firewall applicativo: un WAF è uno strato di difesa, non un sostituto della patch.
Se il tuo sito è ancora su PHP 5 o PHP 7
Per chi è su PHP 5 o PHP 7, PHP2Shell non è un problema che una patch risolverà: quelle versioni non ricevono aggiornamenti di sicurezza da anni, e questa è solo l'ultima di una serie di falle che su quelle installazioni restano aperte per sempre. Non è una questione di quando arriverà l'aggiornamento: non arriverà. Se il tuo sito è ancora su una di queste versioni, probabilmente lo era già prima di PHP2Shell, e lo sarà anche dopo, per la prossima vulnerabilità e quella successiva. Com'è successo in altri casi che abbiamo documentato, come per i siti rimasti su una versione non più supportata di una piattaforma ecommerce, restare su un software fuori supporto è una scelta che si paga in sicurezza, non in comodità.
Cosa significa per chi usa un hosting gestito
Su un'installazione PHP tradizionale, un hosting condiviso con WordPress, PrestaShop o Joomla installati manualmente, la responsabilità di aggiornare la versione PHP è quasi sempre di chi gestisce il sito, sito per sito, uno alla volta. Su un hosting gestito la versione PHP dell'infrastruttura viene aggiornata centralmente da chi fornisce la piattaforma, non dal singolo cliente: è una differenza operativa reale tra i due modelli.
Detto questo, va detto con altrettanta chiarezza: nessun firewall applicativo, incluso quello nativo di KeideaCMS, elimina la necessità di aggiornare la versione PHP sottostante. Un WAF riduce il rischio su un insieme di tecniche di attacco note; non sostituisce la patch, per nessuna piattaforma. Se gestisci siti aziendali e vuoi sapere con certezza su quale versione PHP girano e se sono esposti a questa falla, il modo più diretto è un controllo tecnico della sicurezza del tuo sito, non dare per scontata la risposta.
