PHP2Shell: cause e guida alla risoluzione

Fonti controllate al 22 ottobre 2026. Apubblico: operatori applicativi PHP, addetti alla sicurezza e ingegneri che si occupano della manutenzione di build PHP personalizzate.

Questo articolo riassume la causa, la portata dell’impatto, il processo di riparazione formale, le misure di mitigazione temporanee e l’implementazione ufficiale della patch della vulnerabilità PHP2Shell. Il testo principale è citato utilizzando numeri come S1; tutti i collegamenti alle fonti sono elencati nell’appendice alla fine del testo. Il frammento di configurazione è un modello di distribuzione che deve essere modificato in base alla versione effettiva, alla capacità aziendale e alla relazione di ereditarietà della configurazione.

TL;DR: passaggi e suggerimenti per la riparazione

Aggiorna il runtime PHP: aggiorna il ramo pertinente almeno a 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Per i pacchetti di distribuzione, utilizzare la versione completa del pacchetto che, come confermato dal fornitore, risolve entrambi i CVE. S1 S10
Sostituisci tutti i vecchi processi: riavvia o esegui il rollover di ogni PHP worker, servizio di hosting e contenitore dopo l’aggiornamento e conferma che le vecchie istanze sono terminate.
Verifica tramite il percorso di richiesta Web effettivo: controlla Web SAPI, la versione completa del pacchetto e l’istanza in esecuzione. Il solo controllo di php -v non stabilisce che il servizio live sia corretto.
Esegui controlli di regressione aziendale e ripristina i normali budget delle risorse: test di accesso, gestione delle sessioni, caricamenti, importazioni e gestione degli errori. Se il limite di memoria PHP è stato rimosso temporaneamente, ripristinare un budget finito appropriato dopo l’applicazione della patch.
Se un aggiornamento immediato è impossibile: limita il traffico non attendibile prima che raggiunga PHP. Valutare la disabilitazione dell’avanzamento del caricamento e i backtrace irreversibili PHP 8.5 come descritto nella Sezione 5. Le mitigazioni della configurazione e le regole WAF hanno una copertura limitata e non possono sostituire un aggiornamento. S1 S2 S3

1. Panoramica della vulnerabilità e valutazione del rischio

PHP2Shell in questo articolo si riferisce a due vulnerabilità di livello Critical ufficialmente divulgate da PHP il 21 ottobre 2026. Entrambe sono correlate alla memoria e alla gestione del ciclo di vita delle richieste del motore PHP, ponendo il rischio di esecuzione di codice remoto non autenticato. S1 S2 S3

Progetto	CVE-2026-109618	CVE-2026-109619
nome ufficiale	RCE via OOM corruption	RCE via stale global state
questioni fondamentali	Una memoria insufficiente provoca un salto anomalo, lasciando uno stato che non ha ancora completato l’inizializzazione.	Lo stato globale rimanente nel lavoratore punta alla memoria della richiesta rilasciata.
Orario di occorrenza tipico	Il processo di inizializzazione, esecuzione o pulizia della richiesta corrente	La richiesta precedente lascia lo stato e le richieste successive lo consumano in anticipo.
OOM è una condizione necessaria?	Appartiene al meccanismo principale di attivazione della vulnerabilità	No; potrebbero essere coinvolti anche altri errori fatali e la pulizia post-diagnosi
Direzione della riparazione fondamentale	Gestisci in sicurezza gli errori di allocazione e le richieste di risoluzione	Correggi la proprietà statale, i tempi di pulizia e l’inizializzazione anticipata
Requisiti di smaltimento	deve essere riparato	deve essere riparato allo stesso tempo

Base: due bollettini ufficiali sulla sicurezza e correzioni inviate. S2 S3 S4

1.1 Informazioni sulle distribuzioni interessate

PHP considera ufficialmente tutte le distribuzioni PHP che gestiscono le richieste Web a rischio, incluse PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. L’attacco dimostrato mod_php può verificarsi prima dell’esecuzione del codice dell’applicazione, quindi i controlli di accesso, il middleware del framework e la convalida del caricamento dell’applicazione non possono coprire quel percorso. S1

È necessario distinguere tra “l’implementazione deve essere corretta” e “una certa catena di attacco è stata completamente dimostrata”. Annuncio di CVE-2026-109618: FPM uscirà dal processo figlio dopo che l’avvio della richiesta non è riuscito, bloccando il percorso di pulizia corrispondente di mod_php dopo l’errore di avvio; tuttavia, il percorso OOM dopo l’avvio riuscito è ancora a rischio. L’annuncio rileva inoltre che l’exploit FPM completo per questo CVE non è stato ancora dimostrato. Questa restrizione non può essere utilizzata per dedurre che FPM sia sicuro, soprattutto CVE-2026-109619 non può essere ignorato. S2 S3

I limiti immediati delle autorizzazioni per uno sfruttamento riuscito dipendono dall’identità del processo che ospita PHP e dalle risorse a cui ha accesso. In generale, è necessario prestare attenzione al codice del sito Web, alla directory di caricamento, alle credenziali del database, ai token di servizio e alle capacità di accesso alla rete interna; “esecuzione di codice da remoto” non significa ottenere in modo naturale i permessi di root. Il giudizio sulle conseguenze in questo caso si basa sul modello di autorizzazione del processo e l’impatto effettivo deve essere valutato insieme alle autorizzazioni di distribuzione.

Gli script CLI ordinari una tantum non hanno la stessa voce HTTP; ma i processi che gestiscono attività esterne per lungo tempo in CLI o in modalità incorporata dovrebbero comunque essere inclusi nell’inventario del runtime e del ciclo di vita. Vengono aggiornate solo le dipendenze CMS, framework o Composer e il motore PHP sottostante non viene sostituito automaticamente.

2. Analisi delle cause

2.1 Innanzitutto comprendere i due cicli di vita

PHP worker spesso gestisce più richieste in successione. La memoria allocata durante la richiesta può essere rilasciata uniformemente al termine della richiesta, mentre il lavoratore stesso e alcuni dei suoi campi globali continuano ad esistere.

Pertanto il motore deve mantenere due vincoli:

