Release d'emergenza di PHP: due RCE critiche corrette in 8.2.35-8.5.12
PHP ha rilasciato un aggiornamento di sicurezza fuori programma che corregge due vulnerabilità critiche use-after-free nel cuore del linguaggio, entrambe sfruttabili per l'esecuzione remota di codice senza autenticazione e con punteggio 9,2 sulla scala CVSS v4.0. Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, pubblicate oggi e elencate nell'archivio dei rilasci del progetto. Backport minimi del codice sorgente per i rami 7.4, 8.0 e 8.1, senza manutenzione da tempo, esistono solo su GitHub - nessun binario ufficiale è previsto per essi.
Il rilascio è stato preceduto da una finestra di divulgazione caotica. Il 20 ottobre il progetto ha annunciato una pubblicazione d'emergenza per le 14:00 UTC di oggi senza indicare versioni o funzioni interessate; come documentato da OX Security, screenshot di un tool di exploit hanno circolato prima che le patch fossero disponibili, e il progetto stesso ha avvertito che il codice proof-of-concept in circolazione in quella finestra è spesso malware travestito. Ora che patch e advisory sono pubblici, il quadro tecnico è più chiaro di quanto il ciclo di teaser suggerisse.Un percorso da esaurimento della memoria all'esecuzione di codice
CVE-2026-109618, registrata come GHSA-w8hw-w9fx-j79w, sfrutta il modo in cui PHP gestisce l'esaurimento della memoria. Quando un'allocazione fallisce, il motore srotola la richiesta con un longjmp() - e se accade mentre la memoria della richiesta è solo parzialmente inizializzata, la fase di chiusura legge o poi ramifica su memoria in stato non valido. L'advisory descrive una famiglia di trucchi da pressione di allocazione che rendono tutto raggiungibile da una normale richiesta HTTP: corpi multipart senza un content-length utilizzabile che scivolano oltre post_max_size, parti con migliaia di header la cui rappresentazione in memoria sminchia la dimensione a filo, e controlli file vuoti che allocano array di metadati senza contare mai contro max_file_uploads. Il SAPI mod_php di Apache è confermato sfruttabile: i ricercatori hanno validato l'esecuzione remota di codice non autenticata come account del worker web via HTTP semplice su configurazioni prefork predefinite - con complessità d'attacco alta e forse diversi tentativi. PHP-FPM è considerato suscettibile attraverso percorsi di allocazione specifici dell'applicazione, con FrankenPHP e LiteSpeed probabilmente nella stessa barca. La patch sostituisce il longjmp grezzo con una trappola morbida per l'out-of-memory al prossimo safe point della VM, più un fallimento duro che uccide il worker all'istante.Stato stantio nei processi worker
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) è la sorella silenziosa: i processi worker portano stato globale - gestori di errori, dati di sessione, contabilità di oggetti ed estensioni - che può finire per puntare alla memoria di una singola richiesta. Se un errore fatale, un aborto per mancanza di memoria o una diagnostica tardiva scrive tale stato e nulla lo riporta a zero prima che la memoria della richiesta venga liberata, i globali del worker pendono nel vuoto. Ciò che li tocca prima dell'inizializzazione di una nuova richiesta legge memoria liberata. Due percorsi produttivi sono confermati: i backtrace di errore fatale introdotti in PHP 8.5 sotto mod_php e il meccanismo session upload progress sotto mod_php e FPM. Produttore e consumatore devono atterrare sullo stesso processo worker, il che rende i pool FPM con molti worker più difficili - ma non impossibili - da colpire.Un layout di heap strategicamente confezionato può produrre esecuzione remota di codice (RCE) completa. - Advisory di sicurezza PHP, GHSA-6wmf-4rv5-p3rp
Cosa devono fare gli amministratori ora
Aggiornare è l'unica mitigazione completa, e non è un patch-and-forget: entrambi gli advisory sottolineano di riavviare tutti i worker PHP dopo l'aggiornamento, perché lo stato stantio può sopravvivere in processi di lunga vita. I rami supportati hanno binari di rilascio; i siti ancorati a rami EOL devono applicarsi i backport del sorgente da soli.- Aggiornare a 8.2.35, 8.3.36, 8.4.27 o 8.5.12 (o applicare i backport GitHub per 7.4/8.0/8.1), poi riavviare ogni processo worker.
- Se aggiornare oggi non è possibile: impostare session.upload_progress.enabled=0 e, su PHP 8.5, fatal_error_backtraces=0, e riavviare i worker.
- Per la falla OOM, imporre memory_limit=-1 a livello centrale e verificare che nessun override di pool o .htaccess ripristini un limite finito.
- Mantenere un post_max_size conservativo, bloccare al frontend le richieste multipart se l'applicazione non le usa, e limitare variabili di input, header e upload.
- Usare limiti di memoria container/cgroup invece di RLIMIT_AS o RLIMIT_DATA - l'advisory avverte esplicitamente che i meccanismi RLIMIT spingono i fallimenti di allocazione sul percorso vulnerabile.
- Opzionalmente, limitare il riciclo dei worker con pm.max_requests per accorciare la finestra di trascinamento di stato.