Vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619

Sono state rese pubbliche le vulnerabilità CVE-2026-109618 e CVE-2026-109619, che consentono l’esecuzione di codice da remoto (RCE) senza autenticazione durante la gestione degli arresti anomali e dello stato delle richieste nel motore core di PHP. Il problema deriva da difetti di corruzione della memoria e Use-After-Free nel motore di esecuzione PHP, non da applicazioni web come WordPress o GnuBoard. Per risolverlo, è necessario eseguire subito l’aggiornamento a versioni con le patch di sicurezza, come PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, quindi riavviare i processi worker.

Una vulnerabilità del motore PHP che non si risolve aggiornando solo l’applicazione web

Il 21 ottobre 2026 (UTC), il team di sviluppo PHP ha annunciato due vulnerabilità di sicurezza valutate 9,2 secondo CVSS v4.0. Un attaccante può eseguire codice arbitrario sul server inviando una richiesta HTTP appositamente manipolata, senza effettuare alcun accesso.

Il difetto si trova nel livello core di PHP, che analizza le richieste web e libera la memoria. Pertanto, anche mantenendo aggiornati CMS e plugin del sito, un runtime PHP obsoleto resta esposto agli attacchi. In particolare, negli ambienti Apache con la configurazione predefinita mod_php, è stato verificato che l’esecuzione del codice può avvenire con una sola richiesta, prima ancora dell’esecuzione del codice dell’applicazione web.

Se l’attacco riesce, l’intruso ottiene i privilegi dell’account di sistema con cui viene eseguito il processo PHP. Ciò non comporta necessariamente l’acquisizione immediata dei privilegi root, ma consente di creare una webshell nella directory principale del sito o di leggere le credenziali di accesso al database presenti nei file di configurazione, esfiltrando o modificando dati interni. Se più siti web sullo stesso server condividono lo stesso account di esecuzione PHP-FPM, la compromissione di un sito può inoltre propagarsi agli altri siti del server.

Corruzione della memoria e Use-After-Free durante gli arresti anomali

Entrambe le vulnerabilità si verificano perché la memoria non viene ripulita correttamente quando si presenta una situazione anomala durante l’elaborazione di una richiesta. Le condizioni di attivazione e il funzionamento interno sono diversi.

CVE-2026-109618 (corruzione della memoria durante la gestione del superamento del limite): quando PHP supera il limite di memoria consentito (Out-Of-Memory) durante l’elaborazione di una richiesta, chiama longjmp() per interrompere immediatamente l’esecuzione. Se l’elaborazione si arresta mentre le strutture dati interne della richiesta non sono ancora state inizializzate completamente, lo stato incompleto può rimanere senza essere ripristinato. La routine di pulizia (cleanup) eseguita successivamente considera questa memoria non inizializzata come dati validi e vi accede, causando corruzione della memoria ed esecuzione di codice da remoto.

CVE-2026-109619 (Use-After-Free dovuto al riferimento alla memoria liberata dalla richiesta precedente): alcuni stati globali interni di PHP o stati di gestione degli errori puntano temporaneamente a un’area di memoria posseduta da una singola richiesta. Quando una richiesta termina in modo anomalo a causa di un errore fatale (fatal error) o della memoria insufficiente, la memoria effettiva può essere liberata, mentre il riferimento del puntatore interno che la indica rimane non inizializzato. Negli ambienti che riutilizzano i processi worker, come PHP-FPM o mod_php, lo stesso worker può ricevere ed elaborare la richiesta HTTP successiva, rileggendo un’area di memoria già liberata (Use-After-Free) e creando un percorso per l’esecuzione del codice.

L’avviso di sicurezza ufficiale indica come percorsi confermati per CVE-2026-109619 la funzionalità di avanzamento del caricamento delle sessioni (session.upload_progress), gli avvisi di configurazione visualizzati prima dell’inizializzazione della richiesta e i backtrace degli errori fatali di PHP 8.5 (fatal_error_backtraces). Tuttavia, specifica che anche bloccando questi percorsi restano possibili altre varianti.

Stato delle patch per versione PHP e ambito in base all’ambiente di esecuzione

