In breve: CVE-2026-109619 è la seconda vulnerabilità dietro PHP2Shell. Lo stato interno associato a una richiesta può restare dopo la liberazione della memoria; una richiesta successiva nello stesso worker può usarlo prima che venga azzerato. La conseguenza è l'esecuzione di codice senza autenticazione. Rimedio: aggiornamento a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 e riavvio di tutti i worker.
Che cos'è CVE-2026-109619?
CVE-2026-109619 (identificativo GitHub GHSA-6wmf-4rv5-p3rp) ha un punteggio CVSS v4.0 di 9,2. Insieme a CVE-2026-109618 costituisce PHP2Shell. Entrambe le vulnerabilità si trovano in PHP stesso e non in un'applicazione.
L'effetto è lo stesso della vulnerabilità gemella: un aggressore può eseguire codice sul server da remoto, senza password e senza account utente. La causa è però un'altra.
Perché lo stato obsoleto nel worker è pericoloso
Un web server PHP non avvia un nuovo processo per ogni richiesta. Con PHP-FPM, Apache con mod_php, LiteSpeed o FrankenPHP un worker elabora molte richieste una dopo l'altra. Tra due richieste PHP azzera il proprio stato interno, in modo che nulla della richiesta A arrivi nella richiesta B.
Con CVE-2026-109619 questo azzeramento non riesce del tutto. Secondo php.net, lo stato interno associato alla richiesta può restare dopo la liberazione della memoria. Una richiesta successiva nello stesso worker può usare questo stato obsoleto prima che venga azzerato. In termini semplificati: viene riutilizzato qualcosa che in realtà non è più valido.
Dal punto di vista operativo è notevole. Il riutilizzo dei worker è voluto, perché rende veloci i web server: un worker non deve essere riavviato per ogni richiesta, caricare le estensioni e allocare memoria. La vulnerabilità colpisce quindi una caratteristica che hanno praticamente tutte le installazioni PHP produttive. php.net non indica alcuna configurazione che eviti del tutto il problema; per questo la strada passa dall'aggiornamento.
Dettagli sullo sfruttamento non ne pubblichiamo. Per i gestori conta questo: ogni modalità di esecuzione in cui i worker servono più richieste va tenuta d'occhio, e proprio queste modalità sono quelle abituali.
Le due vulnerabilità PHP2Shell a confronto
| Caratteristica | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Identificativo GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Valutazione | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Causa scatenante | Out-of-memory durante l'inizializzazione dei dati della richiesta | Lo stato interno resta dopo la liberazione |
| Effetto | Esecuzione di codice senza autenticazione | Esecuzione di codice senza autenticazione |
| Corretta in | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Sono interessati PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio più alto lo vede il team PHP con mod_php; il motivo lo spieghiamo alla pagina Perché mod_php comporta il rischio più alto.
Chiudere CVE-2026-109619: aggiornamento, poi riavvio di tutti i worker
Proprio con questa vulnerabilità il riavvio è decisivo. Finché vecchi worker girano in memoria, il server continua a lavorare con il codice difettoso, anche se i nuovi file sono da tempo sul disco.
Verifichi versione e stato dei pacchetti. I nomi dei pacchetti variano a seconda della distribuzione e dell'interfaccia dell'hoster:
php -v
php-fpm8.3 -v # il binario FPM può avere una versione diversa dalla CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # famiglia RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Poi riavviare tutti i servizi interessati:
sudo systemctl restart php8.3-fpm # in base alla versione di PHP installata
sudo systemctl restart apache2 # con mod_php; su RHEL il servizio si chiama httpd
Se la Sua distribuzione o il Suo hoster applica un backport, il numero di versione visualizzato può restare lo stesso. In tal caso contano il changelog del pacchetto e la conferma scritta del fornitore. Una verifica passo dopo passo si trova alla pagina Riavviare PHP-FPM e tutti i worker.
Annoti data e ora del riavvio. Per la successiva valutazione se un attacco sia avvenuto prima o dopo la patch, questo momento è il riferimento più importante.
Che cosa resta da fare dopo la patch
Una patch non dimostra che prima non sia successo nulla. Secondo i resoconti dei media, un primo tentativo di attacco è stato osservato il 17 ottobre, quattro giorni prima delle patch. Conservi i log del server a partire dal 20 ottobre, come raccomanda la stampa specializzata, e verifichi che il server non presenti anomalie. Indicazioni in merito sono alla pagina Sono già stato compromesso?.
Tenga presente la portata: con un'esecuzione di codice riuscita l'aggressore ha i privilegi del processo PHP. Può leggere ciò che l'applicazione può leggere, ad esempio file di configurazione con accessi al database o chiavi API. Se un incidente si conferma, queste credenziali vanno rinnovate dopo la bonifica.
Come aiuta concretamente PHP SOS?
Con il servizio di patch PHP attuiamo la correzione in modo verificabile:
- Rilevare: quali versioni e modalità di esecuzione di PHP girano su quale server, e quale fonte di pacchetti le fornisce?
- Applicare la patch: aggiornamento dalla fonte giusta oppure misure provvisorie secondo php.net, dove l'aggiornamento è ancora bloccato.
- Controllare il riavvio: verifichiamo processo per processo che giri solo più la versione corretta.
- Documentare: versioni, stati dei pacchetti e momenti del riavvio, in modo che possa dimostrare lo stato.
Domande frequenti
In che cosa CVE-2026-109619 si distingue da CVE-2026-109618?
CVE-2026-109618 nasce quando una condizione out-of-memory interrompe la richiesta a metà dell'inizializzazione. CVE-2026-109619 riguarda uno stato che resta nel worker dopo la fine di una richiesta. Entrambe portano all'esecuzione di codice senza autenticazione e sono corrette nelle stesse versioni di PHP.
Aiuta riavviare più spesso i worker PHP-FPM?
Come sostituto dell'aggiornamento non è adatto. php.net non indica riavvii più frequenti dei worker come misura provvisoria. I worker vanno però riavviati dopo l'aggiornamento, affinché giri davvero la versione corretta.
Un aggiornamento del CMS mi protegge da CVE-2026-109619?
No. La vulnerabilità si trova in PHP e non in WordPress, Shopware, TYPO3 o altri sistemi. La chiude solo un aggiornamento di PHP o un backport confermato dal fornitore.
Esistono tracce note di un attacco tramite CVE-2026-109619?
Finora non sono stati pubblicati Indicators of Compromise confermati. Il rilevamento si basa sull'analisi del comportamento, ad esempio nuovi file PHP, connessioni in uscita insolite o cronjob sconosciuti.