Ivincolo di inizializzazione: i dati visibili ad altri codici devono essere in uno stato che possa essere letto, attraversato e distrutto in modo sicuro.
Vincolo del ciclo di vita: una volta liberata la memoria della richiesta, i campi con durata più lunga non devono continuare a trattare gli indirizzi all’interno di quella memoria come stati validi.

Questi due vincoli corrispondono alle principali modalità di fallimento dei due gruppi di vulnerabilità. Il seguente processo è una descrizione del meccanismo che combina gli annunci e la compilazione delle patch. Ciò non significa che ogni distribuzione abbia esattamente lo stesso percorso raggiungibile. S2 S3 S5

2.2 CVE-2026-109618: OOM ha interrotto un aggiornamento di stato non completato

La vecchia implementazione utilizza un salto non locale di tipo longjmp() per gestire OOM e il percorso associato esce dal contesto di esecuzione corrente tramite zend_bailout(). Il pericolo è che un pezzo di codice C possa aver pubblicato un nuovo oggetto, array o stato di richiesta in un altro codice, ma non ha ancora completato l’inizializzazione di tutti i campi; in questo momento, qualsiasi mancata allocazione al momento rilevante potrebbe causare il salto delle normali fasi di chiusura. S2

Il processo di fallimento può essere suddiviso in quattro fasi:

Creare o aggiornare la struttura interna della richiesta e renderla accessibile.
La successiva allocazione della memoria fallisce e viene attivato OOM.
Il flusso di esecuzione si allontana dalla funzione corrente e il codice originariamente utilizzato per completare l’inizializzazione o ripristinare lo stato non viene eseguito.
La pulizia della richiesta continua l’elaborazione di queste strutture e tratta i contenuti non validi come campi o indirizzi validi.

Il problema non è che l’esaurimento della memoria causa sempre RCE. Piuttosto, l’esaurimento della memoria modifica il flusso di controllo e viola le ipotesi del motore sulle strutture valide. Non è necessario che la mancata allocazione coinvolga direttamente la struttura che eventualmente viene letta in modo errato. S2

Perché anche le richieste più piccole possono esaurire la memoria

Il numero di byte nel corpo della richiesta e l’utilizzo dell’heap dopo l’analisi non sono la stessa cosa. Il campo A può corrispondere a più stringhe, elementi di array e oggetti di metadati all’interno di PHP; la complessità strutturale dell’input influenzerà il grado di amplificazione della memoria.

I problemi con multipart elencati nell’annuncio ufficiale includono: gap nel controllo della dimensione iniziale quando manca la lunghezza della dichiarazione disponibile, il numero di intestazioni per una singola parte non è sufficientemente limitato e i controlli di file vuoti producono ancora metadati, con nomi nidificati che aumentano ulteriormente il carico di lavoro dell’array. Anche lo svolgimento, la decodifica o la riassegnazione dell’input dell’applicazione possono essere una fonte di OOM. S2

Da ciò si possono trarre due conclusioni protettive:

Le restrizioni sul corpo della richiesta devono essere implementate il più possibile prima di inserire PHP e devono essere considerate l’effettiva lunghezza di lettura e la complessità strutturale.
La limitazione individuale della dimensione del file, del numero di file o la chiusura di un solo portale di caricamento non possono coprire tutte le origini OOM.

Perché l’autenticazione dell’applicazione potrebbe essere troppo tardi

In mod_php, il corpo della richiesta può essere analizzato automaticamente durante la fase di inizializzazione della richiesta; anche se l’avvio fallisce, verrà comunque eseguita la pulizia delle richieste correlate. I percorsi di attacco confermati possono quindi verificarsi prima del codice dell’applicazione. Per ridurre l’esposizione in questa fase, è necessario applicare restrizioni al proxy inverso, al server Web o ad altri limiti che precedono l’elaborazione della richiesta PHP. S1 S2

2.3 CVE-2026-109619: La memoria richiesta è stata liberata, il riferimento globale è ancora vivo

Questo problema riguarda lo stato di errore, sessione, oggetto o estensione: il campo è archiviato in una posizione di accesso a lungo termine del lavoratore, ma i dati a cui fa riferimento il campo appartengono a una singola richiesta. Finché il riferimento non viene ripulito correttamente prima che l’heap delle richieste venga rilasciato, le richieste successive potrebbero incontrare uno stato sospeso, formando use-after-free. S3

L’analisi ufficiale divide le condizioni di sfruttamento in “produttori” e “consumatori”:

ruolo o condizione	significato	Implicazioni per la tutela
produttore statale	Inserisci lo stato di proprietà di questa richiesta in una posizione a cui è ancora possibile accedere in seguito	Per verificare se la pulizia corrispondente è stata completata dopo un’uscita anomala
Lo stato rimane	Non è stato ripulito oppure è stato ripulito e quindi riempito nuovamente tramite un’operazione tardiva.	La semplice pulizia una volta nella fase di arresto precedente potrebbe non essere sufficiente
riutilizzo dei lavoratori	Lo stesso lavoratore continua a elaborare le richieste successive	Più lavoratori rappresentano solo una differenza di programmazione, non una garanzia di sicurezza della memoria
consumatore anticipato	Leggere, rilasciare o determinare il valore residuo prima che lo stato corrispondente venga inizializzato normalmente.	È necessario controllare INI, sessione e altri percorsi prima dell’inizializzazione

Queste condizioni devono essere soddisfatte in combinazione; qualsiasi registro degli errori di per sé non dimostra che la vulnerabilità sia stata sfruttata con successo. S3

Non richiede OOM come prerequisito necessario

Errori irreversibili possono interrompere la pubblicazione e il ripristino dello stato abbinato. Errori di compilazione o analisi, errori non rilevati, errori require e timeout di esecuzione possono lasciare indietro stati particolari. La diagnostica non irreversibile in una fase avanzata della pulizia può anche ripopolare le informazioni sugli errori già cancellate. S3

Pertanto, la modifica di memory_limit in illimitato non copre questo insieme di vulnerabilità.

”Prima dell’inizializzazione” deve essere trattato separatamente

