PHP2Shell: la vulnerabilità critica in PHP e cosa devono fare le PMI di Torino

PHP2Shell è il nome dato a due vulnerabilità critiche di PHP, il linguaggio con cui è costruita la maggior parte dei siti web del mondo, rese pubbliche il 21 ottobre 2026. Sono identificate dai codici CVE-2026-109618 e CVE-2026-109619 e permettono a un attaccante di eseguire codice sul server senza alcuna autenticazione: non serve una password, non serve un utente, basta che il server risponda a una richiesta web. Il team di sicurezza di PHP le ha classificate con un punteggio di gravità 9,2 su 10 (CVSS v4.0) e ha pubblicato le versioni corrette lo stesso giorno; in Italia l'Agenzia per la Cybersicurezza Nazionale ha diffuso un avviso dedicato.

Il motivo per cui il caso ha fatto tanto rumore è semplice: PHP è ovunque. Secondo W3Techs (rilevazione del 22 ottobre 2026), PHP è usato dal 69,3% dei siti web di cui si conosce il linguaggio lato server. WordPress, i principali e-commerce open source, moltissimi portali aziendali e gestionali web girano su PHP. Per una PMI questo significa che quasi certamente, da qualche parte, c'è un server PHP che porta il suo nome: il sito aziendale, il catalogo online, l'area riservata dei clienti, l'intranet, il pannello dell'hosting.

AscenSys, società IT di Torino che segue circa 130 aziende del Piemonte come fornitore IT unico, ha passato le ore successive all'avviso a verificare e aggiornare i sistemi dei clienti in assistenza. In questo articolo spieghiamo, senza entrare nei dettagli tecnici, che cosa rischia concretamente una PMI, perché "il sito lo gestisce qualcun altro" non è una risposta sufficiente, e quali sono le tre domande da fare oggi stesso a chi vi segue il sito o l'hosting.

La prima reazione di molti imprenditori è stata: "noi non usiamo PHP". Quasi sempre non è vero. Il problema di PHP2Shell è che colpisce il motore stesso di PHP, prima ancora che l'applicazione entri in gioco: l'avviso ufficiale del progetto PHP dice che sono interessate tutte le installazioni di PHP che servono richieste web, e i ricercatori di Wiz hanno dimostrato l'attacco su WordPress, Drupal e Joomla senza bisogno di altre falle nei CMS. In altre parole, non conta quanto è aggiornato il vostro sito o quanto sono buoni i plugin: conta la versione di PHP che gira sotto.

Nelle aziende che seguiamo a Torino e in Piemonte i server PHP si nascondono in posti prevedibili:

• Il sito aziendale, quasi sempre WordPress, su un hosting condiviso scelto anni fa dall'agenzia web, dove nessuno ha mai guardato la versione di PHP.
• Il catalogo o l'e-commerce su PrestaShop, Magento o WooCommerce, spesso su un server dedicato o virtuale con una versione di PHP "congelata" perché un aggiornamento aveva rotto qualcosa.
• Portali e aree riservate: il portale dei clienti, l'area agenti, la richiesta di assistenza, l'intranet. Applicazioni fatte su misura anni fa, che funzionano e per questo nessuno tocca.
• I pannelli di gestione dell'hosting o del server (cPanel, Plesk e simili), che sono a loro volta applicazioni PHP esposte su Internet.
• Dispositivi e software di terze parti con un'interfaccia web interna: telecamere, centralini, sistemi di timbratura, piccoli gestionali verticali.

Il secondo problema è il tempo. Amazon Web Services, come riportato da IlSoftware.it il 22 ottobre 2026, ha osservato i primi tentativi di sfruttamento già dal 17 ottobre, quattro giorni prima della divulgazione pubblica. I programmi di attacco che circolano in rete sono in buona parte incompleti, e lo stesso progetto PHP ha dichiarato di non aver trovato exploit funzionanti nelle prime prove pubbliche; ma le configurazioni più comuni, in particolare Apache con mod_php, sono quelle indicate come più esposte, e un attacco che funziona su una di esse funziona su migliaia di siti identici. Chi aspetta "di vedere se succede qualcosa" sta facendo una scommessa sul tempo degli altri.

C'è infine il tema delle versioni fuori supporto. Le correzioni ufficiali esistono solo per PHP 8.2, 8.3, 8.4 e 8.5; per PHP 8.1, 8.0 e 7.4 il progetto ha pubblicato solo correzioni da applicare al codice sorgente, e per le versioni più vecchie nulla. Molti siti aziendali girano ancora su quelle versioni, e per loro la patch non arriva da sola: serve qualcuno che decida cosa fare.

Per i clienti in assistenza di AscenSys PHP2Shell è stato gestito come un normale, per quanto urgente, ciclo di patch management: sapere dove sono i sistemi, aggiornarli in ordine di esposizione, verificare che l'aggiornamento sia davvero in funzione. È lo stesso metodo che applichiamo a qualunque vulnerabilità, e che proponiamo a chi ci contatta in questi giorni. In pratica lavoriamo così:

1. Inventario dei server PHP: mettiamo in fila tutto quello che risponde su Internet o sulla rete aziendale ed è costruito in PHP, inclusi i sistemi "dimenticati": vecchi portali, pannelli, dispositivi con interfaccia web. Se non si sa che esiste, non si può proteggere.
2. Verifica della versione reale: per ogni sistema leggiamo la versione di PHP effettivamente in esecuzione, non quella dichiarata dal fornitore. Sulle distribuzioni Linux le correzioni spesso arrivano mantenendo il vecchio numero di versione, quindi si controlla il registro delle modifiche del pacchetto, non il numero.
3. Aggiornamento in ordine di esposizione: prima i sistemi raggiungibili da Internet, poi quelli interni. Dove il sito è su un hosting gestito, il passaggio alla versione corretta si fa dal pannello e si verifica subito dopo; dove c'è un server nostro, aggiorniamo i pacchetti e riavviamo i processi PHP, perché un aggiornamento senza riavvio non protegge nulla.
4. Mitigazioni dove non si può aggiornare subito: per i sistemi su versioni fuori supporto o che non possono essere fermati, applichiamo le misure parziali indicate dal progetto PHP (limiti alle richieste, disattivazione di funzioni non usate) e li mettiamo dietro una VPN o un firewall applicativo. Il progetto PHP è chiaro: queste misure riducono l'esposizione, non rendono sicuro il sistema. Servono a guadagnare i giorni necessari a migrare.
5. Controllo a posteriori: cerchiamo tracce di compromissione avvenute prima della patch, perché gli attacchi sono iniziati prima della divulgazione. File nuovi nella cartella del sito, attività programmate sconosciute, utenti inattesi, processi anomali avviati dal server web.

Dove l'azienda ha i nostri strumenti di protezione degli endpoint e dei server, come quelli del partner ESET, il quinto passo è in buona parte automatico: un server web che avvia una shell o scarica file da Internet è un comportamento che si può riconoscere e bloccare. Per chi non ha nulla di tutto questo, il controllo lo facciamo a mano, ed è spesso il punto in cui si scopre che il problema non era solo PHP.

La maggior parte delle PMI non gestisce da sola il proprio sito: lo fa un'agenzia web, un freelance o il fornitore di hosting. Va benissimo, a patto di non dare per scontato che qualcuno abbia già fatto il necessario. Dall'esperienza di questi giorni, le domande che fanno la differenza sono tre, e la qualità della risposta dice molto sul fornitore.

Domanda 1: quale versione di PHP sta usando il nostro sito, oggi?

La risposta deve essere un numero preciso. Le versioni che contengono la correzione di PHP2Shell, pubblicate il 21 ottobre 2026 dal progetto PHP, sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Un numero più basso nella stessa serie (per esempio 8.3.30) significa che la patch non è stata applicata. Un numero che inizia con 8.1, 8.0 o 7 significa che il sito gira su una versione che il progetto PHP non aggiorna più: la correzione esiste solo come modifica al codice sorgente o come pacchetto fornito dalla distribuzione Linux, e va verificata caso per caso. Attenzione alla data: PHP 8.2 esce a sua volta dal supporto il 31 dicembre 2026, quindi chi è su quella serie dovrebbe già pianificare il passaggio.

Domanda 2: la patch è stata applicata e i processi sono stati riavviati?

Molti hosting hanno aggiornato automaticamente nelle ore successive all'avviso, ed è il caso migliore: chiedete conferma scritta e la versione risultante. Su server dedicati o virtuali, invece, l'aggiornamento è a carico di chi li amministra, e la correzione entra in funzione solo dopo il riavvio dei processi PHP o del server web. "Abbiamo lanciato l'aggiornamento" non è la stessa cosa di "il sito gira sulla versione corretta".

Domanda 3: abbiamo altri sistemi PHP oltre al sito?

È la domanda che quasi nessuno fa, ed è quella che scopre i problemi veri. Portale clienti, area agenti, modulo di richiesta assistenza, intranet, pannello dell'hosting, interfacce web di dispositivi: ognuno di questi è un server PHP a sé, spesso su una versione diversa da quella del sito. Chi vi risponde "solo il sito" senza aver controllato probabilmente non ha l'inventario.

Un ultimo chiarimento, perché la domanda arriva sempre: un firewall applicativo o un servizio come Cloudflare basta? No. Riduce la superficie di attacco e intercetta le richieste note, ma la vulnerabilità è nel motore di PHP, che elabora la richiesta prima dell'applicazione: il progetto PHP lo scrive in modo esplicito, "non esistono mitigazioni complete, l'aggiornamento è l'unica scelta sicura". Il firewall è un ombrello mentre si cerca un riparo, non il riparo.