L'aggiornamento dei server PHP è diventato una priorità per le aziende che gestiscono siti web, applicazioni gestionali, API e servizi online esposti su Internet. Nell'ottobre 2026 sono state individuate due vulnerabilità critiche nel motore PHP, identificate come CVE-2026-109618 e CVE-2026-109619, che possono consentire l'esecuzione di codice da remoto senza autenticazione. Le falle, associate al nome PHP2Shell, interessano diverse modalità di esecuzione di PHP e possono mettere a rischio anche applicazioni che non presentano direttamente una vulnerabilità nel proprio codice. Il problema riguarda quindi non soltanto gli sviluppatori, ma anche gli amministratori di sistema, i responsabili IT e i fornitori di hosting, chiamati a verificare le versioni installate e applicare tempestivamente gli aggiornamenti di sicurezza. 

Perché aggiornare immediatamente PHP

Le vulnerabilità recentemente corrette coinvolgono meccanismi interni del runtime PHP. La CVE-2026-109618 riguarda una condizione di corruzione della memoria durante la gestione degli errori di esaurimento della memoria, mentre la CVE-2026-109619 interessa la gestione di uno stato interno che può rimanere utilizzabile dopo la liberazione della memoria associata. In determinate condizioni, queste anomalie possono essere sfruttate per eseguire codice arbitrario sul server, senza che l'attaccante debba necessariamente disporre di un account applicativo valido.

Il rischio è particolarmente rilevante per le installazioni che elaborano richieste HTTP provenienti da Internet. Il problema non è limitato ad Apache con il modulo PHP integrato: può interessare anche configurazioni basate su PHP-FPM, PHP-CGI, FrankenPHP e LiteSpeed. Di conseguenza, aggiornare soltanto il codice del sito o installare una nuova versione del CMS non è sufficiente se il runtime PHP sottostante continua a utilizzare componenti vulnerabili.

Il team PHP ha pubblicato le versioni correttive il 21 ottobre 2026 e raccomanda di applicarle tempestivamente. Il CERT-EU e le autorità europee per la sicurezza informatica hanno invitato le organizzazioni a identificare le applicazioni coinvolte, dare priorità ai sistemi esposti su Internet e coordinare gli interventi con i fornitori di hosting e dei servizi gestiti.

Quali versioni PHP installare

Le versioni correttive pubblicate per le principali release supportate sono PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 e PHP 8.2.35. La versione da installare dipende dal ramo PHP già utilizzato e dalla compatibilità dell'applicazione: non è necessario passare automaticamente a una release principale più recente per applicare la correzione, purché venga installato un pacchetto aggiornato e supportato dal proprio fornitore.

Prima di intervenire, è importante verificare anche il ciclo di vita della versione. PHP 8.2 riceverà aggiornamenti di sicurezza dal progetto ufficiale fino al 31 dicembre 2026; chi utilizza questo ramo dovrebbe quindi pianificare anche una migrazione verso una versione con un periodo di supporto più lungo. Le versioni PHP 8.1 e precedenti non ricevono più aggiornamenti di sicurezza dal progetto principale, anche se alcuni fornitori possono distribuire correzioni retroportate nei propri pacchetti. In questi casi è necessario verificare esplicitamente la copertura del supporto e non basarsi esclusivamente sul numero di versione visualizzato. 

È inoltre importante considerare gli aggiornamenti delle dipendenze incluse nei pacchetti. Il 26 ottobre 2026 il progetto PHP ha annunciato build Windows aggiornate con suffisso -1, contenenti Brotli 1.2.1 per correggere un'ulteriore vulnerabilità nella decompressione dei dati. Per gli ambienti Windows, quindi, occorre verificare anche la disponibilità della build aggiornata appropriata, soprattutto quando le applicazioni utilizzano cURL con la decompressione automatica delle risposte HTTP abilitata.

Verificare la versione PHP effettivamente utilizzata dal server