Le tempistiche delle due tipologie di consumatori confermati sono diverse:

E Diagnostica INI iniziale: alcune configurazioni applicate su richiesta emettono avvisi, avvisi o deprecazioni prima della normale inizializzazione dell’esecutore e l’elaborazione diagnostica potrebbe accedere al vecchio stato di errore.
avanzamento caricamento sessione: la sessione può essere elaborata in anticipo durante il processo di analisi del corpo della richiesta, ma il modulo normale RINIT non è stato ancora completato; non è possibile dedurre che il percorso non esista poiché l’applicazione non chiama esplicitamente session_start(). S3

Non tutte le configurazioni INI presentano gli stessi tempi di rischio. La configurazione a livello di directory di mod_php e PHP_VALUE / PHP_ADMIN_VALUE passata dal front-end FPM deve essere distinta dalla configurazione di avvio ordinaria di php.ini, FPM pool e FPM .user.ini. Questi ultimi hanno tempi di configurazione diversi e non possono essere collettivamente definiti gli stessi primi consumatori. S3

La disattivazione di display_errors, log_errors, la riduzione di error_reporting o l’utilizzo di @ influiscono solo sulla visibilità della diagnosi; è possibile che sia stato effettuato l’accesso allo stato interno rilevante prima di decidere se inviare in output il registro. S3

3. Ripara la versione e la selezione della patch

3.1 Baseline ufficiale delle correzioni a monte

Filiale PHP attuale	La prima versione a includere questa correzione ufficiale	Suggerimenti
8.2	8.2.35	Aggiorna a questa versione o a una versione successiva contenente le stesse correzioni
8.3	8.3.36	Come sopra
8.4	8.4.27	Come sopra
8.5	8.5.12	Come sopra
8.1 e versioni precedenti	Il supporto generale a monte è terminato	Dare priorità alla migrazione alle filiali supportate; rilascio di controllo a breve termine o backport del produttore LTS

La versione e lo stato del supporto si basano sull’annuncio ufficiale di PHP e il riferimento temporale è il 22 ottobre 2026. S1

Queste sono soglie fisse specifiche del ramo. Non possono essere sostituite da una dichiarazione secondo cui ogni versione inferiore a 8.5.12 è vulnerabile: versioni come 8.2.35 e 8.4.27 in altri rami contengono già le correzioni.

3.2 Controlla la versione completa del pacchetto di distribuzione

Le distribuzioni spesso aggiungono correzioni di sicurezza basate su versioni upstream precedenti. L’accettazione dovrebbe anche verificare la versione di rilascio, la fonte del repository, la versione completa del pacchetto e il bollettino sulla sicurezza.

Ad esempio, la versione del pacchetto di correzioni Ubuntu 24.04 LTS elencata per Ubuntu USN-8948-1 è:

8.3.6-0ubuntu0.24.04.13

La sua parte upstream è ancora 8.3.6, ma la versione completa del pacchetto di quella distribuzione è inclusa in questo annuncio di correzione. Questa conclusione si applica solo alla distribuzione e all’origine del pacchetto corrispondenti e non può essere generalizzata a qualsiasi build che visualizzi anche 8.3.6. S10

3.3 Scegliere la patch giusta

scena	Piano prioritario	Punti chiave per l’accettazione
Utilizzando il pacchetto di distribuzione PHP	Installa gli aggiornamenti di sicurezza rilasciati dal produttore	L’annuncio riguarda sia CVE; la versione completa del pacchetto è corretta
Utilizza il contenitore PHP ufficiale o l’immagine creata autonomamente	Aggiorna il runtime di base, ricostruisci e distribuisci	L’istanza in esecuzione utilizza la nuova immagine; tutte le vecchie copie vengono chiuse
Rami supportati autocompilati	Utilizza la versione di sicurezza ufficiale di questo ramo o il set completo di patch ufficiali	Corrispondenza dei rami, completamento delle dipendenze, compatibilità delle estensioni e passaggio della regressione
Soggetto a 7.4, 8.0, 8.1	Dare priorità al backport del fornitore; valutare il ramo ufficiale del codice sorgente di emergenza, se necessario	Identifica le modifiche comportamentali e pianifica la migrazione alle versioni supportate

Sono state rilasciate patch ufficiali e le correzioni effettive dovrebbero iniziare da queste patch. I frammenti di codice nella Sezione 6 hanno lo scopo di illustrare i punti salienti della progettazione e della revisione e non costituiscono una patch completa che può essere applicata in modo indipendente. S1 S4 S6

4. Processo di riparazione formale

4.1 Inventario del runtime che gestisce effettivamente le richieste

Si consiglia di formare un breve libro mastro in cui registrare almeno:

Nome di dominio o servizio di ingresso, backend proxy inverso, PHP SAPI.
Ramo PHP, versione completa del pacchetto o digest dell’immagine, sorgente di build.
FPM pool, unità di servizio effettiva, contenitore o Pod, numero di repliche.
Sono state caricate le estensioni, la configurazione principale e i file di configurazione aggiuntivi.
Esistono altre versioni PHP, vecchie copie di distribuzione o portali di origine a cui è possibile accedere direttamente?

Questi sono suggerimenti di implementazione in modo che “aggiornato” possa corrispondere a ciascun ingresso di traffico effettivo. Controlla soprattutto se le righe di comando PHP e Web PHP utilizzano versioni diverse, l’immagine è creata ma il vecchio contenitore è ancora in esecuzione, parte del pool o la copia non viene sostituita, ecc.

4.2 Selezionare e distribuire l’aggiornamento corretto

Confermare la versione della correzione come indicato nella Sezione 3, preferibilmente utilizzando un’origine di pacchetto attendibile esistente o una catena di build controllata. L’ambito dell’aggiornamento dovrebbe includere il componente che ospita effettivamente la richiesta, ad esempio il pacchetto FPM, il modulo Apache PHP, il file binario CGI o la build del servizio in cui è incorporato PHP.

