Vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619: cosa fare subito con il proprio sito

Il 21 ottobre 2026 alle 16:00, ora svizzera, il progetto PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Correggono due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, che in determinate condizioni permettono a un attaccante di eseguire codice su un server web senza autenticazione e senza alcuna interazione dell'utente. Lo stesso giorno l'Ufficio federale della cibersicurezza (UFCS) ha raccomandato di installare gli aggiornamenti senza indugio.

PHP è il linguaggio su cui girano WordPress, Joomla, Drupal, Magento, le applicazioni Laravel e Symfony e moltissimi negozi online e gestionali. Se il vostro sito usa uno di questi sistemi, la vulnerabilità vi riguarda. Qui sotto trovate i fatti verificati, le versioni da installare e una checklist pratica.

Cosa è successo

Secondo l'avviso di sicurezza di php.net, le due falle si trovano nel nucleo di PHP, nella gestione della memoria e degli errori, cioè in parti che quasi ogni richiesta attraversa:

• CVE-2026-109618: quando una richiesta esaurisce la memoria nel momento sbagliato, PHP può lasciare dati interni inizializzati solo in parte e trattarli poi come validi, corrompendo la memoria.
• CVE-2026-109619: uno stato interno legato a una richiesta può sopravvivere dopo che la memoria corrispondente è stata liberata; una richiesta successiva gestita dallo stesso processo può riutilizzarlo.

Entrambe hanno un punteggio CVSS 4.0 di 9,2 su 10, livello critico. Il valore di 10.0 circolato sui social prima della pubblicazione era sbagliato, come precisa la PHP Foundation. Nei media le falle sono chiamate anche «PHP2Shell», per analogia con Log4Shell del 2021.

Le vulnerabilità sono state segnalate dalle società di sicurezza Calif e Wiz e da OpenAI. La pubblicazione era prevista per il 22 ottobre, ma il 20 ottobre gli identificativi CVE hanno iniziato a circolare online e il progetto PHP ha anticipato il rilascio di un giorno.

Chi è interessato

Secondo php.net è a rischio ogni installazione PHP che risponde a richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto riguarda Apache con mod_php, dove è stato dimostrato un attacco che parte con una richiesta non autenticata prima ancora che venga eseguito il codice dell'applicazione. Le versioni vulnerabili vanno dalla 5.4 alla 8.5.11; il BSI tedesco parla di tutte le versioni almeno dalla PHP 5 in poi.

L'UFCS ricorda che la verifica non va limitata ai siti pubblici: PHP può trovarsi anche in pannelli di amministrazione, applicazioni interne, piattaforme di hosting, container e dispositivi, a volte senza che chi li usa lo sappia.

Lo stato della minaccia

Alla data della pubblicazione non risultavano sfruttamenti confermati. Il BSI segnalava però notizie non confermate di exploit già esistenti e il Centro canadese per la cibersicurezza riferisce che è disponibile una prova di concetto. Secondo la BBC, il responsabile tecnico di Cloudflare ha dichiarato di vedere i primi tentativi di attacco.

Diverse autorità hanno messo temporaneamente offline i propri siti a scopo precauzionale fino all'installazione della correzione: in Germania, per esempio, i siti del governo del Baden-Württemberg e di varie università (tagesschau); secondo la BBC anche i servizi web pubblici del governo finlandese. Non si è trattato di attacchi riusciti ma di una misura di prudenza.

Le versioni da installare

• PHP 8.5: versione 8.5.12
• PHP 8.4: versione 8.4.27
• PHP 8.3: versione 8.3.36
• PHP 8.2: versione 8.2.35 (fine del supporto il 31 dicembre 2026)

PHP 8.1, 8.0, 7.x e precedenti non ricevono più aggiornamenti ufficiali. Il team di sicurezza di PHP ha pubblicato correzioni minime nel codice sorgente per 7.4, 8.0 e 8.1, e alcune distribuzioni Linux offrono pacchetti corretti, ma la soluzione raccomandata è passare a una versione supportata.

Attenzione al numero di versione sui server Linux: le distribuzioni applicano spesso la correzione alla propria versione del pacchetto. Su Ubuntu 24.04, per esempio, il pacchetto corretto è 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), su Debian 13 è 8.4.27-1~deb13u1 (DSA-6574-1). Conta la versione esatta del pacchetto indicata dal fornitore, non solo il numero mostrato da PHP.

Cosa fare adesso

Con un hosting gestito

Se il sito è su un hosting condiviso o gestito, l'aggiornamento di PHP spetta al provider. Chiedetegli una conferma scritta che la correzione è installata, come suggerisce anche l'UFCS. Nel pannello di controllo verificate quale versione di PHP usa il sito: se è 8.1 o precedente, pianificate subito il passaggio a 8.3 o 8.4, provandolo prima su una copia del sito.

Con un VPS o un server proprio