La prima fase dell'intervento consiste nell'inventario delle installazioni PHP presenti sull'infrastruttura. Su un server Linux, il comando php -v mostra la versione del runtime disponibile nella shell, ma non garantisce che il sito web utilizzi lo stesso interprete. Un server può infatti eseguire una versione PHP per i processi CLI, una differente per PHP-FPM e un'altra ancora attraverso Apache o un pannello di hosting.

Per controllare la versione CLI è possibile utilizzare:

php -v
php --ini
php -m

Il primo comando mostra la versione installata, il secondo individua i file di configurazione caricati e il terzo elenca le estensioni disponibili. Queste verifiche sono utili per identificare la configurazione locale, ma devono essere integrate con il controllo del servizio che gestisce effettivamente le richieste web.

Negli ambienti che utilizzano PHP-FPM, è opportuno verificare lo stato dei servizi e dei pool attivi, individuando il socket o la porta verso cui Apache o Nginx inoltrano le richieste. Nei sistemi basati su Apache con mod_php, invece, occorre identificare il modulo PHP caricato dal processo web. Nei server con più siti, versioni PHP differenti possono essere associate a VirtualHost diversi, perciò l'inventario deve essere effettuato a livello di applicazione e non soltanto di macchina.

Per evitare di esporre informazioni sensibili, è preferibile eseguire le verifiche tramite accesso amministrativo o strumenti interni di gestione. Una pagina pubblica contenente phpinfo() non dovrebbe essere lasciata accessibile su un server di produzione, perché può rivelare percorsi interni, moduli caricati, variabili d'ambiente e dettagli della configurazione.

Aggiornare PHP su Linux senza compromettere i servizi

La procedura di aggiornamento dipende dalla distribuzione Linux, dai repository utilizzati e dal metodo con cui PHP è stato installato. Sui sistemi Debian e Ubuntu, per esempio, l'amministratore può aggiornare l'indice dei pacchetti e verificare gli aggiornamenti disponibili attraverso APT:

sudo apt update
apt list --upgradable

Dopo aver identificato i pacchetti PHP interessati, l'aggiornamento deve essere eseguito utilizzando i repository ufficiali della distribuzione o quelli del fornitore che gestisce la versione installata. I nomi dei pacchetti possono includere il runtime, PHP-FPM, il modulo Apache e le singole estensioni, come quelle per MySQL, XML, cURL e l'elaborazione delle immagini. È necessario verificare che tutti i componenti utilizzati dall'applicazione siano aggiornati e coerenti con il ramo PHP previsto.

Nei sistemi basati su distribuzioni della famiglia Red Hat, Rocky Linux o AlmaLinux, la gestione avviene normalmente tramite DNF e i repository configurati sul server. Anche in questo caso, la disponibilità della versione correttiva dipende dai repository e dai flussi di pacchetti attivi. Alcuni fornitori distribuiscono le correzioni retroportate mantenendo il numero di versione principale del pacchetto, mentre altri richiedono l'aggiornamento a una revisione specifica. Per questo motivo è importante consultare gli avvisi di sicurezza della distribuzione prima di sostituire manualmente binari o repository.

Se PHP è stato compilato manualmente dai sorgenti, l'aggiornamento richiede una procedura differente, che comprende il recupero dei sorgenti corretti, la verifica delle opzioni di compilazione, la ricostruzione dei moduli e la sostituzione controllata dei componenti installati. Nei sistemi containerizzati, invece, è necessario aggiornare l'immagine di base PHP e ricostruire il container, verificando che l'immagine corretta venga effettivamente distribuita negli ambienti di produzione. La semplice modifica del Dockerfile non aggiorna automaticamente i container già in esecuzione.

Aggiornare PHP-FPM, Apache e i processi in esecuzione