Prima dell’aggiornamento, conserva la configurazione e l’elenco dei pacchetti e verifica l’avvio e i servizi chiave in un ambiente simile alla produzione. Per le estensioni autogestite, verificare la compatibilità di build ed esecuzione corrispondente alla versione PHP. La semplice selezione di un commit apparentemente rilevante da un altro ramo non garantisce che l’intera serie di correzioni sia stata implementata.

4.3 Riavvia o esegui il rollover delle istanze in esecuzione

Installare un file e caricare un nuovo codice in un processo sono due cose diverse. Il servizio corrispondente dovrebbe essere riavviato o la sostituzione progressiva dovrebbe essere completata e si dovrebbe confermare che il vecchio lavoratore e il vecchio contenitore sono usciti.

Per mod_php, riavviare il processo Apache che ospita il modulo. I servizi che incorporano PHP necessitano della sostituzione del processo di hosting. Per FPM, la cancellazione di OPcache non sostituisce l’aggiornamento del runtime e il ritiro dei vecchi lavoratori.

Quando si utilizza il passaggio graduale, è necessario verificare se il processo di vecchia generazione gestisce ancora connessioni lunghe o richieste in sospeso. Il record di accettazione deve includere il servizio effettivo, la versione di distribuzione, l’ora di completamento della modifica e i risultati di uscita della vecchia istanza.

4.4 Verifica tramite richieste Web reali

Si consiglia di combinare le seguenti prove anziché fare affidamento esclusivamente su un singolo comando di versione:

prove	Cosa può essere dimostrato	Non posso provare nulla da solo
Gestore pacchetti o metadati immagine	Origini di installazione e build complete	Il traffico è stato trasferito a questa istanza
Stato del processo e della distribuzione	il lavoratore o il contenitore completano la sostituzione	Ad esso deve essere indirizzato l’ingresso esterno
Risultati diagnostici limitati accessibili tramite portale reale	Web SAPI effettivo e configurazione in esecuzione	Se il backport di rilascio copre due CVE
Annuncio del fornitore o record completo della patch	Questa correzione del bug è inclusa in questa build	Tutte le repliche vengono distribuite

PHP_VERSION, PHP_SAPI, i file di configurazione caricati e le configurazioni di emergenza possono essere controllati tramite le funzionalità diagnostiche interne esistenti o portali diagnostici temporanei e ad accesso controllato. Assicurati che la richiesta non venga restituita direttamente da CDN o dalla cache della pagina; rimuovere la voce diagnostica temporanea una volta completata.

php -v di solito indica solo il binario CLI attualmente selezionato dalla shell; comandi come php-fpm -i non equivalgono alla verifica del lavoratore esistente che riceve traffico. Non esporre la pagina phpinfo() completa alla rete pubblica per lungo tempo.

4.5 Controlli di regressione aziendale e rimozione delle impostazioni di emergenza

Verificare il normale accesso, la sessione di lettura e scrittura, il modulo e il caricamento, l’importazione, la gestione degli errori e la stabilità del lavoratore attorno alle funzioni interessate da questa modifica. Controllare se il tasso di errore, il ritardo di risposta, il picco di memoria, l’uscita del processo e la frequenza di ricostruzione sono anomali.

Se memory_limit=-1 è impostato temporaneamente, il budget limitato corrispondente alla capacità aziendale verrà ripristinato dopo l’entrata in vigore della patch ufficiale; se è impostato pm.max_requests=1, la configurazione del ciclo di vita valutato in base alla capacità verrà ripristinata dopo la conferma della riparazione. I limiti delle dimensioni di input e i controlli di accesso alla fonte possono essere mantenuti in base alle esigenze aziendali.

Se durante l’aggiornamento si verificano problemi di compatibilità, è necessario dare priorità alla sospensione del portale interessato, alla limitazione dell’accesso esterno o alla modifica dell’applicazione prima del rollback. Consentire direttamente al runtime non riparato di servire nuovamente la rete pubblica riaprirà il rischio originale.

5. Misure di mitigazione quando non è possibile un aggiornamento immediato

Questa sezione è destinata alla riduzione a breve termine dell’esposizione o al miglioramento della disponibilità. Ogni misura copre solo un percorso specifico e la combinazione di più misure non equivale ad una riparazione completa. S1 S2 S3

5.1 Dare priorità ai controlli del traffico prima di PHP

Se il servizio lo consente, limita temporaneamente gli endpoint sensibili a fonti attendibili o applica il controllo degli accessi prima di PHP. Per i carichi di lavoro di caricamento, limitare la dimensione del corpo della richiesta, il conteggio dei campi, il conteggio delle parti, le intestazioni per parte e la profondità di nidificazione. I servizi che non necessitano di multipart possono rifiutarlo nel frontend. S2

Queste restrizioni devono coprire tutti gli ingressi a PHP. Solo intercettando il URL denominato “upload” mancheranno altre voci che vengono ancora analizzate automaticamente da PHP nel corpo della richiesta. Per casi quali trasferimenti in blocchi, mancanza di lunghezza dichiarata disponibile, ecc., il limite dovrebbe essere basato sulla dimensione effettiva della lettura; l’applicazione dovrebbe inoltre avere un proprio budget per le dimensioni di output quando si decomprime o si espande nuovamente il contenuto.

Modello di configurazione 5.2 FPM pool

Inserisci le seguenti impostazioni nella sezione di configurazione FPM pool che effettivamente serve le richieste, non letteralmente in php.ini. I valori 8M e 4M sono esempi da adattare al carico di lavoro. Lascia spazio ai campi modulo e ai limiti multiparte quando limiti l’intera richiesta POST. S11 S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

Solo PHP 8.5, più:

php_admin_flag[fatal_error_backtraces] = off

Le funzioni e i limiti di ciascuno sono i seguenti:

Configurazione	effetto atteso	Descrizione delle restrizioni che devono essere mantenute
`memory_limit=-1`	Rimuovere la prevedibile condizione di attivazione del limite superiore della memoria richiesta PHP	Non impedisce il fallimento dell’allocazione sottostante; l’annullamento del budget originale può aumentare il rischio di esaurimento della memoria e interruzione del servizio.
Più piccolo `post_max_size`	Ridurre la dimensione dei dati immessi nel processo di analisi	Il parser non corretto ha riscontrato un gap noto; l’amplificazione della memoria non può essere prevenuta in modo indipendente
`upload_max_filesize < post_max_size`	Limita la dimensione del singolo file e riserva lo spazio di sovraccarico della richiesta	Non vincola tutti i campi, i metadati o le allocazioni in-app
Chiudi l’avanzamento del caricamento	Blocca il percorso correlato alla sessione confermata	Non copre altre varianti di stati globali
PHP 8.5 chiude il backtrace fatale	Blocca i produttori con stato correlato confermato	Non copre altri percorsi come la sessione

I limiti della misura derivano dal comunicato ufficiale; per la sintassi del pool e la semantica di configurazione a livello di gestione, consultare il manuale PHP. S1 S2 S3 S11

Le impostazioni php_admin_* a livello di gestione non possono essere sovrascritte dalle applicazioni tramite ini_set(). Tutte le configurazioni in entrata di pool, a livello di directory e front-end dovrebbero comunque essere riviste per confermare che i valori sulle richieste effettive siano quelli previsti. Dopo la modifica, ricostruire tutto il lavoratore per evitare che i processi esistenti continuino a mantenere il vecchio stato.

Se si sceglie di modificare direttamente php.ini, la sintassi dovrebbe essere modificata in:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

A differenza di php_admin_value nel pool, la semplice impostazione di memory_limit=-1 in php.ini non impedisce all’app di modificarlo nuovamente. Il framework, il codice dell’applicazione e altre configurazioni dovrebbero essere controllati per vedere se hanno ripristinato il valore limitato; quando è richiesta l’applicazione, utilizzare le impostazioni a livello di gestione appropriate per l’attuale SAPI e verificare il valore effettivo effettivo. S11 S12

Aggiungere fatal_error_backtraces = Off solo per PHP 8.5. Non utilizzare ini_set() a livello di applicazione come soluzione alternativa per disabilitare l’avanzamento del caricamento e non fare affidamento su FPM .user.ini per renderlo efficace prima dell’analisi della richiesta. S1 S3

5.3 Gestisci il costo della rimozione dei limiti di memoria PHP

memory_limit=-1 è una mitigazione del percorso temporanea per ambienti non corretti e non deve essere copiata come configurazione predefinita a lungo termine. Quando un’applicazione o una richiesta sfugge al controllo, può utilizzare una parte maggiore della memoria dell’host. Pertanto, prima dell’uso, è necessario valutare il numero di simultaneità, il picco del singolo lavoratore e la capacità totale del servizio e distribuire i limiti di input front-end. S2

I limiti di memoria del contenitore o del cgroup possono fornire limiti di disponibilità ma non garantiscono che le allocazioni non falliranno mai; anche l’intero contenitore, il master e tutti i lavoratori possono essere terminati quando viene attivato il limite. La granularità dell’isolamento e le strategie di terminazione devono essere valutate insieme alla distribuzione e non possono essere definite protezione completa per questi due CVE. S2

Non sostituire le strategie di cui sopra con RLIMIT_AS, RLIMIT_DATA o corrispondenti restrizioni sullo spazio degli indirizzi del processo; potrebbero causare direttamente il fallimento dell’allocazione sottostante nel percorso ancora problematico OOM. S2

5.4 Nginx Esempio di configurazione

Applicabile alla distribuzione in cui Nginx inoltra le richieste a PHP-FPM. Può essere impostato a livello di configurazione del servizio di hosting attuale:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size limita la dimensione del corpo richiesta; fastcgi_request_buffering on consente a Nginx di leggere prima il corpo completo della richiesta e quindi di inviarlo al backend FastCGI. È necessario verificare se entra in vigore in un determinato server o location insieme ai rapporti di successione e di copertura esistenti. S13 S14

Solo quando l’azienda non necessita di multipart, puoi aggiungere una regola di rifiuto alla voce di servizio corrispondente:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Questo è un semplice modello di restrizione dell’ingresso che utilizza if e return, non una regola di filtro generale per le vulnerabilità del parser. Verificare la sintassi di configurazione e le richieste normali prima della distribuzione e verificare se lo error_page personalizzato reindirizza le richieste 403 a PHP. La corrispondenza delle stringhe non fornisce garanzie complete su tutte le differenze di analisi. S15

Inoltre, queste configurazioni non limitano automaticamente la quantità di dati, il numero di campi o il numero di oggetti PHP che possono essere decompressi dall’applicazione; le aziende che devono effettuare caricamenti dovrebbero utilizzare restrizioni aggiuntive che comprendano la struttura delle loro richieste.

5.5 Mitigazione facoltativa: una richiesta per lavoratore FPM

Per le distribuzioni FPM che possono permettersi l’overhead, è possibile valutare configurazioni a breve termine:

pm.max_requests = 1

E ricostruire il lavoratore esistente. Blocca la catena di richieste incrociate descritta a livello di riutilizzo del lavoratore, ma aumenterà il sovraccarico di creazione e inizializzazione del processo; allo stesso tempo, non può riparare la stessa richiesta OOM e i problemi di pulizia di CVE-2026-109618. Quando il valore è inferiore ma maggiore di 1, è ancora presente una finestra di riutilizzo della richiesta. S3 S11

Limiti di copertura 5.6 WAF e Cloudflare

Cloudflare ha annunciato accordi di implementazione per la protezione contro PHP2Shell, incluso il piano Free. Quando si utilizzano i suoi servizi è bene verificare se il traffico effettivo passa attraverso il proxy, se sono in vigore le regole di protezione e se il sito di origine può essere direttamente bypassato; per i piani a pagamento è necessario verificare anche la configurazione e le eccezioni delle corrispondenti Regole Gestite. S16

Alcuni dei rilevamenti descritti dal fornitore utilizzano segnali di risposta, quindi tutte le protezioni non possono essere interpretate come “ogni attacco viene bloccato prima di raggiungere PHP”. WAF può aiutare a ridurre l’esposizione e fornire informazioni osservative, ma sono ancora necessari aggiornamenti continui a PHP. S16

5.7 Perché le misure comuni sono insufficienti

