Aggiornato al 30 ottobre 2026

Il 21 ottobre 2026 il progetto PHP ha pubblicato gli aggiornamenti di sicurezza per due vulnerabilità critiche, ribattezzate PHP2Shell e identificate dai codici CVE-2026-109618 e CVE-2026-109619. PHP è il linguaggio su cui funziona buona parte dei siti che visitiamo ogni giorno, da WordPress a PrestaShop, da Joomla a Drupal, fino a molti gestionali e applicazioni sviluppati su misura per le aziende, e per questo la notizia ha avuto un’eco ben oltre la cerchia degli addetti ai lavori.

Il 26 ottobre la CISA, l’agenzia statunitense per la cybersecurity, ha inserito entrambe le falle nel proprio catalogo delle vulnerabilità sfruttate attivamente. Per chi ha un sito aziendale, quindi, la domanda da porsi riguarda anche il server su cui il sito è ospitato, perché in questo caso avere CMS e plugin aggiornati non basta: il problema si trova nell’ambiente che permette al sito di funzionare.

PHP2Shell: cosa è successo e quali siti sono coinvolti

PHP riceve le richieste dei visitatori, dialoga con il database e costruisce al volo le pagine che vediamo, per cui dietro un modulo di contatto o un acquisto online c’è quasi sempre uno script PHP al lavoro. Le due vulnerabilità riguardano il modo in cui PHP gestisce internamente la memoria tra una richiesta e l’altra e, in determinate condizioni, possono consentire a un attaccante di eseguire codice sul server senza autenticarsi. In questi casi si parla di Remote Code Execution (RCE), cioè esecuzione di codice da remoto; le conseguenze dipendono dalla configurazione e dai permessi del server, ma possono arrivare all’accesso ai file, alla sottrazione di dati o alla modifica dei contenuti.

Il team di PHP ha assegnato a entrambe un punteggio di gravità di 9,2 su 10 (CVSS 4.0) e ha precisato che è potenzialmente a rischio ogni installazione che gestisce richieste web. Non è quindi il problema di un singolo CMS o di un plugin: possono essere coinvolti allo stesso modo un sito WordPress, un e-commerce PrestaShop o un gestionale scritto in PHP, e l’esposizione reale dipende dalla versione installata, dalle patch applicate e dalla configurazione del server.

Dagli aggiornamenti agli attacchi: cosa è cambiato in pochi giorni

L’esistenza delle vulnerabilità è stata annunciata il 20 ottobre e il giorno successivo sono state rilasciate le versioni corrette. Alcuni ricercatori hanno rilevato tentativi di sfruttamento già a ridosso della pubblicazione e, nei giorni seguenti, sono state confermate tecniche di attacco funzionanti contro le versioni non aggiornate, fino all’inserimento nel catalogo KEV della CISA. Un tentativo di attacco non equivale a un sito compromesso, ma la velocità con cui una vulnerabilità appena annunciata è diventata qualcosa da provare su server reali dice molto su quanto conti oggi il tempo di intervento.

Il 23 ottobre il team di PHP ha poi pubblicato un avviso informativo su una terza vulnerabilità, la CVE-2026-115560, non coperta dalle patch del 21 ottobre. Lo scenario di attacco, in questo caso, richiede una combinazione piuttosto insolita di configurazione e codice applicativo, e in attesa della prossima release è indicata una mitigazione specifica, la disattivazione dell’opzione session.upload_progress. Resta comunque un buon esempio di come la sicurezza di un server vada seguita nel tempo, anche dopo il primo aggiornamento.

Quali versioni PHP devono essere aggiornate?

Per le due vulnerabilità PHP2Shell il progetto PHP ha distribuito il 21 ottobre queste versioni corrette:

Le versioni precedenti di questi rami vanno aggiornate. PHP 8.1 e le versioni più vecchie non ricevono più aggiornamenti ufficiali: per alcune il team di PHP ha reso disponibili correzioni a livello di codice sorgente, e diverse distribuzioni Linux e fornitori con supporto esteso applicano le patch tramite backport, cioè senza cambiare il numero di versione principale. Per sapere se un server è protetto, quindi, il numero di versione da solo non basta e bisogna verificare quali correzioni siano state effettivamente installate. Chi è ancora su un ramo non più supportato può cogliere l’occasione per pianificare la migrazione, tenendo presente che anche PHP 8.2 arriverà a fine supporto il 31 dicembre 2026.

«Avete aggiornato il nostro sito?» Chi interviene su cosa

Nei giorni successivi alla notizia diversi clienti ci hanno contattato per sapere se i loro siti fossero stati aggiornati e se potessero stare tranquilli. È una domanda naturale, perché per molte aziende siamo il punto di riferimento per tutto ciò che riguarda il sito, anche quando alcuni servizi, come l’hosting, sono forniti e gestiti da altri. Ci ha dato l’occasione di chiarire una distinzione che dall’esterno non è scontata, cioè che non tutti gli aggiornamenti di sicurezza passano dal sito.