L'installazione del pacchetto corretto non conclude necessariamente l'intervento. I processi che hanno già caricato una versione precedente delle librerie possono continuare a utilizzare il codice presente in memoria fino al riavvio o al ricaricamento previsto dalla configurazione. È quindi necessario verificare quali servizi devono essere riavviati per applicare effettivamente la correzione.

Negli ambienti PHP-FPM, dopo l'aggiornamento dei pacchetti occorre verificare lo stato del servizio e, quando necessario, riavviare l'istanza interessata. Un controllo preliminare può essere eseguito con:

systemctl status php8.4-fpm

Il nome del servizio è soltanto un esempio: deve essere sostituito con quello effettivamente presente sul server. Dopo l'intervento, è opportuno verificare i log del servizio, controllare che tutti i worker siano stati ricreati e accertarsi che il web server continui a comunicare correttamente con il socket PHP-FPM.

Per Apache con mod_php, l'aggiornamento del modulo richiede che i processi Apache carichino la versione corretta. Per questo motivo può essere necessario un reload o un riavvio controllato, secondo la procedura supportata dalla distribuzione. Nei sistemi che utilizzano Nginx come reverse proxy verso PHP-FPM, invece, bisogna verificare sia il runtime PHP sia il servizio web, senza riavviare componenti non interessati se non necessario.

Le operazioni devono essere pianificate considerando le applicazioni attive, le connessioni persistenti e gli eventuali job in background. Su infrastrutture ad alta disponibilità è possibile aggiornare i nodi progressivamente, verificando ciascuna istanza prima di procedere con la successiva. Questa strategia riduce il rischio di interruzioni estese, purché il bilanciamento del traffico, la compatibilità tra i nodi e le procedure di rollback siano stati verificati in anticipo.

Verificare la compatibilità delle applicazioni dopo l'aggiornamento

Un aggiornamento di sicurezza deve essere seguito da test funzionali, perché un runtime aggiornato può interagire con estensioni, librerie e applicazioni che presentano vincoli specifici di compatibilità. Prima di intervenire in produzione, è opportuno eseguire un backup verificato della configurazione e dei dati necessari al ripristino, documentare la versione precedente e predisporre un ambiente di test quando l'architettura lo consente.

Dopo l'aggiornamento è necessario controllare l'accesso al sito, l'autenticazione, la gestione delle sessioni, le operazioni sul database, l'invio delle e-mail, l'elaborazione dei file caricati e gli endpoint API. Per un gestionale aziendale è importante verificare anche le procedure di inserimento e modifica dei dati, la generazione dei documenti, i processi schedulati e gli script CLI. Un sito che restituisce la homepage senza errori non è necessariamente completamente funzionante.

I log di Apache o Nginx, quelli di PHP-FPM e i log applicativi devono essere analizzati per individuare errori di avvio, moduli mancanti, incompatibilità o timeout. La direttiva display_errors dovrebbe rimanere disabilitata in produzione, mentre la registrazione degli errori deve essere configurata in modo da consentire la diagnosi senza esporre dettagli tecnici agli utenti. È inoltre opportuno verificare le metriche di CPU, memoria, latenza e numero di worker, perché un problema di configurazione può manifestarsi anche come degrado prestazionale.

Misure temporanee quando l'aggiornamento non è immediatamente possibile

L'aggiornamento del runtime è la misura principale per correggere le vulnerabilità PHP2Shell. Se un server non può essere aggiornato immediatamente a causa di vincoli di compatibilità, indisponibilità dei pacchetti o dipendenze applicative, è necessario ridurre temporaneamente l'esposizione e pianificare una correzione urgente. Le mitigazioni non devono essere considerate equivalenti a una patch completa.

Le indicazioni pubblicate dal progetto PHP e dal CERT-EU comprendono, a seconda della vulnerabilità e della configurazione, la disattivazione di session.upload_progress.enabled e specifiche restrizioni sulla gestione delle richieste. La modifica deve essere applicata a livello di configurazione effettivamente utilizzato dal runtime e deve essere seguita dal riavvio dei worker interessati. Una chiamata a ini_set() eseguita all'interno dell'applicazione non è sufficiente per sostituire una configurazione che deve intervenire prima dell'elaborazione della richiesta.

