Vulnerabilità critiche di PHP: perché le fondazioni benefiche dovrebbero controllare subito i propri siti

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 a un attaccante di eseguire codice proprio sul server — senza login, senza password, senza alcuna azione da parte del personale o dei volontari.

PHP è il linguaggio in cui è scritta la maggior parte dei siti in internet: WordPress, Joomla, OpenCart, Bitrix, Laravel. I siti delle fondazioni benefiche, delle iniziative di volontariato e delle raccolte fondi sono quasi sempre realizzati con esso, quindi il rischio li riguarda allo stesso modo delle grandi aziende.

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.

Che cosa comporta per la raccolta fondi

Nessuno cerca separatamente il sito di una fondazione specifica. Quando gli esempi di violazione 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 di un portale aziendale o di una pagina di raccolta per un'auto: conta solo se il server risponde con una versione vulnerabile.

Per una fondazione lo scenario più pericoloso non è quello in cui il sito è palesemente danneggiato. È il contrario: il sito funziona, ha l'aspetto di sempre — ma il numero della carta o i dati della raccolta sulla pagina sono stati cambiati in silenzio. Le donazioni arrivano, le persone trasferiscono denaro, e la cosa emerge quando qualcuno riconcilia gli incassi. Accanto a questo arrivano le conseguenze consuete: una web shell sul server, pubblicità estranea sulle pagine, il dominio nelle liste nere e la posta che non raggiunge più donatori e partner.

Il terzo rischio sono i dati. Gli elenchi dei donatori, le richieste dei reparti e i documenti sulla consegna degli aiuti 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 la fondazione non ha una persona responsabile del sito e dell'hosting, la verifica si può commissionare all'esterno — in particolare a SmartGT: esamineranno le risorse e diranno chiaramente se c'è una minaccia.

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