Falle critiche PHP: il tuo sito web è davvero sicuro?

Il tuo sito aziendale funziona perfettamente. Le pagine si aprono, i clienti possono contattarti e magari ricevi regolarmente ordini o richieste di preventivo. Perché dovresti preoccuparti della sua sicurezza?

Perché un sito può funzionare normalmente e avere comunque una vulnerabilità grave. Non sempre un problema informatico produce un messaggio di errore o un'interruzione evidente.

È quanto ci ricorda l'allerta del 21 ottobre 2026: due gravi falle nel motore PHP hanno richiesto aggiornamenti urgenti e misure precauzionali da parte di organizzazioni pubbliche e private.

La questione non riguarda soltanto grandi portali e università. Riguarda potenzialmente anche siti aziendali, negozi online, blog e piattaforme realizzate con tecnologie che utilizzano PHP.

Le vulnerabilità PHP dell'ottobre 2026: cosa è successo?

Il 21 ottobre 2026 il PHP Security Team ha pubblicato aggiornamenti straordinari per correggere due vulnerabilità classificate come critiche:

CVE-2026-109618

Critica · CVSS v4.0 9,2/10. Un problema di gestione della memoria che, se sfruttato nelle condizioni necessarie, può permettere l'esecuzione di codice non autorizzato.

CVE-2026-109619

Critica · CVSS v4.0 9,2/10. Una seconda vulnerabilità, anch'essa legata alla gestione interna della memoria e potenzialmente sfruttabile per eseguire codice da remoto.

Il dato più preoccupante è che l'attacco, in determinate condizioni, può essere eseguito senza disporre di una password amministrativa. In alcuni scenari la vulnerabilità può essere raggiunta prima ancora che venga eseguito il codice del sito.

Fonti: CERT-AGID ed ENISA, 21 ottobre 2026 (collegamenti nelle fonti ufficiali in fondo alla pagina).

Il 23 ottobre è stata inoltre segnalata una terza vulnerabilità, CVE-2026-115560, riguardante particolari configurazioni PHP meno comuni. Questo ulteriore aggiornamento conferma l'importanza di seguire i bollettini di sicurezza e non limitarsi a verificare una sola volta la versione installata.

Perché alcuni servizi pubblici sono stati sospesi?

Non è necessario che un sito sia già stato attaccato per decidere di sospenderlo temporaneamente. Quando emerge una vulnerabilità particolarmente grave, impedire l'accesso dall'esterno può essere una misura di prevenzione.

È successo all'Università degli Studi di Roma Tor Vergata, che il 21 ottobre 2026 ha comunicato una limitazione precauzionale dell'accessibilità dei servizi web dall'esterno della rete universitaria.

La decisione è stata adottata dopo gli avvisi dell'Agenzia per la Cybersicurezza Nazionale e del CERT-EU, per consentire aggiornamenti e verifiche tecniche.

L'Ateneo aveva previsto il ripristino completo dei servizi entro il 26 ottobre. Questo non significa che i suoi sistemi fossero stati necessariamente compromessi: significa che la minaccia è stata ritenuta abbastanza seria da giustificare un intervento preventivo.

La domanda allora è inevitabile: se un'organizzazione dotata di personale e infrastrutture informatiche dedicate adotta precauzioni del genere, come dovrebbe comportarsi una piccola azienda che non sa nemmeno quale versione PHP utilizza il proprio hosting?

PHP è davvero un linguaggio insicuro?

PHP è utilizzato per sviluppare siti web e applicazioni dinamiche. WordPress, per esempio, si basa su PHP e può essere impiegato per siti aziendali, blog, cataloghi e negozi online.

Ma sarebbe scorretto affermare che PHP sia, per sua natura, un linguaggio insicuro.

Le vulnerabilità possono interessare qualsiasi tecnologia. La differenza la fanno la manutenzione, la rapidità con cui vengono applicati gli aggiornamenti e le protezioni predisposte sul server.

Un sito realizzato con PHP, ben configurato e regolarmente mantenuto, può offrire un buon livello di sicurezza. Un sito trascurato, invece, può accumulare rischi anche senza mostrare alcun malfunzionamento.

Cosa può succedere a un'azienda dopo un attacco?

Un attacco riuscito non significa soltanto trovare una pagina modificata. A seconda della vulnerabilità e dei permessi ottenuti, le conseguenze possono coinvolgere dati, funzionalità del sito e continuità dell'attività.

Furto dei dati

Se il sistema compromesso consente l'accesso a informazioni riservate, potrebbero essere sottratti dati dei clienti, ordini, documenti e credenziali.

Pagine alterate e truffe

Un aggressore potrebbe modificare contenuti o reindirizzare i visitatori verso pagine fraudolente, danneggiando la credibilità dell'attività.

Malware e accessi nascosti