1. Fate un backup o uno snapshot del server, compresi database e file caricati.
2. Aggiornate i pacchetti PHP dal gestore della distribuzione (su Debian e Ubuntu: apt update e aggiornamento dei pacchetti PHP).
3. Riavviate PHP-FPM e il server web: senza riavvio i processi continuano a usare il codice vecchio.
4. Verificate la versione realmente in uso con php -v e con la versione del pacchetto, anche per il processo che serve il sito.
5. Ricostruite e ridistribuite le immagini Docker che contengono PHP.
6. Controllate i log per richieste insolite, crash, file modificati e processi inattesi: un aggiornamento non ripara una compromissione già avvenuta.

Una buona pratica in più: impostare expose_php = Off, così il server non annuncia la versione di PHP nelle intestazioni HTTP. Non protegge dalla falla, ma riduce le informazioni utili a chi cerca server non aggiornati.

Se non potete aggiornare subito

php.net indica alcune misure temporanee, per esempio session.upload_progress.enabled=0 e un valore basso per post_max_size. Riducono solo alcune vie di attacco e non rendono sicura l'installazione. Secondo l'UFCS anche un firewall per applicazioni web da solo non basta. Per le applicazioni critiche va valutata la disconnessione temporanea da Internet.

Checklist in breve

1. Fate l'elenco di siti, negozi online, gestionali e pannelli che usano PHP.
2. Per ognuno annotate chi lo gestisce e quale versione di PHP usa.
3. Chiedete al provider di hosting la conferma che la correzione è installata.
4. Sui server propri: backup, aggiornamento, riavvio dei servizi, verifica della versione.
5. Pianificate il passaggio da PHP 8.1 o precedente a una versione supportata.
6. Aggiornate anche CMS, temi e plugin, che sono un tema separato.
7. Controllate i log e i file del sito nei prossimi giorni.

Domande frequenti

Il mio sito WordPress è a rischio?

WordPress funziona con PHP, quindi sì, se il server usa una versione di PHP non corretta. Il problema non è in WordPress ma nel linguaggio sotto: aggiornare WordPress e i plugin è utile, ma non sostituisce l'aggiornamento di PHP.

Come scopro quale versione di PHP usa il mio sito?

Nel pannello dell'hosting, di solito nella sezione PHP o nella configurazione del sito. In WordPress la trovate in Strumenti, Salute del sito, Info, Server. Su un server proprio con il comando php -v e con la versione del pacchetto installato.

Il mio sito usa ancora PHP 7.4: cosa faccio?

PHP 7.4 non riceve più aggiornamenti ufficiali. Le correzioni minime pubblicate per 7.4 sono pensate per chi compila PHP da sé o non ha un fornitore con supporto esteso. Per un sito aziendale la strada corretta è la migrazione a PHP 8.3 o 8.4, con un test preventivo su una copia del sito.

Basta un firewall o un servizio come Cloudflare?

No. Possono filtrare alcuni attacchi noti, ma l'UFCS precisa che un firewall per applicazioni web da solo non è sufficiente. L'unica soluzione completa è l'aggiornamento.

L'aggiornamento può bloccare il sito?

Un aggiornamento all'interno dello stesso ramo, per esempio da 8.3.35 a 8.3.36, è una release di sicurezza e di norma non cambia il funzionamento. Il passaggio a un ramo nuovo, per esempio da 7.4 a 8.3, va invece provato prima su una copia, perché temi, plugin o codice vecchio possono non essere compatibili.

Ho aggiornato: devo fare altro?

Riavviate i servizi PHP, verificate la versione in uso e controllate i log. Se notate file modificati, utenti amministratore sconosciuti o processi strani, trattate il server come compromesso.

Il nostro approccio

ElaraTeq Sagl gestisce siti e applicazioni per PMI ed enti in Ticino con hosting in Svizzera. Possiamo verificare quale versione di PHP usa il vostro sito, installare la correzione o pianificare la migrazione da una versione non più supportata. Per la manutenzione continua c'è il servizio descritto in Orbit; per una verifica, scriveteci. Per le altre misure di base si veda anche Una fattura falsa può fermare una PMI.

Fonti

• PHP, «Security advisory: Critical remote code execution vulnerabilities, update now», 21 ottobre 2026: php.net
• PHP, avvisi GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) e GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, «Today's PHP Security Release», 21 ottobre 2026: thephp.foundation
• UFCS, «Vulnerabilità critiche in PHP: installate immediatamente gli aggiornamenti di sicurezza», 21 ottobre 2026: bacs.admin.ch
• BSI, «PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit», 21 ottobre 2026: bsi.bund.de
• Ubuntu, USN-8948-1; Debian, DSA-6574-1
• Canadian Centre for Cyber Security, AL26-026
• tagesschau/SWR, 21 ottobre 2026: siti del Baden-Württemberg offline per precauzione; BBC, 21 ottobre 2026: Websites taken down worldwide