PHP2Shell: Due vulnerabilità critiche, patch già disponibile

Il 21 ottobre 2026 il PHP Security Team ha pubblicato due patch per vulnerabilità con punteggio CVSS 9,2 su 10. La patch esiste già: il problema comincia adesso, nella finestra tra la sua pubblicazione e il momento in cui l’hosting o lo sviluppatore deciderà di applicarla.

In sintesi

• Il 21 ottobre 2026 PHP Security Team ha pubblicato due patch per vulnerabilità che permettono esecuzione di codice da remoto (RCE), entrambe con punteggio CVSS 9,2 su 10.
• PHP è il linguaggio alla base di WordPress, Drupal, Joomla e di molti gestionali custom usati da studi e aziende italiane.
• La patch esiste già. Il problema vero è se il fornitore di hosting o lo sviluppatore l’ha applicata.
• Non è un obbligo normativo immediato per chi usa PHP, ma chi distribuisce software con marchio proprio basato su PHP può avere responsabilità sotto il Cyber Resilience Act.

Cosa è successo esattamente

In determinate condizioni, le due falle permettono a un aggressore di eseguire comandi su un server tramite richieste inviate via internet, senza credenziali di accesso. Il PHP Security Team ha confermato che entrambe rendono possibile l’esecuzione di codice da remoto: un malintenzionato può far girare programmi propri sul server come se fosse seduto alla tastiera di chi lo amministra.

Un punteggio CVSS di 9,2 colloca le vulnerabilità nella fascia più alta di gravità, quella in cui gli exploit circolano online entro pochi giorni dalla divulgazione pubblica. La finestra di rischio si apre il giorno della pubblicazione e si chiude solo quando la patch viene effettivamente applicata, non quando viene rilasciata.

PHP è il linguaggio lato server su cui girano WordPress, Drupal, Joomla e una quota ampia dei gestionali custom usati da studi professionali e aziende italiane. Se il sito è stato costruito con uno di questi sistemi, PHP è quasi certamente il motore sotto il cofano, anche se l’utente finale vede solo l’interfaccia con cui carica foto prodotto o gestisce le prenotazioni.

Perché la notizia tecnica diventa un problema aziendale

Chi gestisce un ecommerce, il sito vetrina di uno studio legale o il gestionale prenotazioni di una clinica si trova davanti a una domanda secca: il fornitore di hosting o lo sviluppatore ha già applicato la patch del 21 ottobre? Molti contratti di manutenzione prevedono aggiornamenti “quando necessario”, senza accordi sui tempi di intervento per la sicurezza critica. Potrebbe non succedere nulla finché qualcuno non se ne accorge, magari dopo un incidente già avvenuto.

Il caso del ristorante con prenotazioni su WordPress è paradigmatico: la responsabilità dell’aggiornamento è quasi sempre delegata a un terzo, e quel terzo non ha sempre un incentivo contrattuale a muoversi in fretta. La gravità tecnica della CVSS 9,2 smette qui di essere un numero astratto e diventa un problema di governance del fornitore.

Il punteggio CVSS misura la gravità teorica di una falla, non la probabilità che venga sfruttata contro un sito specifico. Non tutti i siti PHP sono bersagli ugualmente appetibili, ed è lecito chiedersi quanto spesso questi allarmi vengano gonfiati rispetto al rischio reale per il singolo sito aziendale. Ma usare questo dubbio per rimandare la verifica è esattamente l’errore che rende utili gli exploit quando arrivano: il costo di un controllo è minuti, il costo di un incidente è giorni di fermo e dati compromessi.

Verificare, non sperare

La prima cosa da fare è chiedere al fornitore di hosting o allo sviluppatore conferma scritta che la versione di PHP in uso sia stata aggiornata dopo il 21 ottobre 2026. Un “ci stiamo pensando” non è una risposta accettabile su una vulnerabilità di questa gravità. Chi gestisce l’hosting internamente può verificare da sé la versione PHP attiva e confrontarla con le release corrette indicate dal PHP Security Team.

