Vulnerabilità critiche di PHP: cosa significa per i siti dei progetti di ricostruzione

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. Due vulnerabilità con un punteggio di pericolosità di 9,2 su 10 consentono di eseguire codice estraneo sul server senza autorizzazione.

PHP è il linguaggio in cui è scritta la maggior parte dei siti: WordPress, Joomla, OpenCart, Bitrix, Laravel. Nel contesto della ricostruzione questo significa portali di programmi, pagine di raccolta fondi, registri dei beni danneggiati, siti di organizzazioni civiche e di appaltatori, cioè risorse in cui convivono dati personali, documenti e dati di pagamento.

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é un sito di progetto violato è una questione di fiducia e non solo di tecnica

Nessuno cerca il vostro progetto in particolare. Quando gli esempi di sfruttamento 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 portale di un programma nazionale o della pagina di un'iniziativa per un solo comune: conta solo la versione con cui risponde il server.

Le conseguenze tipiche sono note: una webshell sul server, spam e pubblicità altrui sulle pagine, il dominio nelle liste nere, la posta che non arriva più. Ma per i progetti di ricostruzione la cosa più costosa è un'altra. In primo luogo, la sostituzione delle coordinate bancarie per i contributi: lo scenario classico in cui un sito con le donazioni viene violato non per danneggiarlo, ma per cambiare in silenzio il numero di conto. In secondo luogo, la rendicontazione pubblica: se documenti e cifre possono essere modificati dall'esterno, perde senso la trasparenza stessa su cui si regge la fiducia di donatori e partner.

In terzo luogo, i dati delle persone. Le domande, i registri dei beni danneggiati e i questionari dei partecipanti ai programmi di solito si trovano sullo stesso server del sito.

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 nel vostro progetto non c'è una persona responsabile degli aggiornamenti e degli accessi, l'audit delle risorse può essere commissionato all'esterno — in particolare a SmartGT.

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