News

Falle critiche in PHP e siti offline: cosa è successo e come abbiamo protetto i nostri clienti

Due falle critiche in PHP hanno spinto governi e aziende a spegnere i siti. Cosa è successo e come FF-Design ha protetto i clienti senza fermare i server.

Codice sorgente su un monitor: le falle critiche di PHP riguardano il software dei server webNews
Foto: Markus Spiske markusspiske · CC0 · Wikimedia Commons
Ascolta l’articoloLetto da voce AI · 8 min 59 s

Tra il 20 e il 21 ottobre 2026 in tutto il mondo molti siti sono stati spenti di proposito. Tra questi c'erano pagine di governi europei, alcune voci di Wikipedia e i siti di prefetture francesi. Il motivo erano due falle critiche in PHP, il linguaggio su cui gira la maggior parte dei siti web, e la paura che gli attacchi informatici partissero prima degli aggiornamenti. In questo articolo spieghiamo in modo semplice cosa è successo, perché tanti siti sono andati offline e come abbiamo protetto i siti dei nostri clienti di Termoli, Vasto e di tutto il Molise senza spegnere i server nemmeno per un minuto.

Cosa è successo: due falle critiche in PHP

PHP è il "motore" che produce le pagine di moltissimi siti: WordPress, e-commerce, gestionali, aree riservate. Secondo Il Post, è alla base di circa sette siti su dieci.

Il 20 ottobre il team di sviluppo di PHP ha annunciato in anticipo un aggiornamento di sicurezza per due vulnerabilità, e il 21 ottobre lo ha pubblicato. Le falle sono:

  • CVE-2026-109618, legata a come PHP gestisce la memoria quando una richiesta la esaurisce;
  • CVE-2026-109619, legata a dati interni che possono "sopravvivere" da una richiesta a quella successiva.

Entrambe hanno ricevuto un punteggio di gravità di 9,2 su 10. Il punto più preoccupante è che, nei casi peggiori, un malintenzionato può arrivare a eseguire codice sul server senza bisogno di password, con richieste costruite ad arte. In pratica può prendere il controllo del sito e, a volte, dei dati che contiene.

Secondo quanto riportato dal Post, a scoprirle sono stati ricercatori delle aziende di sicurezza Calif e Wiz, aiutati da strumenti di intelligenza artificiale. Erano rimaste nascoste nel codice per oltre dieci anni.

Rack di server con cavi di rete in un data center
I server che fanno girare i siti: la patch va installata qui, non nel sito.
Foto: Kim Scarborough from Chicago, IL · CC BY-SA 2.0 · Wikimedia Commons

Perché tanti siti sono andati offline

Il problema non riguardava un plugin o un tema, ma PHP stesso. Aggiornare WordPress quindi non bastava: andava aggiornato il software installato sul server.

Le versioni corrette sono uscite per i rami ancora supportati:

  1. PHP 8.5.12
  2. PHP 8.4.27
  3. PHP 8.3.36
  4. PHP 8.2.35

Le versioni 8.1 e precedenti non ricevono più aggiornamenti ufficiali. Chi è ancora su versioni vecchie è rimasto quindi più esposto.

Le agenzie per la sicurezza informatica, tra cui quelle europee e britanniche, hanno dato un'indicazione molto chiara: aggiornare subito o, se non è possibile, mettere offline i siti finché la patch non è installata. Lo stesso PHP ha scritto che non esistono contromisure complete e che aggiornare è l'unica scelta sicura.

Per un'amministrazione pubblica con decine di server, aggiornare tutto in poche ore è difficile. Molte hanno preferito spegnere temporaneamente i siti. È una scelta prudente, ma ha un costo: servizi non disponibili e utenti bloccati.

Una falla di sicurezza non si risolve con un "aggiornamento automatico prima o poi": conta quanto velocemente qualcuno se ne accorge e interviene.

Come abbiamo gestito la situazione sui server FF-Design

I siti dei nostri clienti girano su server che gestiamo direttamente. Questo ci ha permesso di intervenire subito, senza aspettare un fornitore esterno. Ecco cosa abbiamo fatto, passo per passo.

1. Verifica dell'esposizione

Per prima cosa abbiamo controllato quali versioni di PHP erano in uso e come erano configurate. Sui nostri server PHP 8.3 gira tramite PHP-FPM, non come modulo integrato nel web server (mod_php), che secondo il team di PHP è lo scenario più rischioso. Era comunque necessario aggiornare.

2. Aggiornamento appena disponibile la patch

La versione corretta PHP 8.3.36 è stata installata nella notte successiva al rilascio, a meno di dodici ore dalla pubblicazione ufficiale. I processi di PHP sono stati poi riavviati: il riavvio è durato meno di un secondo e i siti sono rimasti sempre raggiungibili. Nessun cliente è dovuto andare offline.

3. Controllo dei log e dei possibili accessi