Sono interessate le versioni PHP 8.2–8.5 precedenti alle versioni corrette; le versioni 8.1 e precedenti, ormai fuori supporto, non rientrano negli aggiornamenti ufficiali del progetto PHP. Sono interessate tutte le installazioni che gestiscono richieste web, tra cui PHP-FPM, mod_php, php-cgi, FrankenPHP e LiteSpeed; l’avviso ufficiale considera mod_php il caso con il rischio maggiore. Red Hat classifica PHP-FPM come potenzialmente interessato in modo condizionale attraverso percorsi a livello applicativo.

Ambiente verificato: al 22 ottobre 2026, in un ambiente server Linux che utilizza il repository Remi, è stato verificato l’aggiornamento di PHP 8.4.26 a 8.4.27, insieme al riavvio dei worker PHP-FPM e all’applicazione alle richieste web.

Procedura per aggiornare i pacchetti e applicare le impostazioni di mitigazione PHP-FPM

Il team di sviluppo PHP indica che le sole modifiche alla configurazione non possono bloccare tutti i percorsi di attacco e che l’aggiornamento a una versione con patch è l’unica soluzione completa. Dopo l’aggiornamento, è possibile applicare anche misure di mitigazione che disabilitano le funzionalità non necessarie per ridurre la superficie d’attacco.

1. Installare gli aggiornamenti dei pacchetti PHP
   Aggiornare i pacchetti tramite il gestore dei pacchetti del sistema operativo alla versione corretta del ramo PHP in uso, ad esempio 8.4.27 per il ramo 8.4. Dopo l’installazione, verificare prima la versione CLI dal terminale.

   php -v

   L’esecuzione del comando visualizza una versione aggiornata e la data di compilazione, ad esempio PHP 8.4.27 (cli). Tuttavia, la versione CLI può differire da quella del processo PHP utilizzato dal server web; è quindi necessario completare anche il passaggio successivo.

2. Modificare la configurazione PHP-FPM per ridurre la superficie d’attacco (opzionale e temporaneo)
   Se è difficile applicare immediatamente l’aggiornamento o si desidera aggiungere un ulteriore livello di difesa, eseguire un backup di php.ini o del file di configurazione del pool PHP-FPM, ad esempio /etc/php-fpm.d/www.conf, quindi modificare le voci seguenti.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   Disabilitando session.upload_progress.enabled è possibile bloccare il percorso di attacco basato sulle sessioni già confermato. Riducendo post_max_size — ad esempio a 8M negli ambienti che non richiedono caricamenti di file o a 32M negli ambienti che ne hanno bisogno — si rendono più difficili i tentativi di esaurire la memoria tramite richieste di grandi dimensioni. Poiché occorre considerare le dimensioni delle intestazioni aggiuntive multipart, impostare upload_max_filesize su un valore leggermente inferiore a post_max_size. In PHP 8.5 applicare anche fatal_error_backtraces = 0.

3. Verificare la sintassi di PHP-FPM e riavviare i processi
   Dopo aver salvato la configurazione, verificare l’assenza di errori di sintassi e riavviare il servizio PHP-FPM.

   php-fpm -t
   systemctl restart php-fpm

   Se la configurazione è corretta, l’esecuzione di php-fpm -t visualizza il messaggio NOTICE: configuration file ... test is successful. È necessario riavviare i processi worker per terminare quelli obsoleti residenti in memoria e applicare la nuova patch e la configurazione.

4. Verificare la versione effettivamente applicata tramite una richiesta web
   Richiamare la scheda delle informazioni «Stato del sito (Site Health)» di WordPress o una pagina diagnostica dell’integrazione con il server web e verificare che il worker PHP-FPM che gestisce le richieste risponda con una versione corretta, come 8.4.27. Se è stato creato temporaneamente un file PHP diagnostico, eliminarlo subito dopo il controllo per evitare l’esposizione di informazioni di sistema all’esterno.

Come intervenire in caso di ritardo nell’aggiornamento o di effetti collaterali delle modifiche

Il pacchetto non può essere scaricato perché il mirror di un repository di terze parti, come Remi, non è ancora aggiornato

Subito dopo una patch di sicurezza urgente, la concentrazione del traffico o i ritardi di sincronizzazione possono impedire la visualizzazione immediata dei pacchetti aggiornati nei repository di terze parti, come rpms.remirepo.net, oppure ridurre la velocità di download. L’avviso ufficiale dichiara che il repository gestito da volontari potrebbe non pubblicare gli aggiornamenti il giorno dell’annuncio e raccomanda di passare ai pacchetti della distribuzione o alla compilazione dai sorgenti.