misure o giudizi	carenze
Chiudere solo `file_uploads`	Impossibile coprire tutta l’elaborazione multiparte e applicare il proprio percorso OOM
Impostazione `enable_post_data_reading=Off`	Modificare il comportamento del riempimento automatico di POST/FILES; il corpo della richiesta può ancora essere letto dall’applicazione e potrebbe interrompere la normale attività
Disattiva la visualizzazione degli errori, registra o utilizza `@`	L’elaborazione diagnostica interna potrebbe ancora accedere allo stato pendente
Aumentare la quantità di lavoratori	Non istituire un meccanismo di pulizia statale sicuro, né eliminare il riutilizzo del singolo lavoratore
Configurare solo `disable_functions` o `open_basedir`	Queste limitazioni non risolvono il danneggiamento della memoria del livello del motore C
Controlla una versione o una singola copia solo una volta	Non è possibile dimostrare che tutti gli ingressi e le istanze funzionanti siano stati sostituiti
Non viene visualizzato alcun registro delle eccezioni	Non può dimostrare che la vulnerabilità non esista o che non sia stata sfruttata prima.

Tra questi, la base del meccanismo di configurazione e vulnerabilità di PHP può essere trovata in S2 S3 S12; i giudizi sulla copertura, sull’accettazione e sui limiti di autorizzazione si basano sui suggerimenti di implementazione avanzati da questi meccanismi.

6. Idee per l’implementazione e punti di revisione della patch ufficiale

6.1 Utilizzare correzioni complete per il ramo corretto

La presentazione ufficiale rappresentativa per PHP 8.5 è:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

Il commit associa esplicitamente due CVE, sia per regolare il meccanismo di uscita OOM sia per correggere lo stato globale a cui è possibile accedere durante la fase di inizializzazione. Invia la pagina con il differenziale completo, vedi S4 S5. Altri rami dovrebbero utilizzare le proprie versioni di sicurezza ufficiali o patch corrispondenti e non si può presumere che le modifiche a 8.5 possano essere applicate direttamente a qualsiasi versione precedente.

6.2 OOM Riparazione: ripristina prima lo stato elaborabile, quindi termina la richiesta

L’implementazione formale introduce due livelli di elaborazione soft e hard OOM: quando viene raggiunto il limite soft, lo stato in sospeso viene registrato e viene eseguita un’uscita controllata in un luogo sicuro come VM; l’interfaccia di allocazione non riuscita consente al chiamante di gestire esplicitamente l’errore. Per le allocazioni che non possono restituire direttamente un errore, se è previsto il superamento di una soglia rigida più elevata, il processo verrà terminato direttamente per evitare di continuare a elaborare le richieste in uno stato intermedio non sicuro. S2 S5

Quello che segue è un estratto del codice chiave nel diff 8.5 utilizzato per contrassegnare OOM in sospeso:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

La gestione degli interrupt VM e altri luoghi sicuri chiamano successivamente zend_handle_delayed_oom(). Il contesto di esecuzione del codice utente utilizza un percorso di rimozione controllato; il percorso difficile OOM chiama _exit(137). S5

Dal punto di vista della progettazione, le modifiche importanti sono: evita di attraversare arbitrariamente lo stack di chiamate C quando la struttura è in uno stato intermedio e posiziona l’uscita in una posizione che può mantenere i vincoli di stato. Dopo l’attivazione del limite flessibile, potrebbe essere necessaria memoria aggiuntiva per completare il processo, pertanto la nuova soglia flessibile non può essere intesa come limite superiore assoluto per la memoria totale del processo.

Né può essere riassunto come “PHP ha cancellato tutti gli zend_bailout()”. La patch utilizza ancora meccanismi rilevanti in contesti specifici; ciò che viene fissato sono i pericolosi tempi di uscita e la relativa gestione statale. S5

6.3 Aggiorna i chiamanti di allocazione e l’analisi in più parti insieme

Se si modifica una funzione di allocazione solo in “restituisci NULL in caso di errore” e il chiamante originale presuppone comunque che venga sempre restituito un puntatore valido, si introdurranno nuovi accessi a puntatori null o una pulizia incompleta. L’interfaccia di allocazione fallibile nella patch deve essere rivista insieme al controllo del chiamante e alla propagazione delle eccezioni. S5

Le correzioni correlate a più parti includono anche l’esecuzione di controlli cumulativi basati sul volume di lettura effettivo, la riduzione dell’elaborazione di intestazioni inutili o duplicate e l’adozione di una logica di uscita e pulizia coerente quando OOM è in sospeso. Queste modifiche riducono l’amplificazione delle risorse e rendono il parser conforme al nuovo protocollo OOM. S5

Per i team che mantengono i propri rami, si consiglia di focalizzare la revisione del codice sui seguenti problemi:

Lo stato è visibile al mondo esterno prima che sia completamente inizializzato?
Dopo un errore di allocazione o un’eccezione di callback, la proprietà è ancora unica e inequivocabile?
Riuscirai a raggiungere l’uscita di pulizia unificata se fallisci a metà?
La funzione di pulizia può riconoscere i campi non inizializzati o liberati?
Il budget di analisi è basato sul volume di elaborazione effettivo e non solo sulle richieste di attendibilità?
Il nuovo valore restituito dall’errore è stato gestito da tutti i chiamanti?

Queste sono domande di revisione riepilogate in base al meccanismo di correzione e non sono la conclusione di un controllo completato per una codebase non fornita.

6.4 Correzione delle richieste incrociate: inizializzazione anticipata, pulizia finale successiva

Corrispondente a CVE-2026-109619, la patch modifica contemporaneamente più limiti del ciclo di vita. I file e le operazioni elencate di seguito prendono come esempio il diff ufficiale PHP 8.5. S5

