1 Individui ogni PHP sul server

Molti server eseguono più di un PHP: il pacchetto di sistema, le versioni installate da un pannello di controllo (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), i container e le build da riga di comando usate da cron. Ognuno di quelli che servono richieste web deve essere aggiornato.

Esegua php -v, elenchi i processi php-fpm con ps aux | grep php-fpm e controlli il selettore PHP del Suo pannello.

2 Aggiorni a una versione corretta

Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. I pacchetti delle distribuzioni possono includere la correzione con un numero di versione precedente: cerchi CVE-2026-109618 e CVE-2026-109619 nel changelog.

PHP 8.1 e precedenti non ricevono rilasci dal progetto PHP. Per chi compila dai sorgenti sono stati pubblicati backport minimi per 7.4, 8.0 e 8.1, ma la soluzione duratura è passare a un ramo supportato.

Debian / Ubuntu (pacchetti della distribuzione)

Installi l’aggiornamento di sicurezza della Sua distribuzione e riavvii PHP. Il numero di versione può restare invariato; il changelog del pacchetto riporta la CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Applichi le errata del fornitore per lo stream del modulo PHP in uso, quindi riavvii.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / immagini php ufficiali

Scarichi o ricostruisca con il tag corretto e ricrei i container.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Usi lo strumento di aggiornamento del pannello per ogni versione di PHP installata (EA-PHP, handler PHP di Plesk, alt-php, CustomBuild), quindi riavvii PHP-FPM. I pannelli mantengono spesso installate versioni vecchie per singoli siti: aggiorni o rimuova anche quelle.

Hosting condiviso o gestito

Di solito non può aggiornare PHP autonomamente. Usi il messaggio nella scheda del risultato per chiedere al Suo provider la versione esatta, la data della patch e la conferma che i worker siano stati riavviati.

Windows / IIS

Scarichi la build corretta da windows.php.net, sostituisca la directory di PHP e ricicli i pool di applicazioni di IIS.

3 Riavvii ogni processo PHP

Installare un pacchetto non modifica il codice già in esecuzione. Riavvii PHP-FPM, Apache (per mod_php), LiteSpeed, FrankenPHP, i worker delle code e i supervisor. Per i container, ricostruisca o scarichi la nuova immagine: riavviare la stessa immagine non installa alcuna patch.

4 Verifichi

Esegua php -v per ogni binario e confermi che i processi in esecuzione usino la nuova build (ad esempio ls -l /proc/$(pgrep -o php-fpm)/exe non deve riportare «deleted»). Poi esegua di nuovo questa verifica.

5 Se non può aggiornare oggi

Applichi le mitigazioni parziali indicate sotto e limiti chi può raggiungere il sito finché non potrà aggiornare. Riducono il rischio, ma non lo eliminano.

6 Cerchi segni di compromissione e cambi i segreti

Se un sito vulnerabile era raggiungibile da Internet, esamini l’attività a partire dal 20 ottobre 2026: crash dei worker PHP (SIGSEGV) nel log degli errori di PHP-FPM o di Apache, file PHP nuovi o modificati nella web root, nuovi cron job, nuovi account amministratore e connessioni in uscita inattese.

Poiché CVE-2026-109619 può esporre la memoria del processo PHP senza eseguire alcun codice, un file system pulito non prova che non sia trapelato nulla. Cambi le password dei database, le chiavi API, le credenziali di pagamento e di posta, e invalidi le sessioni utente dei siti che sono stati esposti.

7 Dopo l’aggiornamento

La correzione introduce un nuovo limite rigido di memoria: un processo che lo raggiunge viene terminato immediatamente e gli shutdown handler non vengono eseguiti. Verifichi come si comporta la Sua applicazione sotto pressione di memoria, riveda memory_limit insieme a post_max_size e max_input_nesting_level, e annulli qualsiasi memory_limit = -1 temporaneo impostato prima della patch. Nascondere la versione con expose_php = Off è un irrobustimento facoltativo, non una correzione.

Mitigazioni parziali (da php.net e dai bollettini)

Restringono soltanto i percorsi di attacco noti. php.net afferma che l’aggiornamento è l’unica scelta sicura.

; php.ini / FPM pool (php_admin_value) — riavvii poi tutti i worker
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M se servono gli upload
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Imposti questi valori in php.ini, nel pool PHP-FPM (php_admin_value) o nella configurazione del server, non con ini_set() o .user.ini, e riavvii i worker. Ulteriori misure indicate dai bollettini e dal team di ricerca:

memory_limit = -1 blocca alcuni percorsi che si basano sul limite di memoria di PHP, ma affida l’esaurimento della memoria al sistema operativo: lo usi solo insieme a un limite cgroup v2 memory.max. Non usi RLIMIT_AS o RLIMIT_DATA: possono attivare gli stessi percorsi vulnerabili.
Riduca max_input_nesting_level quanto più i Suoi moduli lo consentono.
Riduca pm.max_requests di PHP-FPM in modo che i worker vengano riciclati più spesso (con un costo in prestazioni).
Limiti sulla dimensione delle richieste, sul numero di campi e sull’annidamento a livello di server web o proxy; rimuova le impostazioni INI per richiesta non valide o deprecate.
Le policy SELinux o AppArmor possono limitare ciò che un worker compromesso è in grado di eseguire: riducono l’impatto, ma non impediscono la divulgazione della memoria.

Riferimenti

Fonte: bollettino di sicurezza di php.net, 21 ottobre 2026. Ultima verifica: 2026-10-23.