Quando si aggiorna WordPress, PrestaShop o un’altra piattaforma si interviene sul software che gestisce il sito, quindi sul CMS, sui plugin, sui moduli e sul tema. Con PHP2Shell il problema sta invece in PHP, il linguaggio eseguito dal server, ed è a quell’ambiente che va applicata la correzione. Su un hosting condiviso o gestito questo compito spetta di norma al fornitore del servizio, mentre su un VPS o un server dedicato se ne occupa chi amministra l’infrastruttura, secondo quanto previsto dal contratto. Può succedere, così, che un sito perfettamente aggiornato giri su un ambiente PHP che attende ancora la patch.

Chi segue il sito ha comunque un ruolo importante, soprattutto quando fa da tramite tra il cliente e i diversi fornitori: conoscere l’ambiente su cui gira il progetto, seguire le comunicazioni del provider, chiedere conferma che le correzioni siano state applicate e verificare che dopo l’aggiornamento tutto funzioni come prima. Capire subito quale componente è coinvolto e chi ha la responsabilità di intervenire evita operazioni inutili e permette di lavorare in modo coordinato con chi gestisce l’infrastruttura.

Firewall, backup e sistemi di sicurezza: bastano?

Molti servizi di hosting includono firewall, antimalware, backup automatici e monitoraggio. Sono strumenti utili, ciascuno con un compito preciso: un firewall applicativo può bloccare una parte delle richieste sospette, il monitoraggio può segnalare anomalie e il backup permette di ripartire dopo un incidente. Per PHP2Shell diversi fornitori, tra cui Cloudflare e AWS, hanno rilasciato regole di protezione specifiche, preziose quando l’aggiornamento non può essere installato subito. Lo stesso team di PHP, però, è stato chiaro: non esistono mitigazioni complete e l’aggiornamento resta l’unica scelta sicura.

Tempi di intervento sempre più stretti, anche per i siti piccoli

La scoperta di PHP2Shell mostra anche come l’intelligenza artificiale stia entrando nel lavoro sulla sicurezza: i ricercatori di Calif e di Wiz, che hanno analizzato le falle, hanno dichiarato di aver utilizzato modelli di AI nelle loro ricerche. È un uso positivo, che aiuta a individuare problemi rimasti nel codice anche per anni, ma le stesse capacità possono accelerare lo studio delle vulnerabilità appena pubblicate da parte di chi vuole sfruttarle. Il risultato è che l’intervallo tra la scoperta di un problema e i primi tentativi di attacco tende ad accorciarsi.

Questo riguarda anche i siti di piccole dimensioni. Buona parte dei tentativi di attacco è automatizzata e cerca software vulnerabile senza distinguere tra una grande organizzazione e un’attività locale, per cui un sito diventa un bersaglio semplicemente perché presenta una falla sfruttabile. Le conseguenze, poi, possono pesare anche su una piccola azienda: richieste di contatto e ordini che non arrivano più, contenuti fraudolenti pubblicati a nome dell’attività, danni alla reputazione e alla visibilità sui motori di ricerca.

La manutenzione non riguarda soltanto WordPress

WordPress è spesso al centro dei discorsi sulla sicurezza perché è il CMS più diffuso, ma aggiornamenti e verifiche riguardano qualsiasi progetto, dagli e-commerce PrestaShop ai siti Joomla, dalle applicazioni Laravel ai gestionali personalizzati, che possono essere esposti anche per via di librerie obsolete o componenti server non aggiornati. Ogni aggiornamento, d’altra parte, va gestito con metodo. Un cambio di versione di PHP può creare incompatibilità con applicazioni datate e persino le patch d’emergenza possono avere effetti collaterali: nei giorni successivi al rilascio, per esempio, è stata segnalata una regressione nelle versioni 8.4.27 e 8.5.12 legata all’estensione SimpleXML. Backup, verifiche preliminari e, quando possibile, un ambiente di test servono proprio a questo, cioè ad aggiornare con tempestività riducendo il rischio di interruzioni.

Il rischio zero non esiste: conta come viene gestito

Nuove vulnerabilità continueranno a emergere, anche nei software più diffusi e sviluppati con cura, e nessuno può garantire un sito immune da qualsiasi problema. Quello che si può fare è ridurre l’esposizione, applicare le correzioni appena disponibili, monitorare i servizi ed essere pronti a intervenire. Per questo, quando si sceglie un hosting, oltre a prestazioni e prezzo vale la pena conoscere le politiche di aggiornamento, i tempi dell’assistenza e la ripartizione delle responsabilità tra fornitore e cliente: non esiste una soluzione adatta a tutti, e conta soprattutto come l’ambiente viene gestito giorno per giorno.

In Zero Pixel consideriamo la gestione tecnica parte del lavoro necessario a mantenere efficace un progetto digitale nel tempo, anche quando questo significa coordinarsi con fornitori diversi per dare al cliente una risposta chiara.

Un sito deve farsi trovare, essere veloce e funzionare bene, e deve poter continuare a farlo in sicurezza anche domani.

Vuoi verificare la sicurezza del tuo sito e del servizio di hosting?

Se non sai quale versione di PHP utilizza il tuo sito, quando è stato fatto l’ultimo aggiornamento o chi si occupa della sicurezza del server, contattaci, possiamo aiutarti a fare il punto. Analizziamo l’ambiente tecnico e le attività di manutenzione e, se serve, ci confrontiamo con il tuo fornitore di hosting per chiarire cosa è già stato fatto e quali sono le priorità.