Per chi usa WordPress, Drupal o Joomla, l’aggiornamento di PHP è spesso gestito dal provider indipendentemente dal CMS installato, ma questo non esonera dal controllo: i pannelli di hosting più economici segnalano con una certa frequenza versioni PHP obsolete, proprio perché l’aggiornamento automatico non è sempre incluso nel contratto.

Per chi ha un gestionale custom sviluppato da un fornitore esterno, questo è il momento in cui la clausola di manutenzione del contratto smette di essere un dettaglio burocratico. Se il contratto non prevede tempi certi per le patch di sicurezza critiche, va corretto non solo per questo episodio, ma come prassi strutturale.

Il collegamento con il Cyber Resilience Act

Chi distribuisce software con marchio proprio basato su componenti PHP, anche se sviluppato da terzi, ha obblighi specifici sotto il Cyber Resilience Act, il regolamento (UE) 2024/2847 sulla sicurezza dei prodotti con elementi digitali. Rivendere col proprio marchio un software sviluppato da altri rende “fabbricante” agli occhi del regolamento, a prescindere da cosa dice il contratto con lo sviluppatore originale.

L’articolo 14 impone notifica entro 24 ore per vulnerabilità attivamente sfruttate, obbligo già in vigore oggi. Non ogni falla PHP fa scattare automaticamente questo obbligo: dipende da se il prodotto è classificato come “prodotto con elementi digitali” sotto il CRA, e se la vulnerabilità risulta attivamente sfruttata, non solo teoricamente critica sulla carta. Chi distribuisce software dovrebbe usare proprio questo episodio per verificare, con un legale, se il proprio prodotto rientra nel perimetro del regolamento, prima che la prossima vulnerabilità critica arrivi senza preavviso.

Cosa fare ora

La singola azione che conta più di tutte le altre è una email o una telefonata al proprio fornitore di hosting o sviluppatore, oggi, con una richiesta precisa: conferma scritta che la versione PHP in uso è stata aggiornata dopo il 21 ottobre 2026. Non è una questione di competenza tecnica, è una questione di chiedere la cosa giusta alla persona giusta prima che lo faccia qualcun altro con intenzioni diverse.

Domande correlate

Come faccio a sapere se il mio sito è vulnerabile?

Verifica la versione di PHP in uso tramite il pannello di controllo del tuo hosting o chiedendo al tuo sviluppatore. Confronta la versione con quella indicata come corretta dal PHP Security Team. Se il tuo hosting aggiorna PHP automaticamente, controlla comunque la data dell’ultimo aggiornamento applicato.

WordPress è vulnerabile a questa falla?

WordPress non è direttamente vulnerabile come software, ma gira su PHP. Se il server che ospita il tuo WordPress usa una versione PHP non corretta, l’esposizione esiste a prescindere dalla versione di WordPress installata. Verifica con il tuo hosting provider.

Cosa rischio se non aggiorno subito?

Un aggressore potrebbe eseguire comandi sul tuo server da remoto, con accesso potenziale a dati clienti, credenziali e funzionalità del sito. Il rischio concreto dipende dalla configurazione del server e da altre misure già attive. Con un CVSS di 9,2, la finestra di esposizione va chiusa in giorni, non settimane.

Chi deve notificare questa vulnerabilità sotto il CRA?

L’obbligo riguarda chi distribuisce prodotti con elementi digitali sotto proprio marchio, non chi semplicemente usa un CMS per il proprio sito aziendale. Se vendi software basato su PHP con il tuo brand, verifica con un legale se rientri nel perimetro del regolamento (UE) 2024/2847.

Fonti:

• PHP2Shell: due falle critiche nel linguaggio web - Repubblica (accesso ottobre 2026)
• PHP, due gravi vulnerabilità: patch urgenti - Punto Informatico (accesso ottobre 2026)
• Regolamento (UE) 2024/2847 - Cyber Resilience Act - EUR-Lex (accesso ottobre 2026)