In questo caso, è possibile indicare direttamente nelle impostazioni del repository l’indirizzo di un mirror che abbia completato la sincronizzazione e offra una velocità normale, quindi procedere con l’aggiornamento. Anche modificando manualmente il mirror, mantenere attivo il controllo delle firme GPG (gpgcheck=1) per impedire la manomissione dei pacchetti. Se non è possibile utilizzare un mirror, usare i pacchetti ufficiali di backport della distribuzione o compilare direttamente il codice sorgente.

Possibili problemi di memoria insufficiente (OOM) o rifiuto dei caricamenti dopo l’applicazione della mitigazione

L’avviso ufficiale propone memory_limit = -1 (illimitato) come misura di mitigazione per CVE-2026-109618 quando non è possibile aggiornare immediatamente e raccomanda di applicare anche un limite di memoria tramite container o cgroup. Tuttavia, su server con poca memoria fisica, rimuovere il limite può consentire a una singola richiesta di consumare tutta la memoria del server, causando l’arresto forzato di demoni essenziali da parte dell’OOM Killer del sistema operativo. Si tratta di una misura temporanea da usare fino all’aggiornamento; dopo il passaggio alla versione corretta, è più sicuro ripristinare il limite di memoria originale.

Inoltre, prima di ridurre post_max_size rispetto al valore precedente, ad esempio 64MB, verificare il metodo di trasferimento dei file utilizzato dal sito. I siti che caricano direttamente file di backup o plugin di grandi dimensioni tramite una pagina web di amministrazione potrebbero vedersi rifiutare le richieste. Se invece i file di grandi dimensioni vengono trasferiti tramite SFTP o rsync, oppure se l’applicazione ha già un limite pari o inferiore a 30MB, ridurre a 32MB il limite di caricamento PHP non influisce sul servizio.

Se dopo l’aggiornamento della versione PHP i worker PHP-FPM terminano occasionalmente in modo anomalo, è possibile verificare la configurazione JIT (Just-In-Time) di OPcache. La funzionalità JIT, ad esempio opcache.jit=1255, non è direttamente correlata alle vulnerabilità di sicurezza in esame; tuttavia, se in passato ha causato problemi di stabilità durante i cambi di versione, è possibile disabilitarla nel file di configurazione con opcache.jit=off per prevenire conflitti.

Domande frequenti

Il problema si risolve aggiornando WordPress o i plugin all’ultima versione?

No. La vulnerabilità si verifica nel motore core di PHP, prima dell’esecuzione di WordPress o dei plugin di sicurezza. Un firewall per applicazioni web, come Cloudflare o AWS WAF, può bloccare temporaneamente i pattern di attacco noti, ma la soluzione fondamentale consiste nell’aggiornare la versione PHP del server tramite il provider di hosting o l’amministratore del server.

Disabilitando session.upload_progress.enabled è sicuro non aggiornare?

No. L’avviso ufficiale specifica che questa impostazione blocca solo il percorso di sessione confermato e non impedisce altre varianti. Inoltre, l’impostazione deve essere applicata prima dell’analisi della richiesta, in php.ini, nel pool FPM o nella configurazione del server, non tramite ini_set() o il file .user.ini di FPM; è inoltre necessario riavviare tutti i worker. L’unica soluzione completa è installare la patch.

Dopo aver completato l’applicazione della patch, è possibile tornare subito in produzione senza ulteriori verifiche?

L’aggiornamento blocca gli attacchi futuri, ma non indica se il sistema sia stato compromesso in precedenza. Anche dopo l’aggiornamento è consigliabile verificare separatamente l’eventuale compromissione precedente. Controllare se nella directory web sono presenti file PHP creati o modificati di recente in modo anomalo, come webshell, e analizzare i log di accesso del server web e i log degli errori PHP alla ricerca di richieste POST insolitamente grandi o di errori di memoria ripetuti.

Come intervenire negli ambienti con container o immagini cloud?

L’aggiornamento dei pacchetti sul server host non modifica automaticamente il runtime PHP incluso nel container. È quindi necessario ricostruire e ridistribuire l’immagine del container utilizzando un’immagine di base che includa le versioni corrette 8.5.12, 8.4.27, 8.3.36 o 8.2.35.

Fonti

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (in coreano)