Vulnerabilità critiche di PHP: controllate il sito della vostra attività o iniziativa

Molti veterani, dopo il servizio, aprono una propria attività, si prendono in carico un progetto sociale o avviano un'iniziativa educativa — e quasi sempre a un certo punto compare un sito. Di solito è stato fatto con WordPress: in fretta, a basso costo, spesso per mano di un conoscente o di un freelance con cui da tempo non ci sono contatti.

Il 21 ottobre 2026 il team di PHP ha pubblicato aggiornamenti straordinari e la squadra europea di risposta agli incidenti informatici CERT-EU ha pubblicato un avviso urgente. Il motivo sono due vulnerabilità con un punteggio di pericolosità di 9,2 su 10, che consentono a un aggressore di eseguire codice proprio sul vostro server. Senza login, senza password, senza alcuna azione da parte vostra.

Qui sotto, senza linguaggio tecnico superfluo: che cosa è successo, perché riguarda anche il sito più piccolo e quali tre frasi vale la pena scrivere già oggi al proprio hoster.

Che cosa è stato trovato esattamente

Le vulnerabilità sono due, entrambe valutate 9,2 punti ed entrambe portano allo stesso risultato: l'esecuzione di codice estraneo sul server senza autenticazione.

CVE-2026-109618 — interruzione quando manca la memoria

In PHP esiste l'impostazione memory_limit: una richiesta che ha consumato troppa memoria viene interrotta a forza. Il problema è come esattamente viene interrotta. PHP può fermarsi nel momento in cui i dati interni della richiesta sono riempiti solo a metà — per esempio mentre viene analizzato un file inviato tramite un modulo di caricamento. La pulizia dopo una richiesta del genere prende i dati incompleti per dati veri e prova a liberare memoria che non è mai esistita. E in quella memoria può trovarsi ciò che l'aggressore vi ha messo con richieste precedenti.

CVE-2026-109619 — residui della richiesta precedente

La seconda falla riguarda il fatto che il server non «dimentica» del tutto il visitatore precedente. Lo stato interno che apparteneva a una richiesta a volte sopravvive alla liberazione della memoria, per esempio dopo un errore fatale. La richiesta successiva, finita nello stesso processo di lavoro, riesce a sfruttare quei residui prima che la normale inizializzazione li azzeri.

È a rischio qualsiasi installazione di PHP che serve richieste web: PHP-FPM, Apache con il modulo mod_php, php-cgi, FrankenPHP, LiteSpeed. La combinazione più rischiosa, secondo il team di PHP, è proprio quella di Apache con mod_php — è ancora quella standard su molti hosting economici.

L'exploit dimostrativo funziona con una sola richiesta non autenticata, prima ancora che inizi a girare il codice del sito stesso. Qui dunque non servono né i plugin di sicurezza, né le password complesse, né l'autenticazione a due fattori: l'attacco avviene un livello più in basso.

Quali versioni sono a rischio

Tutto ciò che è inferiore a queste versioni è vulnerabile:

Ramo di PHP	Versione sicura
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 e precedenti	nessun supporto

Una categoria di rischio a parte sono i prodotti commerciali e open source che hanno PHP incorporato, anche se da fuori non si vede: pannelli di gestione, dispositivi di rete, sistemi di videosorveglianza, portali aziendali. L'elenco di questo software è tenuto nel repository del NCSC olandese.

Perché «ho un sito piccolo» qui non salva

Nessuno cerca il vostro sito in particolare. Quando gli esempi dell'attacco diventano pubblici — e sono già pubblici — in poche ore partono scanner automatici che passano al setaccio tutta la rete, indirizzo dopo indirizzo. Non importa loro se si tratta del sito di una grande azienda o della pagina di un'officina con cinque servizi: conta solo se il server risponde con una versione vulnerabile.

