Note di sicurezza.
Il 21 ottobre il progetto PHP ha pubblicato un avviso di sicurezza critico con un'indicazione breve: aggiornate subito. Due falle di esecuzione di codice remoto, CVE-2026-109618 e CVE-2026-109619, hanno entrambe punteggio CVSS 9.2. La prima si attiva quando PHP esaurisce la memoria a metà della preparazione di una richiesta e in seguito ripulisce dati mai inizializzati del tutto. La seconda permette allo stato interno di una richiesta di sopravvivere alla sua memoria, così la richiesta successiva servita dallo stesso worker può ereditarlo. È colpita ogni configurazione PHP che serve traffico web — PHP-FPM, mod_php, php-cgi, FrankenPHP e LiteSpeed — con mod_php al rischio più alto.
Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. L'avviso è chiaro: non esiste un workaround completo, l'aggiornamento è l'unica opzione sicura.
Cosa abbiamo fatto prima della correzione. Le vulnerabilità sono state annunciate prima del rilascio, quindi nelle ore intermedie abbiamo ridotto l'esposizione dei server che gestiamo. Abbiamo disattivato il session upload progress, indicato nell'avviso come mitigazione parziale della seconda falla, e imposto lo strict session mode come ulteriore protezione. Entrambe le impostazioni sono state applicate a ogni runtime PHP su ciascun host e nei container applicativi, e le abbiamo verificate sui worker PHP che rispondono davvero alle richieste invece di fidarci dei file di configurazione.
Aggiornamento in giornata. All'uscita dei rilasci, i consueti pacchetti delle distribuzioni e le immagini container ufficiali non erano ancora aggiornati. Invece di aspettare, abbiamo compilato le versioni corrette dai sorgenti ufficiali di PHP verificati tramite checksum, mantenendo le estensioni e le impostazioni esistenti di ogni server, e ricompilato OPcache di conseguenza. Le applicazioni ancora su PHP 8.0 o 8.1, che non ricevono più rilasci pubblici, hanno ricevuto i backport di sicurezza ufficiali del progetto PHP invece di un salto di versione d'emergenza. Le applicazioni in container sono state spostate sull'immagine 8.4.27 corretta, con l'immagine di base fissata perché una build futura non possa tornare silenziosamente a una versione vulnerabile.
Verificare, non presumere. Un numero di versione da solo non dimostra nulla quando una build corretta e una non corretta possono riportare la stessa stringa. Per questo ogni pool web attivo è stato verificato per il motore e la build di OPcache che esegue davvero, e in seguito abbiamo controllato i negozi pubblici, le pagine di login e i siti demo. Tutti e ventitré i pool PHP attivi nei nostri ambienti e in quelli dei clienti hanno superato la verifica.
Cosa significa per il vostro negozio. Se usate Magento o un'altra applicazione PHP e non avete aggiornato dal 21 ottobre, consideratelo urgente. Verificate la versione di PHP che i vostri worker web eseguono davvero, non solo quella da riga di comando, e pianificate l'abbandono di PHP 8.0 e 8.1 se ne dipendete ancora. I backport di sicurezza fanno guadagnare tempo; non sono una soluzione a lungo termine.
Se volete un secondo parere sul vostro stack, o desiderate che gestiamo noi aggiornamenti come questo, contattateci — mantenere i negozi sicuri e operativi è una parte importante del nostro lavoro quotidiano.