Altre misure possono includere limiti sulla dimensione delle richieste HTTP, controlli sul numero di parti multipart, restrizioni sulle risorse accessibili e isolamento dei servizi esposti. Tuttavia, parametri come memory_limit e i limiti di caricamento devono essere valutati rispetto al comportamento applicativo, perché modifiche non corrette possono causare problemi di disponibilità o non bloccare tutte le possibili modalità di sfruttamento. Le misure temporanee devono quindi essere applicate sulla base dell'avviso tecnico ufficiale e non attraverso modifiche improvvisate alla configurazione.

Il CERT-EU ha inoltre segnalato il 23 ottobre 2026 una vulnerabilità aggiuntiva, CVE-2026-115560, legata a una combinazione particolare di configurazione delle sessioni e comportamento applicativo. L'indicazione pubblicata dal progetto PHP è di impostare session.upload_progress.enabled=0 fino alla disponibilità della correzione prevista nel normale ciclo di rilascio, qualora la funzionalità non sia indispensabile. È quindi importante consultare gli avvisi ufficiali aggiornati prima di considerare concluso l'intervento. 

Verificare possibili compromissioni e rafforzare la sicurezza del server

Quando una vulnerabilità consente l'esecuzione di codice da remoto senza autenticazione, l'aggiornamento del software non dimostra automaticamente che il sistema non sia già stato compromesso. Prima di chiudere l'intervento, è opportuno verificare i log di accesso web, gli error log, gli eventi di autenticazione e le attività anomale registrate nel periodo in cui il server era esposto. La verifica deve considerare anche i processi in esecuzione, le modifiche recenti ai file dell'applicazione, i nuovi account, i task pianificati e le connessioni in uscita non previste.

La ricerca deve essere proporzionata alla criticità del sistema e può richiedere strumenti di rilevamento degli endpoint, analisi forense o il coinvolgimento di specialisti di sicurezza. Se emergono indicatori di compromissione, non è sufficiente reinstallare PHP: occorre contenere l'incidente, preservare le evidenze disponibili, valutare l'integrità del sistema e ruotare le credenziali potenzialmente esposte. In presenza di una compromissione confermata, il ripristino da un ambiente noto e verificato può essere più affidabile della semplice rimozione dei file sospetti.

Una volta completata la correzione, è opportuno mantenere aggiornati il sistema operativo, il web server, le estensioni PHP, le librerie di terze parti e le applicazioni. La segmentazione della rete, il principio del privilegio minimo, la protezione delle credenziali e il monitoraggio centralizzato dei log contribuiscono a limitare le conseguenze di eventuali vulnerabilità future. Il processo di patch management dovrebbe inoltre prevedere un inventario aggiornato dei runtime, la verifica periodica delle versioni e un sistema di priorità basato sull'esposizione e sulla gravità delle vulnerabilità.

Aggiornamento dei server PHP: un'attività essenziale per la continuità operativa

Le vulnerabilità emerse nell'ottobre 2026 dimostrano quanto sia importante gestire gli aggiornamenti del runtime PHP come parte integrante della sicurezza infrastrutturale. Identificare le versioni installate, verificare i pacchetti corretti, aggiornare tutti i processi che gestiscono richieste web e testare le applicazioni consente di ridurre il rischio senza trascurare la continuità dei servizi aziendali.

ALLIT può affiancare le aziende nella gestione dei server, nell'aggiornamento dei componenti software, nel controllo delle configurazioni PHP e nella definizione di procedure di manutenzione e sicurezza. Un approccio strutturato consente di individuare tempestivamente i sistemi esposti, pianificare gli interventi, verificare l'efficacia delle correzioni e migliorare la resilienza delle applicazioni web e dei gestionali aziendali.