Alcuni attacchi permettono di introdurre script malevoli o strumenti per mantenere accessi non autorizzati nel tempo.

Interruzione dell'attività

Per un e-commerce o un sito di prenotazioni, l'indisponibilità del servizio può significare vendite perse, ritardi e costi di ripristino.

Non tutte queste conseguenze si verificano in ogni attacco. Molto dipende da come è configurato il server e da quali parti del sistema l'aggressore riesce effettivamente a raggiungere.

Non solo PHP: anche i plugin non aggiornati rappresentano un rischio

C'è un altro aspetto che molti proprietari di siti sottovalutano: anche quando PHP è aggiornato, un plugin vulnerabile può mettere in pericolo il sito.

Pensiamo a un sito WordPress che utilizza un plugin per i moduli di contatto, un sistema di prenotazioni o una galleria fotografica. Se viene scoperta una falla e lo sviluppatore rilascia una correzione, continuare a utilizzare la versione precedente può lasciare aperta una possibilità di attacco.

Alcune vulnerabilità dei plugin permettono di ottenere accessi non autorizzati, visualizzare informazioni riservate o modificare file e contenuti. Altre hanno conseguenze più limitate. Non tutti i plugin obsoleti sono automaticamente vulnerabili, ma trascurare gli aggiornamenti aumenta il rischio.

Anche un componente disattivato, se ancora presente sul server, può costituire un problema in determinate circostanze.

Per questo motivo la manutenzione deve interessare PHP, CMS, temi, plugin e configurazioni del server, non un unico elemento.

Come sapere se il proprio sito utilizza una versione PHP a rischio?

La prima verifica riguarda la versione PHP effettivamente utilizzata dal server e le patch applicate dal fornitore hosting.

Al 24 ottobre 2026, le principali versioni corrette per le due vulnerabilità critiche sono:

Versioni rilasciate il 21 ottobre 2026. Le distribuzioni che applicano patch retroportate possono utilizzare numerazioni differenti. Fonte: CERT-EU.

Non sempre è possibile ottenere queste informazioni dall'esterno. Alcuni server nascondono la versione PHP e altri utilizzano versioni con correzioni specifiche del fornitore.

Quindi, vedere un numero di versione non equivale automaticamente a dimostrare che un sito sia vulnerabile. Serve una verifica tecnica contestualizzata.

Una prima analisi gratuita può aiutarti a individuare altri segnali di rischio

Chi gestisce un'attività non sempre dispone delle competenze per interpretare configurazioni e registri del server. Un controllo preliminare del sito può comunque mettere in evidenza elementi tecnici che meritano attenzione.

Aggiornare PHP basta per rendere nuovamente sicuro un sito?

Non sempre. Se una vulnerabilità è già stata sfruttata, installare l'aggiornamento elimina il problema noto nel software ma potrebbe non cancellare le conseguenze dell'attacco.

Un aggressore potrebbe aver lasciato file modificati, credenziali sottratte o accessi nascosti.

In questi casi bisogna verificare l'integrità del sito, controllare gli accessi, individuare gli eventuali elementi malevoli e valutare il ripristino da una copia affidabile.

È importante distinguere la prevenzione di un attacco dalla bonifica di un sito già compromesso. Sono attività collegate, ma non equivalenti.

Cosa dovrebbe fare oggi il proprietario di un sito web?

Non è necessario diventare esperti di cybersicurezza per adottare alcune precauzioni. È però importante sapere chi gestisce la manutenzione del sito e quali controlli vengono effettuati.

• Chiedere al proprio hosting quale versione PHP sia in uso e se siano state applicate le ultime correzioni.
• Aggiornare WordPress o altri CMS, temi e plugin, eliminando i componenti inutilizzati.
• Controllare che i backup siano recenti e possano essere effettivamente ripristinati.
• Proteggere gli accessi amministrativi con password robuste e autenticazione a più fattori dove disponibile.
• Richiedere una verifica approfondita se emergono comportamenti insoliti o sospetti di compromissione.

La sicurezza di un sito non dovrebbe diventare una preoccupazione soltanto dopo un attacco

Quando un sito funziona normalmente, gli aggiornamenti e la manutenzione finiscono spesso in secondo piano. È comprensibile: per chi gestisce un'azienda ci sono clienti, ordini, fornitori e scadenze più immediate.

Ma un sito aziendale non è semplicemente un insieme di pagine online. È uno strumento di lavoro, e in molti casi gestisce contatti, documenti, prenotazioni e informazioni importanti.

L'allerta PHP dell'ottobre 2026 dimostra quanto velocemente una vulnerabilità software possa diventare una questione concreta anche per organizzazioni strutturate.

La prevenzione non elimina qualsiasi rischio, ma permette di affrontare i problemi prima che diventino emergenze.