Poi lo scenario è tipico: sul server viene caricato codice altrui, il sito comincia a distribuire spam o pagine con pubblicità altrui, il dominio finisce nelle liste nere e la posta inviata da lì non arriva più ai clienti. Per una piccola attività questo fa male il doppio: il sito è spesso l'unica vetrina, e per rimettere tutto in ordine servono settimane e soldi che non erano previsti.

Avvertiamo a parte su ciò che di solito segue. Dopo notizie del genere si attivano i «tecnici» che scrivono di propria iniziativa ai proprietari dei siti: «avete una vulnerabilità, dateci subito gli accessi». Gli accessi al sito e all'hosting consegnateli solo a chi conoscete e a chi pagate per la manutenzione.

Cosa fare — passo per passo

1. Scoprite la vostra versione. Nel pannello dell'hosting è la sezione «Versione PHP» o «PHP Selector»; su un server proprio, il comando php -v. È importante controllare la versione con cui gira davvero il sito, non quella presente nella riga di comando: spesso sono diverse.
2. Aggiornate all'interno del vostro ramo. Passare da 8.2.29 a 8.2.35 è una correzione all'interno di un solo ramo: la compatibilità è mantenuta e il sito non si rompe. Non confondetelo con il passaggio da 8.2 a 8.4 — quello sì richiede verifiche.
3. Se avete la 8.1 o una versione più vecchia — questi rami non hanno supporto. Data la gravità della situazione il team di sicurezza di PHP ha pubblicato correzioni minime anche per 7.4, 8.0 e 8.1, e una parte degli hoster mantiene build proprie. La scelta giusta resta però il passaggio a un ramo supportato, e conviene pianificarlo adesso e non la prossima volta.
4. Riavviate i gestori. Senza riavviare php-fpm o Apache i processi di lavoro continuano a girare sul codice vecchio e l'aggiornamento di fatto non ha effetto.
5. Verificate il risultato. La cosa più semplice è una pagina temporanea con phpinfo(), che va cancellata subito dopo il controllo, oppure la sezione «Versione PHP» nel pannello dopo il riavvio.

Ai clienti di un hosting di solito non toccherà fare nulla a mano: i grandi provider hanno ricevuto le correzioni in anticipo e aggiornano le proprie macchine da sé. Vale la pena scrivere una riga all'assistenza — «PHP è stato aggiornato alle versioni del 21 ottobre 2026?» — e ottenere la risposta per iscritto.

Se aggiornare subito non è possibile

Capita che il sito sia vecchio e che l'aggiornamento richieda preparazione. Allora esistono misure temporanee che restringono la finestra per un attacco:

• chiudere l'esaurimento della memoria come punto d'ingresso: memory_limit=-1, impostato in modo che l'applicazione non possa sovrascriverlo, e una verifica che nessun pool o directory riporti indietro il limite;
• ridurre post_max_size — 8M per i siti senza caricamento di file, 32M se i caricamenti servono, e upload_max_filesize tenerlo più basso;
• disattivare session.upload_progress.enabled e riavviare tutti i processi di lavoro;
• su PHP 8.5 disattivare inoltre fatal_error_backtraces;
• limitare dimensione e complessità delle richieste a livello di server web o proxy.

Nessuna di queste misure rende sicura l'installazione. Chiudono solo le vie note: il problema lo chiude del tutto soltanto l'aggiornamento.

Se nemmeno questo è possibile, CERT-EU consiglia una soluzione semplice e impopolare: togliere il servizio vulnerabile dall'internet pubblico finché la correzione non è installata e verificata.

Da dove vengono questi dati

• CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP»
• L'annuncio del rilascio degli aggiornamenti su php.net
• Descrizione tecnica di CVE-2026-109618 e CVE-2026-109619

---

Se non sapete con che cosa è fatto il vostro sito e chi ne risponde, è già un motivo per chiarirlo senza aspettare la prossima notizia. La verifica si può commissionare anche a SmartGT, il team che cura le risorse digitali del cluster.

Autore del materiale — SmartGT. Fonte originale: «Vulnerabilità critiche di PHP: l'aggiornamento non può aspettare».