Aggiornare chiude la porta, ma bisogna anche verificare che nessuno sia entrato prima. Abbiamo analizzato i log di tutti i siti ospitati dal 15 al 22 ottobre, oltre 400.000 richieste, cercando i segnali tipici di questo tipo di attacco:

  • crash dei processi di PHP dovuti a memoria corrotta;
  • errori di memoria esaurita provocati da richieste anomale;
  • abusi delle funzioni di caricamento dei file;
  • richieste che tentano di leggere file di sistema o di eseguire codice.

Il risultato: nessun indizio di sfruttamento delle due falle. Abbiamo trovato solo i normali tentativi automatici che ogni sito riceve ogni giorno, come scansioni di cartelle e percorsi inesistenti. Sono stati tutti respinti dal server con un errore "pagina non trovata".

Codice su uno schermo durante l'analisi dei log di un server
Dopo l'aggiornamento abbiamo analizzato i log per escludere accessi sospetti.
Foto: Sai Kiran Anagani _imkiran · CC0 · Wikimedia Commons

4. Monitoraggio dei sistemi dei clienti

Nei giorni successivi abbiamo tenuto sotto controllo i siti e i gestionali dei nostri utenti: disponibilità, errori, carico dei server e richieste sospette. Se fosse arrivato un attacco, lo avremmo visto e bloccato subito.

Cosa può fare chi ha un sito con un altro fornitore

Se il tuo sito non è gestito da noi, ecco le domande da fare subito al tuo hosting o al tuo sviluppatore:

  1. Quale versione di PHP usa il mio sito? Deve essere una delle versioni corrette elencate sopra, o una versione con la patch inclusa dalla distribuzione Linux.
  2. Quando è stato aggiornato? Ogni giorno di ritardo è un rischio in più.
  3. Avete controllato i log? Un sito aggiornato tardi potrebbe essere stato attaccato prima.
  4. Il mio sito è su PHP 8.1 o più vecchio? In quel caso serve una migrazione a una versione supportata.

Molti siti di piccole attività del territorio, tra Termoli, San Salvo, Vasto e Campobasso, sono su hosting economici o non vengono aggiornati da anni. Sono proprio quelli che rischiano di più.

Domande frequenti

Il mio sito WordPress è a rischio?

Se il server usa una versione di PHP non aggiornata, sì. La falla è in PHP, non in WordPress: aggiornare solo WordPress e i plugin non basta.

Devo spegnere il sito?

Solo se non puoi aggiornare PHP in tempi brevi. Se il tuo fornitore installa subito la patch, come abbiamo fatto noi, non serve andare offline.

Come capisco se qualcuno è entrato nel mio sito?

Servono i log del server e qualcuno che sappia leggerli. Segnali da non ignorare sono file modificati che non riconosci, nuovi utenti amministratori o pagine che reindirizzano altrove.

I siti ospitati da FF-Design sono aggiornati?

Sì. Tutti i siti sui nostri server sono passati a PHP 8.3.36 e sono stati controllati uno per uno, senza interruzioni del servizio.

Vuoi un sito gestito da chi interviene subito?

Episodi come questo mostrano la differenza tra un sito "messo online e dimenticato" e un sito seguito davvero. Con il nostro servizio di hosting, sicurezza e assistenza aggiornamenti, backup e monitoraggio sono compresi. Se vuoi sapere se il tuo sito è in regola, possiamo fare anche una verifica tecnica e legale.

Richiedi la bozza gratuita o un controllo del tuo sito su ff-design.it: ti rispondiamo entro 24 ore.

Fonti

Continua a leggere

Altri articoli.

Lucchetto aperto su un computer portatile: sicurezza del sito web per le attività di Vasto e TermoliSiti web
Siti web ·

Sicurezza del sito web a Vasto e Termoli: HTTPS, aggiornamenti e avvisi di Chrome

Sicurezza del sito web a Vasto e Termoli: con Chrome 154 i siti senza HTTPS mostrano un avviso. Checklist pratica, GDPR e quando rifare il sito.

Leggi l’articolo
Smartphone con barra di ricerca: come i clienti cercano un ristorante vicino a meSEO e Google
SEO e Google ·

Sito web per ristoranti a Venafro e Bojano: farsi trovare nelle ricerche "vicino a me"

Sito web per ristoranti a Venafro e Bojano: come Google sceglie i locali nelle ricerche "vicino a me", cosa mettere sul sito ed errori da evitare.

Leggi l’articolo
Laptop su una scrivania ordinata: controllo del cookie banner del sito di un'attività di LarinoPrivacy e norme
Privacy e norme ·

Cookie banner a norma a Larino e Guglionesi: le regole del Garante per il tuo sito

Cookie banner a Larino e Guglionesi: regole del Garante Privacy, errori più comuni e come mettere in regola il sito della tua attività.

Leggi l’articolo
Contatti

Raccontami il progetto.
Ti rispondo in 24 ore.

Due righe bastano. Se ha senso, prepariamo insieme la bozza gratuita.

Email[email protected] Telefono+39 349 930 9324 WhatsAppScrivimi ora

Termoli · Vasto · San Salvo · Basso Molise

Richiesta di progettoFF—01
Inserisci il tuo nome
Indirizzo email non valido
Scrivi almeno due righe sul progetto

Nessuna newsletter · Nessun dato ceduto a terzi