Vulnerabilità critiche PHP: cosa fare subito

Due falle da 9.2 su 10 espongono a esecuzione di codice remoto senza autenticazione. Guida operativa alla verifica e all'aggiornamento.

22 ottobre 2026 · 3SM TECH SRLS

Cosa è successo

Il 21 ottobre 2026 il team di sicurezza di PHP ha pubblicato quattro release correttive: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Chiudono due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, entrambe valutate 9.2 su 10 nella scala CVSS v4.0.

Il dettaglio che le rende serie è la natura della falla: consentono l'esecuzione di codice remoto senza autenticazione. Non serve una password né un account valido. È sufficiente che il server risponda a richieste web.

Sono interessate tutte le modalità con cui PHP serve pagine: PHP-FPM, Apache con mod_php, php-cgi, LiteSpeed, FrankenPHP.

Se il vostro sito gira su PHP 8.1 o versioni anteriori, nessun aggiornamento ufficiale arriverà: l'unica strada è migrare a un ramo supportato.

Perché riguarda anche chi non si occupa di siti web

La reazione comune è "io non faccio siti, non mi riguarda". Nella pratica PHP gira in molti più posti di quanti se ne ricordino.

• Il sito vetrina dell'azienda, quasi sempre WordPress, Joomla o PrestaShop
• I gestionali interni: preventivi, rapportini, magazzino, scadenzari
• I pannelli di amministrazione di apparati e piattaforme self-hosted
• Le aree riservate per i clienti e i portali di assistenza
• Installazioni dimenticate: vecchi siti, ambienti di test, sottodomini mai dismessi

Un'esecuzione di codice remoto senza autenticazione significa che un attaccante può eseguire comandi sul server. Da lì può leggere il database, installare una web shell, usare la macchina come ponte verso altro.

Il punto più spesso trascurato sono proprio le installazioni dimenticate. Un sottodominio di prova rimasto online da anni espone lo stesso server del sito principale, ma nessuno lo aggiorna perché nessuno se lo ricorda.

Verificare la versione in uso: due minuti

Prima di qualsiasi intervento serve sapere da dove si parte. Il metodo cambia in base al tipo di hosting.

Hosting condiviso (Aruba, Register, Netsol e simili). Nel pannello di controllo c'è una sezione dedicata alla gestione PHP: mostra il ramo attivo e spesso include un collegamento a PHPinfo con la versione esatta. È il dato che serve: non basta sapere di essere su "PHP 8.3", serve la terza cifra.

VPS o server dedicato, via SSH.

php -v              # versione dell'interprete da riga di comando
ls /etc/php/        # rami installati sul sistema
php-fpm8.3 -v       # versione che serve davvero le pagine web

La versione da riga di comando e quella usata dal web server possono differire. Quella che conta per queste CVE è la seconda, perché è quella esposta alle richieste in arrivo.

Metodo universale, da usare con cautela. Si carica nella root un file con <?php echo PHP_VERSION;, lo si apre da browser e lo si cancella subito dopo. Da evitare invece un phpinfo() lasciato online: espone percorsi, estensioni e configurazione a chiunque passi di lì.

I tre percorsi di aggiornamento

Hosting condiviso

Qui la patch la applica il provider, non il cliente. Dal pannello si sceglie il ramo (8.2, 8.3, 8.4), mentre la terza cifra dipende da quando il fornitore ricompila i propri pacchetti.

Cosa si può fare concretamente:

1. Verificare la micro-versione attuale tramite PHPinfo.
2. Se risulta inferiore a quella corretta, controllare se un altro ramo disponibile è già aggiornato e, nel caso, valutarne il passaggio.
3. Se nessun ramo è aggiornato, aprire un ticket chiedendo i tempi di applicazione della patch, citando le CVE.

Il cambio di ramo è reversibile: si torna indietro dallo stesso pannello, e i file e il database non vengono toccati. Va però testato, perché il codice applicativo potrebbe non essere compatibile con un ramo più recente.

VPS e server Linux

Qui l'intervento è a carico di chi gestisce la macchina.

apt update && apt list --upgradable
apt upgrade

Su Debian e Ubuntu con PHP dai repository ufficiali gli aggiornamenti di sicurezza arrivano in automatico, ma la verifica resta necessaria. Con pannelli di controllo come CloudPanel l'automatismo non copre i pacchetti del pannello: il comando va lanciato a mano.

Due accortezze prima di procedere: fare uno snapshot della macchina e, se php.ini o i pool FPM sono stati personalizzati, mantenere la propria configurazione quando il gestore pacchetti chiede se sovrascrivere.

Piattaforme gestite e container

Su servizi gestiti l'aggiornamento è lato fornitore: conviene verificare le comunicazioni ricevute e la versione effettivamente in esecuzione. Nelle immagini Docker occorre ricostruire il container con un'immagine base aggiornata: un semplice riavvio non cambia la versione di PHP al suo interno.

Il passaggio che quasi tutti saltano

Aggiornare il pacchetto non basta. Finché il processo PHP resta in esecuzione, continua a usare il binario vecchio caricato in memoria: la patch è sul disco ma non è attiva.

systemctl restart php8.3-fpm
systemctl restart nginx    # oppure apache2
php -v

Su Ubuntu lo strumento needrestart segnala i servizi che devono ripartire dopo un aggiornamento. Va assecondato, non rimandato.

La verifica finale è sempre la stessa: riaprire PHPinfo, o rilanciare php-fpm -v, e leggere la versione effettivamente in esecuzione. Finché quel numero non corrisponde a una delle versioni corrette, il server resta esposto.

Dopo l'aggiornamento

Le rotture da cambio di versione raramente si notano navigando la home. Si manifestano nei percorsi usati di rado, che sono spesso i più delicati.

• Generazione di PDF e stampe
• Invio delle email transazionali
• Upload di file e allegati
• Export di dati e report
• Accesso e funzioni dell'area amministrativa
• Procedure pianificate e cron

Vale la pena tenere d'occhio il log degli errori per qualche giorno. I messaggi di deprecazione non bloccano nulla, ma segnalano il codice che darà problemi al prossimo passaggio di ramo: meglio intervenire quando non c'è fretta.

Un'ultima considerazione, più strategica che tecnica. Queste due CVE sono un episodio; il rischio strutturale è restare su un ramo PHP fuori supporto, dove le patch non arrivano affatto. Il ramo 8.2 esce dal supporto di sicurezza il 31 dicembre 2026: restano poche settimane, e chi è fermo lì dovrebbe pianificare ora il passaggio a 8.3 o 8.4, con calma anziché sotto la pressione del prossimo allarme.