Vulnerabilità critiche di PHP: il rischio per i siti delle comunità, delle istituzioni municipali e dei progetti regionali

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 in internet: WordPress, Joomla, OpenCart, Bitrix, Laravel. Sul piano regionale questo significa i siti dei consigli comunali e rurali, delle aziende municipali, delle scuole, delle biblioteche, dei musei e dei progetti di ricostruzione, cioè proprio quella parte dell'infrastruttura digitale che di norma non ha né un amministratore proprio né un budget per la manutenzione.

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é è una questione di resilienza digitale della comunità e non di un singolo sito

Nessuno cerca separatamente il sito di una comunità specifica. Quando gli esempi di sfruttamento diventano pubblici — e sono già pubblici — nel giro di poche ore partono scanner automatici che passano in rassegna tutto internet di seguito. Non fa differenza se si tratta del portale di un'amministrazione regionale o della pagina di una casa della cultura di paese: conta solo la versione con cui risponde il server.

La particolarità del settore pubblico è che le risorse stanno raramente da sole. Il sito del consiglio, il sistema delle istanze elettroniche, il calendario dei servizi e la pagina di un'azienda municipale vivono spesso sullo stesso hosting e sotto lo stesso account. Violando il più debole di essi, l'attaccante ottiene l'accesso agli altri e in seguito può non solo diffondere spam, ma anche pubblicare comunicati a nome dell'organo di governo. Per la comunità non è più un guasto tecnico, ma una perdita di fiducia nel canale ufficiale di informazione.

La conclusione pratica per chi risponde dell'ambito digitale in una comunità: conviene partire non dall'aggiornamento, ma dall'inventario — quali risorse esistono davvero, su quale hosting si trovano e chi ha accesso a esse. Molto spesso risulta che una parte dei siti da anni non è seguita da nessuno.

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 nella comunità o nell'istituzione non c'è uno specialista responsabile degli aggiornamenti, l'audit delle risorse si può commissionare all'esterno — in particolare a SmartGT.

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