posizione	cambiare direzione	Problema risolto
`Zend/zend_execute_API.c` ecc.	Reimposta lo stato dell’esecutore come errori, eccezioni, gestori, oggetti, ecc.	Al termine della richiesta, sono ancora presenti vecchi riferimenti a cui è possibile accedere dalla richiesta successiva.
Percorso di avvio di `main/main.c`	Chiama `php_basic_early_rinit()` prima che SAPI venga attivato	Quando si verifica un consumo anticipato, il relativo stato sottostante non è stato ancora inizializzato.
Chiudi il percorso di `main/main.c`	Distruggi HTTP globals e contrassegnalo come non definito	Il valore rilasciato è ancora considerato un oggetto valido
prima che l’heap delle richieste venga finalmente liberato	Pulisci nuovamente l’ultimo messaggio di errore	La diagnostica della pulizia tardiva ripopola lo stato di errore
`ext/session/session.c`	avanzamento del caricamento Il percorso iniziale viene inizializzato nella prima sessione globale	Il modulo normale RINIT ha avuto accesso in precedenza al vecchio stato
Codice relativo alla serializzazione	Limita l’analisi delle classi e le richiamate degli utenti nell’elaborazione iniziale	Eseguire il codice utente aggiuntivo quando l’inizializzazione non è completa

Ad esempio, la sequenza di avvio include:

zend_activate();
php_basic_early_rinit();
sapi_activate();

Dopo che HTTP globals è stato distrutto, aggiungere il contrassegno di errore di stato:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

Questi estratti illustrano due principi: inizializzare prima del primo consumer possibile ed eseguire la pulizia finale dopo l’ultima operazione che potrebbe ricreare lo stato. La reimpostazione di un puntatore solo durante la normale RINIT o una fase di arresto precedente potrebbe far perdere accessi precedenti o successivi. S5

6.5 Perché non è consigliabile effettuare la propria “riparazione su una riga”?

Sostituire tutti gli zend_bailout() con _exit(), o semplicemente aggiungere un controllo del puntatore nullo a una determinata voce, si estenderebbe a un gran numero di contesti di esecuzione diversi. Possono omettere altri campi di stato oppure modificare la distruzione, i callback estesi, l’hosting dei processi e la semantica finale delle richieste.

Per le versioni supportate, le correzioni complete già rilasciate hanno la precedenza. La migrazione dei propri rami dovrebbe registrare l’origine delle patch, le linee di base applicabili, la gestione dei conflitti e le modifiche del comportamento e utilizzare i corrispondenti casi d’uso di regressione upstream e la verifica di questo processo aziendale. I suggerimenti qui provengono da un’analisi dell’ambito della patch attraverso l’allocatore, VM, la sessione e le modifiche al ciclo di vita della richiesta. S4 S5

7. Backport di emergenza di PHP 7.4, 8.0, 8.1

PHP fornisce ufficialmente il backport minimo del codice sorgente di tre vecchi rami in base alla gravità. I nomi dei rami sono:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

Per i collegamenti di diramazione, vedere S7 S8 S9. Si tratta di consegne di emergenza per questa vulnerabilità e non rappresentano un ritorno al regolare supporto upstream per il vecchio ramo, né sostituiscono altri aggiornamenti di sicurezza. S1

7.1 Prendi come esempio il backport PHP 8.1

Le comunicazioni rilevanti per PHP 8.1 sono:

1d7dec178a094e6e75b229ce22754045f8c6070a

La sua strategia favorisce il fail-fast: chiamare _exit(1) dopo aver inviato la diagnostica nel percorso OOM corrispondente e incluso lo stato globale e altre correzioni rilevanti; disabilitando internamente l’elaborazione corrispondente dell’avanzamento del caricamento della sessione. Per l’invio del codice sorgente pertinente, vedere S6.

Questa è una differenza di comportamento rispetto alla progettazione OOM ritardata più completa nel ramo supportato. Solo perché la configurazione mostra ancora che l’avanzamento del caricamento è attivo, non significa che il comportamento di elaborazione interna dopo questo backport rimarrà invariato.

7.2 Il prezzo che devi accettare durante la distribuzione

L’uscita diretta dal processo può causare il fallimento della richiesta corrente, saltando i normali callback di arresto PHP e parte della chiusura dell’applicazione; se l’host adotta un modello a thread, è necessario anche valutare l’impatto dell’uscita dell’intero processo host su altro lavoro simultaneo. Nella verifica dovrebbe essere incluso anche il fatto che il responsabile del processo possa avviare il processo di sostituzione in tempo.

Pertanto, gli utenti di versioni precedenti dovrebbero considerare in ordine:

Migrare al ramo PHP supportato e alla sua versione fissa.
Utilizzare una versione che copra esplicitamente sia CVE che l’aggiornamento del produttore LTS.
Se è effettivamente soggetto alla vecchia versione del codice sorgente, utilizzare il backport di emergenza ufficiale della versione corrispondente per verificare le modifiche complete e la compatibilità e organizzare la successiva migrazione.

Il “backport minimo” qui descrive la compatibilità e l’ambito di implementazione selezionati dal funzionario e non deve essere interpretato automaticamente come “risoluzioni di vulnerabilità incomplete note”. Dovresti giudicare in base al codice sorgente del ramo corrispondente e all’annuncio del produttore e non eliminare da solo le modifiche di supporto. S1 S6

8. Criteri di accettazione e ispezioni di follow-up

Si consiglia di utilizzare i seguenti risultati come base per completare questa riparazione:

Articoli di accettazione	Standard di completamento
copertura delle vulnerabilità	L’annuncio della build o del fornitore risolve esplicitamente CVE-2026-109618 e CVE-2026-109619
Copertura della distribuzione	Tutti i portali, il pool, i servizi e le repliche utilizzano il runtime riparato
Il processo entra in vigore	Il vecchio lavoratore, il vecchio processo host e il vecchio contenitore escono tutti
Verifica della richiesta autentica	SAPI confermato, costruito e configurato con il collegamento Web effettivo per eliminare il reindirizzamento errato della cache
disponibilità aziendale	Le funzioni chiave come sessione, caricamento, importazione e gestione degli errori sono tornate normalmente.
Fine delle misure temporanee	Le configurazioni di memoria illimitata e di riciclaggio estremo dei lavoratori sono state ripristinate in base al piano di capacità o hanno un motivo chiaro per la conservazione
Prova del cambiamento	Registra la versione del pacchetto o il digest dell’immagine, l’ambito dell’aggiornamento, il tempo di completamento e i risultati della verifica

