PHP2Shell: le nuove vulnerabilità di PHP e i rischi per la sicurezza dei siti web
Il 21 ottobre sono state rese pubbliche due vulnerabilità particolarmente gravi che riguardano PHP, uno dei linguaggi di programmazione più diffusi per lo sviluppo di siti e applicazioni web.
Le vulnerabilità, identificate come CVE-2026-109618 e CVE-2026-109619 e indicate con il nome PHP2Shell, hanno attirato immediatamente l’attenzione degli esperti di sicurezza informatica per le possibili conseguenze sui server che utilizzano versioni di PHP non aggiornate.
Il problema non riguarda un particolare CMS, un plugin o un errore commesso durante lo sviluppo di un sito. Questa volta le criticità sono state individuate direttamente nel motore PHP, il componente software che permette al server di eseguire le applicazioni scritte in questo linguaggio.
È una distinzione importante, perché significa che anche un sito realizzato correttamente, con un CMS aggiornato e senza particolari problemi applicativi, potrebbe essere esposto se il server utilizza una versione vulnerabile di PHP.
Cosa è successo esattamente?
Le due vulnerabilità riguardano alcuni meccanismi interni utilizzati da PHP per gestire la memoria durante l’esecuzione delle applicazioni.
La prima, CVE-2026-109618, è collegata alla gestione di particolari condizioni di esaurimento della memoria. La seconda, CVE-2026-109619, riguarda invece il possibile utilizzo di riferimenti a porzioni di memoria che sono già state liberate.
Si tratta di problemi piuttosto complessi dal punto di vista tecnico, ma le conseguenze sono più semplici da comprendere.
In determinate condizioni, un malintenzionato potrebbe inviare al server richieste appositamente costruite e sfruttare questi errori per arrivare a eseguire codice non autorizzato.
È quello che in ambito informatico viene definito Remote Code Execution, o più semplicemente RCE.
In pratica, il rischio è che un soggetto esterno riesca a far eseguire al server istruzioni che non dovrebbero essere consentite, senza necessariamente conoscere le credenziali di accesso al sito.
Se l’attacco dovesse riuscire, le conseguenze dipenderebbero dai permessi disponibili al processo PHP e dalla configurazione del server. Potrebbero comprendere l’accesso a file riservati, la sottrazione di informazioni presenti nei database, la modifica dei contenuti del sito o l’installazione di software malevolo.
Questo non significa che tutti i server vulnerabili possano essere automaticamente compromessi, ma è evidente che un problema di questo tipo debba essere affrontato con la massima attenzione.
Il problema riguarda anche WordPress?
Sì, ma è importante chiarire un aspetto che rischia di generare confusione.
WordPress è sviluppato in PHP, così come numerose altre piattaforme utilizzate per siti aziendali, portali editoriali, e-commerce e applicazioni web personalizzate.
Tuttavia, PHP2Shell non è una vulnerabilità specifica di WordPress.
Il problema si trova a un livello più basso, nel software che esegue il codice PHP sul server.
Di conseguenza, aggiornare WordPress, i plugin e il tema grafico rimane una buona pratica indispensabile, ma non è sufficiente a risolvere una vulnerabilità presente nell’interprete PHP.
Per capire se un sito è esposto bisogna verificare quale versione di PHP viene effettivamente utilizzata dall’hosting e se sono stati installati gli aggiornamenti di sicurezza necessari.
Lo stesso discorso vale per i CMS sviluppati su misura. Anche quando il codice dell’applicazione è stato scritto seguendo tutte le buone pratiche di sicurezza, una vulnerabilità del software sottostante può rappresentare un problema.
E se il server utilizza Windows?
Un altro aspetto che merita attenzione riguarda il sistema operativo.
Quando si parla di PHP, si pensa spesso ai server Linux, ma PHP può essere eseguito anche su macchine Windows, ad esempio attraverso Microsoft IIS e FastCGI.
Utilizzare Windows, quindi, non significa essere automaticamente al riparo da questo tipo di vulnerabilità.
È necessario verificare la versione di PHP installata e soprattutto il modo in cui viene eseguita all’interno dell’ambiente server.
Questo vale anche per le aziende che stanno migrando da applicazioni sviluppate con tecnologie Microsoft, come ASP.NET e C#, verso nuove piattaforme realizzate in PHP.
Il cambiamento di tecnologia non è di per sé un problema di sicurezza, ma richiede una verifica accurata dell’ambiente che ospiterà il nuovo software.
Quali versioni di PHP sono interessate?
Il team di sviluppo PHP ha pubblicato aggiornamenti correttivi per i rami supportati.
Le versioni indicate per risolvere le vulnerabilità sono:
| Ramo PHP | Versione corretta |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Chi utilizza una versione precedente dovrebbe verificare tempestivamente la propria installazione e programmare l’aggiornamento.
Per le versioni PHP ormai fuori supporto, la situazione richiede ancora più attenzione, perché non sempre vengono rilasciate correzioni ufficiali.
Naturalmente, prima di aggiornare un server di produzione è opportuno verificare la compatibilità del sito con la nuova versione e disporre di un backup funzionante.
Questo non deve però diventare un motivo per rimandare indefinitamente l’intervento.
I primi tentativi di attacco sarebbero precedenti alla pubblicazione
Uno degli elementi più preoccupanti emersi dalle analisi riguarda la tempistica dei primi tentativi di sfruttamento.
Secondo quanto riportato da Amazon Threat Intelligence, i suoi sistemi di monitoraggio avrebbero individuato attività riconducibili a PHP2Shell già il 17 ottobre, alcuni giorni prima della divulgazione pubblica delle vulnerabilità.
Questo dato è particolarmente significativo.
Quando una vulnerabilità viene resa pubblica, infatti, non è detto che gli attaccanti inizino a interessarsene soltanto in quel momento. In alcuni casi il problema può essere già conosciuto o sfruttato da un numero limitato di soggetti.
Dopo la pubblicazione degli aggiornamenti e delle analisi tecniche, inoltre, le informazioni disponibili possono facilitare la ricerca di sistemi ancora vulnerabili.
È anche per questo motivo che la rapidità con cui vengono applicate le correzioni rappresenta un elemento essenziale nella gestione della sicurezza.
Cloudflare e i firewall possono risolvere il problema?
Cloudflare ha annunciato l’introduzione di protezioni specifiche attraverso il proprio Web Application Firewall, con l’obiettivo di riconoscere e bloccare richieste potenzialmente collegate allo sfruttamento delle vulnerabilità.
Si tratta certamente di una misura utile.
Un firewall applicativo correttamente configurato può contribuire a ridurre l’esposizione di un sito, soprattutto nel periodo necessario a effettuare gli aggiornamenti.
Bisogna però evitare di considerarlo una soluzione definitiva.
Il firewall analizza e filtra il traffico, ma non modifica il codice vulnerabile presente nel motore PHP.
Inoltre, se il server è raggiungibile direttamente attraverso percorsi che non passano dal sistema di protezione, alcune richieste potrebbero aggirare il filtraggio.
La soluzione rimane quindi l’aggiornamento del software, accompagnato da una configurazione corretta del server.
Un problema da considerare anche durante lo sviluppo di nuovi siti
C’è un aspetto di questa vicenda che considero particolarmente importante e che riguarda la realizzazione di nuovi progetti web.
Quando si sviluppa un sito o si sostituisce un vecchio CMS, normalmente ci si concentra sulle funzionalità, sulla gestione dei contenuti, sulla grafica e sulle prestazioni.
Sono tutti elementi fondamentali, ma non dovrebbero far passare in secondo piano la sicurezza dell’infrastruttura.
Un nuovo CMS può essere perfettamente funzionante dal punto di vista applicativo e presentare comunque problemi se viene installato su un server non aggiornato o configurato in modo inadeguato.
Questo è particolarmente importante quando si passa da una tecnologia a un’altra.
Penso, ad esempio, alla migrazione di un sito sviluppato in ASP.NET verso una nuova piattaforma PHP. In una situazione del genere non è sufficiente verificare che le pagine funzionino correttamente e che i dati siano stati trasferiti senza errori.
Bisogna anche controllare l’ambiente che ospiterà la nuova applicazione: versioni dei software, configurazione del web server, permessi di accesso, sicurezza del database, servizi esposti verso Internet e procedure di backup.
Anche gli ambienti di test meritano attenzione.
Il fatto che un sito non sia ancora stato pubblicato non significa necessariamente che sia protetto. Se il server di sviluppo è accessibile da Internet, potrebbe essere individuato e attaccato esattamente come un normale sito pubblico.
La separazione tra ambiente di test e produzione è una misura importante, ma deve essere accompagnata da un isolamento effettivo e da adeguati controlli di accesso.
Cosa fare se si gestisce un sito PHP
Per chi gestisce direttamente un server, il primo passo è piuttosto evidente: verificare la versione di PHP installata e applicare gli aggiornamenti disponibili.
Per chi invece utilizza un hosting gestito, la cosa più semplice è chiedere al proprio fornitore una conferma sulla versione in uso e sull’eventuale applicazione delle correzioni.
A mio avviso, però, la verifica non dovrebbe fermarsi a questo.
Sarebbe opportuno controllare anche i log del server per individuare eventuali richieste anomale, verificare che non siano presenti file sospetti e accertarsi che i backup siano aggiornati e realmente utilizzabili.
Un altro elemento spesso trascurato riguarda i privilegi dei processi.
Il software che esegue il sito dovrebbe poter accedere soltanto alle risorse strettamente necessarie al suo funzionamento. In questo modo, anche nell’eventualità di una compromissione, si possono limitare i danni.
Infine, è importante ricordare che la sicurezza non dipende da un singolo strumento.
Un server aggiornato, un firewall configurato correttamente, un sistema di backup affidabile e un monitoraggio costante sono misure che funzionano meglio quando vengono adottate insieme.
La sicurezza di un sito non finisce con la sua pubblicazione
La vicenda PHP2Shell dimostra ancora una volta quanto sia importante considerare la sicurezza informatica come un’attività continuativa.
Non esiste un linguaggio di programmazione che possa essere considerato completamente immune dalle vulnerabilità. Problemi di sicurezza possono emergere in PHP, in ASP.NET, nei database, nei sistemi operativi e in qualsiasi altro componente software.
La differenza la fanno soprattutto la qualità della gestione tecnica e la capacità di intervenire rapidamente quando vengono individuate nuove criticità.
Un sito può funzionare perfettamente, essere veloce e non mostrare alcun problema evidente, ma utilizzare comunque componenti software vulnerabili.
Per questo ritengo che la manutenzione tecnica non debba limitarsi alla risoluzione dei malfunzionamenti segnalati dagli utenti.
Dovrebbe comprendere verifiche periodiche, aggiornamenti, controlli sulla configurazione del server, monitoraggio dei log e test delle procedure di ripristino.
Soprattutto quando si prepara il lancio di una nuova piattaforma, queste attività dovrebbero essere considerate parte integrante del progetto e non un intervento aggiuntivo da affrontare soltanto in caso di necessità.
PHP2Shell non significa che tutti i siti sviluppati in PHP siano insicuri. È però un promemoria molto concreto: anche un’applicazione ben realizzata può diventare vulnerabile se l’infrastruttura su cui viene eseguita non viene mantenuta e controllata con attenzione.
Ed è proprio su questo aspetto che, secondo me, dovrebbe concentrarsi chiunque abbia la responsabilità tecnica di un sito web. Per qualsiasi dubbio potete contattarmi.
Fonti e approfondimenti
Related Posts
RESTIAMO IN CONTATTO
PROPONIMI IL TUO PROGETTO
O FAMMI ANALIZZARE IL TUO
SITO PER MIGLIORARLO
PUOI CHIAMARMI AL TELEFONO
06 88934050
SEGUIMI SUI SOCIAL
PRENOTA UN INCONTRO
PRENOTA UNA RIUNIONE ONLINE
GRATUITA E SENZA IMPEGNO
