Falle critiche in PHP: perché aggiornare solo il CMS non basta
Due vulnerabilità possono consentire ad attaccanti di eseguire codice sui server web. Le correzioni sono disponibili. Per i gestori di siti svizzeri conta ora la versione di PHP effettivamente in uso.
Il progetto PHP ha pubblicato il 21 ottobre 2026 aggiornamenti di sicurezza contro due vulnerabilità critiche. In determinate condizioni, questi difetti possono permettere ad attaccanti di eseguire codice su un server web senza autenticarsi. Per i gestori di negozi online, siti di associazioni o servizi digitali in Svizzera è quindi decisivo il software installato sul server, non soltanto il sito visibile.
Le correzioni sono incluse in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le due falle sono registrate come CVE-2026-109618 e CVE-2026-109619. L'avviso congiunto delle autorità europee per la cybersicurezza, tra cui ENISA e CERT-EU, invita le organizzazioni ad agire subito. La priorità va ai sistemi raggiungibili pubblicamente.
La vulnerabilità sta sotto il CMS
PHP è un linguaggio di programmazione con un ambiente di esecuzione sul server. Numerose applicazioni web si basano su di esso. Un gestore può quindi usare PHP senza programmare il linguaggio stesso. La responsabilità dell'aggiornamento tecnico spetta, a seconda del contratto, al provider di hosting, a un'agenzia che segue il sito o al proprio team IT.
WordPress chiarisce nel proprio avviso di sicurezza che non si tratta di difetti specifici di WordPress. Un aggiornamento di WordPress non è né previsto né necessario per queste falle. Va invece corretta l'installazione di PHP. Nella sezione di WordPress dedicata allo stato del sito si possono consultare le indicazioni sulla versione del server; anche molte interfacce di gestione dell'hosting le mostrano.
Per una piccola azienda è quindi più utile una domanda precisa che l'assicurazione generica che il sito sia aggiornato: quale versione di PHP serve l'applicazione pubblica e quale correzione ha applicato il fornitore? L'aggiornamento di estensioni e CMS resta importante, ma non risponde a quest'altra domanda.
I numeri di versione richiedono il contesto giusto
Chi utilizza le versioni originali del progetto PHP può confrontare le release corrette indicate. Nelle distribuzioni Linux e nei pacchetti di fornitori con assistenza a lungo termine, le correzioni di sicurezza possono essere trasferite anche nelle serie di pacchetti esistenti. In tal caso conta pure l'avviso di sicurezza del fornitore concreto. Una versione principale più vecchia non basta per una valutazione definitiva.
Viceversa, l'assenza di un percorso di aggiornamento regolare non significa che non ci siano rischi. PHP 8.1 e le serie precedenti non ricevono più release di sicurezza ordinarie dal progetto PHP. Alcuni fornitori mettono a disposizione retroportazioni proprie. I gestori devono chiarire se valgono per l'installazione in uso oppure passare a una serie supportata e corretta.
Non ogni server vulnerabile è già stato compromesso
Le falle riguardano la gestione della memoria e la gestione degli errori. Secondo il progetto PHP, il rischio è particolarmente elevato con Apache e mod_php; vanno verificate anche altre modalità diffuse di eseguire PHP. Per il pubblico è centrale la distinzione: una via d'attacco dimostrata indica un rischio reale. Non prova però che ogni sito interessato sia già stato compromesso.
ENISA raccomanda di censire le applicazioni e i fornitori di servizi e di installare gli aggiornamenti. Dove una correzione rapida non è possibile, le organizzazioni dovrebbero valutare di isolare temporaneamente dalla rete pubblica le applicazioni colpite. Il progetto PHP sottolinea dal canto suo che le misure di configurazione provvisorie riducono solo singole vie d'attacco e non sostituiscono una protezione completa.
Una conferma verificabile dovrebbe indicare quale sistema è stato controllato e a quale livello è stato portato. Nei servizi esternalizzati non deve restare un vuoto di responsabilità tra agenzia e hoster. Il censimento raccomandato dalle autorità europee serve proprio a trovare PHP anche in prodotti che a prima vista portano altri nomi.
L'IA trova i difetti, alle persone spetta la correzione
OpenAI riferisce che la società di sicurezza Calif ha analizzato una vulnerabilità critica con l'aiuto di un modello di IA e che Wiz ha segnalato entrambe le falle in modo indipendente. È la versione di un'azienda coinvolta. Non equivale all'affermazione che un'IA abbia scoperto e risolto il problema da sola.
La PHP Foundation descrive una genesi più lunga: i primi segnali di uno dei problemi c'erano già nel 2024. Compatibilità, possibili effetti collaterali e scarse risorse specialistiche hanno reso più difficile la decisione di correggere. La fondazione ammette errori strutturali e riferisce di processi modificati. Questo limita la semplice narrazione di successo sulla sicurezza automatica.
Per i gestori svizzeri ne deriva un compito verificabile: stabilire le responsabilità, censire le versioni interessate e farsi confermare la correzione installata. Un nome di prodotto che suona sicuro o un aggiornamento del CMS riuscito non bastano. Decisivo è se è stato corretto proprio il software che elabora davvero le richieste pubbliche.