Quanto sopra sono suggerimenti per l’implementazione. Se è necessario verificare il comportamento di OOM, un’uscita anomala o patch personalizzate, è necessario utilizzare il test di regressione upstream o l’inserimento di errori controllati in un ambiente isolato per evitare di creare ripetutamente un esaurimento della memoria nell’ambiente di produzione come metodo di accettazione.

Controlla anche gli eventi PHP irreversibili, arresto anomalo del lavoratore, riavvio anomalo, percentuale di errori di richiesta ed eventi WAF prima e dopo l’aggiornamento. I log possono solo fornire indizi investigativi: la presenza di OOM non significa che sia stato sfruttato, e la mancanza di allarmi non dimostra che non sia avvenuto alcuno sfruttamento. L’aggiornamento risolve i percorsi di vulnerabilità che possono essere raggiunti in futuro; se vengono rilevate anomalie come la manomissione dei file o la perdita di credenziali, dovrebbero essere condotte indagini separate sugli incidenti.

Appendice: fonti e link citati

Tutti i collegamenti alle fonti sono raccolti di seguito. Gli avvisi, le patch e le indicazioni del fornitore riflettono i controlli a partire da O22 ottobre 2026; le distribuzioni successive dovrebbero verificare la presenza di aggiornamenti del fornitore. Le citazioni numerate nel testo si riferiscono a queste voci.

S1: bollettino ufficiale sulla sicurezza e versione di riparazione PHP

Fonte: Progetto PHP, 21 ottobre 2026.
Scopo: Ambito del rischio, quattro versioni di riparazione ufficiali, misure temporanee ufficiali e istruzioni di backport di emergenza per le vecchie filiali.
Riferimento: PHP 2026 This security bulletin è presente nell’archivio dei bollettini annuali

S2 — CVE-2026-109618 Bollettino tecnico ufficiale

Fonte: php/php-src GitHub Security Advisory, 21 ottobre 2026.
Identificazione: GHSA-w8hw-w9fx-j79w.
Scopo: limite di copertura per OOM, amplificazione in più parti, differenza e mitigazione SAPI.
Riferimento: RCE via OOM corruption

S3 — CVE-2026-109619 Bollettino tecnico ufficiale

Fonte: php/php-src GitHub Security Advisory, 21 ottobre 2026.
Identificazione: GHSA-6wmf-4rv5-p3rp.
Scopo: stato pendente di richieste incrociate, produttori e consumatori, inizializzazione anticipata, mitigazione della configurazione.
Riferimento: RCE via stale global state

S4: invio ufficiale della correzione PHP 8.5

Fonte: php/php-src.
Invia: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
Scopo: confermare l’invio formale per correggere due vulnerabilità contemporaneamente e spiegare la direzione generale del cambiamento.
Riferimento: Avoid state corruption via bailout

S5 — PHP 8.5 Restaurato ufficialmente e differenziale completo

Fonte: diversa dalla stessa presentazione ufficiale.
Scopo: verificare l’implementazione specifica dell’allocatore, VM, HTTP globals, sessione, serializzazione e ciclo di vita della richiesta.
Riferimento: official complete diff

S6: invio ufficiale del backport di emergenza PHP 8.1

Fonte: php/php-src.
Invia: 1d7dec178a094e6e75b229ce22754045f8c6070a.
Scopo: controllare l’uscita rapida dei vecchi rami e caricare le modifiche al comportamento di avanzamento.
Riferimento: PHP 8.1 Emergency backport submission
Riferimento: corresponds to complete diff

S7 - PHP 7.4 ramo backport di emergenza ufficiale

Fonte: rami del codice sorgente php/php-src, PHP elencati nel bollettino ufficiale sulla sicurezza.
Riferimento: PHP-7.4-CVE-2026-109618-109619

S8 - PHP 8.0 ramo backport di emergenza ufficiale

Fonte: rami del codice sorgente php/php-src, PHP elencati nel bollettino ufficiale sulla sicurezza.
Riferimento: PHP-8.0-CVE-2026-109618-109619

S9 - PHP 8.1 ramo backport di emergenza ufficiale

Fonte: rami del codice sorgente php/php-src, PHP elencati nel bollettino ufficiale sulla sicurezza.
Riferimento: PHP-8.1-CVE-2026-109618-109619

S10 — Ubuntu Bollettino di sicurezza USN-8948-1

Fonte: Canonical / Ubuntu, 21 ottobre 2026.
Scopo: rilasciare backport e completare esempi di versioni del pacchetto.
Riferimento: USN-8948-1: PHP vulnerabilities

S11 — PHP-FPM Configuration Manuale

Fonte: documento ufficiale PHP.
Scopo: semantica di configurazione come php_admin_value, php_admin_flag, pm.max_requests, ecc.
Riferimento: PHP-FPM Configuration

S12 — PHP Manuale di configurazione Core INI

Fonte: documento ufficiale PHP.
Scopo: definizione e ambito del corpo della richiesta, caricamento, memoria e configurazione di lettura automatica POST.
Riferimento: Description of core php.ini directives

S13 — Nginx richiedere il limite delle dimensioni del corpo

Fonte: documento ufficiale Nginx.
Scopo: Il significato di client_max_body_size e i livelli di configurazione disponibili.
Riferimento: ngx_http_core_module / client_max_body_size

S14: buffer di richiesta Nginx FastCGI

Fonte: documento ufficiale Nginx.
Scopo: la sequenza di elaborazione e la funzione di fastcgi_request_buffering.
Riferimento: ngx_http_fastcgi_module / fastcgi_request_buffering

S15 — Nginx Condizioni e istruzioni per la restituzione

Fonte: documento ufficiale Nginx.
Scopo: Sintassi di configurazione di if e return.
Riferimento: ngx_http_rewrite_module

S16 — Cloudflare PHP2Shell Istruzioni di protezione

Fonte: blog ufficiale Cloudflare.
Scopo: descrizione dell’ambito di distribuzione WAF, disposizione del piano Free e meccanismo di rilevamento.
Riferimento: Cloudflare deploys protections against php2shell vulnerability