PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 chiudono due falle RCE critiche: aggiorna adesso

Il 21 ottobre PHP ha pubblicato 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Correggono due vulnerabilità critiche di esecuzione remota di codice senza autenticazione, entrambe con CVSS v4.0 9.2.

Perché ti riguarda: è a rischio ogni installazione PHP che serve richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed. Il rischio più alto è con mod_php. Lì il team ha dimostrato un exploit in cui una richiesta non autenticata fa partire l’attacco prima che giri una sola riga del tuo codice.

Questo è il primo numero di TuttoPHP e avremmo preferito aprire con una feature nuova. Ma sono passate due settimane: se non hai ancora aggiornato, la notizia del giorno è questa.

Le due falle, in parole semplici

CVE-2026-109618, “RCE via OOM corruption”. Se PHP esaurisce la memoria nel momento sbagliato, si ferma mentre i dati interni della richiesta sono pronti solo a metà. Poi la pulizia di fine richiesta tratta quei dati come validi.

CVE-2026-109619, “RCE via stale global state”. Un pezzo di stato interno di una richiesta sopravvive anche dopo che la sua memoria è stata liberata. La richiesta successiva sullo stesso worker può usarlo prima che venga azzerato. È un use-after-free, cioè l’uso di memoria già restituita. Tra le funzioni che possono leggere quello stato c’è l’upload progress delle sessioni, che è attivo di default. Su PHP 8.5 il caso più solido coinvolge fatal_error_backtraces.

A cosa aggiornare

Aggiorna a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Se usi i pacchetti di una distribuzione Linux o di un vendor LTS, controlla i loro aggiornamenti: hanno ricevuto le patch in anticipo. PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto. In quel caso chiedi al tuo vendor o passa a una versione supportata.

Ramo	Versione corretta	Nota
PHP 8.5	8.5.12	se non puoi aggiornare, spegni anche fatal_error_backtraces
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35	fine vita il 31 dicembre 2026
PHP 8.1 e precedenti	nessuna dal progetto	vendor LTS o backport minimi (7.4, 8.0, 8.1)

Se oggi proprio non puoi

Le misure indicate dal team riducono il rischio su percorsi specifici, ma non rendono sicura l’installazione. Solo l’aggiornamento risolve.

• CVE-2026-109618: imposta memory_limit=-1 dove l’applicazione non può sovrascriverlo (per esempio con php_admin_value). Come argine usa un limite di container o cgroup, non RLIMIT_AS o RLIMIT_DATA. Tieni basso post_max_size (8M senza upload, 32M con upload) e upload_max_filesize sotto quel valore. Metti limiti sulle richieste anche nel web server o nel proxy.
• CVE-2026-109619: imposta session.upload_progress.enabled=0 in php.ini, nel pool FPM o nella configurazione del server, non con ini_set() né con .user.ini. Su PHP 8.5 aggiungi fatal_error_backtraces=0. Poi riavvia tutti i worker.

Sono toppe, non cure. E il piano “aggiorno al prossimo sprint” è scaduto da due settimane.

«There are no complete mitigations, updating is the only safe choice.» Non esistono mitigazioni complete: aggiornare è l’unica scelta sicura. — Annuncio di PHP 8.2.35, php.net, 21 ottobre 2026

PHP 8.2, conto alla rovescia

PHP 8.2 arriva a fine vita il 31 dicembre 2026. Dopo quella data non riceverà più correzioni di sicurezza. Se sei su 8.2, aggiorna oggi alla 8.2.35 e pianifica il passaggio a una versione supportata. È un buon proposito per il 2027, da mettere in pratica nel 2026.

Seguito: build Windows con Brotli 1.2.1 e un avviso sulle sessioni.