Michael JohnsonIl 21 ottobre 2026 PHP ha annunciato due vulnerabilità critiche che potrebbero consentire l’esecuzione di codice da remoto senza autenticazione. Lo stesso giorno il progetto ha rilasciato correzioni per i rami 8.5, 8.4, 8.3 e 8.2, raccomandando agli utenti di aggiornare senza indugio. Potrebbero essere vulnerabili le installazioni che gestiscono richieste web, tra cui PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed, secondo quanto comunicato da PHP.
Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. I rilasci risolvono CVE-2026-109618, legata alla corruzione dello stato in caso di esaurimento della memoria, e CVE-2026-109619, un errore per cui lo stato di una richiesta poteva persistere nel processo worker ed essere riutilizzato durante l’elaborazione di quella successiva. Sono interessate le versioni precedenti a quelle elencate; per PHP 8.1 e i rami precedenti il progetto non rilascia più aggiornamenti propri, quindi gli amministratori dovrebbero verificare la disponibilità di correzioni presso il fornitore della distribuzione o del supporto LTS.
Due errori nel ciclo di vita delle richieste web
Nel caso di CVE-2026-109618, l’elaborazione di una richiesta può interrompersi per esaurimento della memoria prima che i dati interni siano stati inizializzati completamente. Al termine, PHP può quindi accedere a uno stato non valido. Nell’advisory gli sviluppatori descrivono, tra gli altri, scenari che coinvolgono richieste multipart e il raggiungimento del limite di memoria. Per Apache mod_php è stato confermato uno scenario in cui il problema si verifica prima ancora dell’avvio del codice dell’applicazione; PHP segnala inoltre che il rischio è maggiore per questa configurazione.
CVE-2026-109619 riguarda lo stato conservato dal processo worker tra una richiesta e l’altra. Se un’operazione termina con un errore prima che i dati vengano ripuliti, la memoria della richiesta precedente viene liberata, ma il riferimento a essa rimane. La richiesta successiva gestita dallo stesso processo può accedere allo stato obsoleto prima della normale inizializzazione. Nell’advisory del progetto, PHP descrive percorsi confermati tramite operazioni diagnostiche precoci e gestione dell’avanzamento del caricamento dei file; l’applicabilità di ciascun percorso dipende dalla configurazione, dall’applicazione e dalle estensioni utilizzate.
Entrambe le vulnerabilità hanno ottenuto un punteggio CVSS 4.0 di 9,2. Secondo PHP, l’impatto confermato include l’esecuzione di codice con i privilegi del worker web. Per la vulnerabilità legata all’esaurimento della memoria, l’advisory conferma uno scenario HTTP completo contro mod_php; per PHP-FPM, invece, la fonte descrive l’analisi del codice e le condizioni di vulnerabilità. È quindi importante distinguere questi dati nella valutazione di una distribuzione specifica.
Cosa dovrebbero verificare gli amministratori
Per prima cosa, individuate le versioni di PHP che gestiscono effettivamente il traffico web: sullo stesso server possono essere presenti build separate per CLI, FPM e Apache, mentre container e nodi di un cluster vengono aggiornati indipendentemente. Per ogni ramo supportato installate la versione corretta oppure un pacchetto del fornitore con la patch confermata. Quindi riavviate tutti i worker PHP e verificate la loro versione dopo il riavvio: sostituire i file senza riavviare lascia in funzione i processi meno recenti.
Per PHP 8.1 e versioni precedenti, verificate lo stato del supporto e la disponibilità di una correzione retroportata da parte della distribuzione o del fornitore LTS. Se non è disponibile un pacchetto del genere, pianificate il passaggio a un ramo supportato. PHP afferma che i fornitori delle distribuzioni Linux hanno ricevuto le patch in anticipo; il numero di versione dei loro pacchetti può differire da quello del rilascio ufficiale PHP, quindi controllate che la correzione sia effettivamente inclusa.
Le impostazioni temporanee e il filtraggio delle richieste possono ridurre alcuni vettori d’attacco, ma il progetto indica l’aggiornamento come l’unico metodo completo per risolvere entrambi i problemi. Per i team, la priorità pratica è inventariare tutti i worker web, installare il pacchetto corretto, riavviare i processi e verificare il risultato su ogni nodo. Questo è ciò che corregge le vulnerabilità confermate, anziché affidarsi soltanto alla configurazione del server web.