Vulnerabilità NGINX: cause, soluzioni e verifica della produzione

Data articolo storico: 2026-10-14 (data di divulgazione e rilascio di sicurezza). Fonti controllate e informazioni integrate tramite 2026-10-27.

Questo articolo è archiviato per data dell’evento; gli aggiornamenti della versione e del rilascio rilasciati dopo il 14 ottobre sono inclusi di seguito. Destinatari: sito Web NGINX Open Source / NGINX Plus e personale operativo e di manutenzione del proxy inverso, personale di risposta alla sicurezza, manutentori della distribuzione, nonché ingegneri che compilano automaticamente NGINX e mantengono moduli di terze parti.

Questo articolo si concentra sulle cinque vulnerabilità principali NGINX che sono state divulgate e risolte in modo approfondito il 14 ottobre 2026 e ripercorre anche le vulnerabilità rappresentative della sicurezza della memoria e dell’integrità delle richieste da maggio a settembre 2026. Il contenuto copre condizioni di attivazione, cause a livello di codice, ambito dell’impatto, flusso di lavoro di riparazione, misure di mitigazione a breve termine, implementazione di patch ufficiali, backport ai rami più vecchi e verifica della produzione. Riferimenti come S1 si collegano all’appendice della fonte. Le configurazioni di esempio vengono utilizzate solo per illustrare le idee di distribuzione e controllo e devono essere verificate in base alla versione effettiva, all’ereditarietà della configurazione, alle dipendenze e alla capacità aziendale prima dell’implementazione.

TL;DR: azioni prioritarie

1. Dai priorità agli aggiornamenti di sicurezza. Per i pacchetti Open Source nginx.org, aggiornare il ramo Stable 1.30 almeno a 1.30.6 e il ramo Mainline 1.31 almeno a 1.31.7. Alla data di verifica, 1.31.8 è l’ultimo Sblocco Mainline. Queste sono linee di base del ramo separate; non confrontare i loro numeri tra i rami. S1S2
2. Verifica le installazioni della distribuzione in base alla versione del pacchetto completo. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 dispongono di backport del fornitore; Debian 13 (trixie) richiede almeno 1.26.3-3+deb13u10. Al momento della verifica, il pacchetto Debian 12 (bookworm) 1.22.1-9+deb12u10 è ancora contrassegnato come interessato. Controllare ogni CVE; l’avviso Debian 13 non stabilisce che Debian 12 sia corretto. S13S14S15
3. Controlla cinque combinazioni di configurazione: alias + rewrite + $request_filename, map + regex + valutazione variabile, aio + ssi + include virtual, HTTP/3 con proxy_request_buffering on e ssl_session_cache shared:... con rotazione automatica della chiave del ticket di sessione TLS. La sola presenza di una direttiva non stabilisce la sfruttabilità; valutare il percorso della richiesta e l’ambito della configurazione. S1S3S4
4. Sostituisci tutti i vecchi processi e contenitori. Esegui nginx -t, quindi riavvia il servizio o esegui una distribuzione in sequenza ad alta disponibilità. Confermare che i vecchi processi master/worker siano terminati; nginx -s reload da solo non dimostra che il codice binario in esecuzione sia cambiato.
5. Verifica gli endpoint effettivi: HTTP/1.1, HTTP/2, HTTP/3 se abilitato, caricamenti proxy e corpi delle richieste API, autenticazione del certificato mTLS, pagine SSI e log di accesso. Registra la provenienza, la versione, il digest dell’immagine, i processi in esecuzione e i risultati del pacchetto per ciascun endpoint.
6. Se un aggiornamento immediato è impossibile, rimuovere le condizioni di attivazione applicabili: disabilitare SSI/AIO o HTTP/3 non necessari, esaminare i riferimenti variabili alias/rewrite/map vulnerabili e valutare i riferimenti temporanei ssl_session_tickets off; interessati. Servizi mTLS. WAF, ASLR, i limiti di velocità e le modifiche alla configurazione coprono solo alcune condizioni e non possono sostituire le patch ufficiali. S3S4S8S12

1. Panoramica della vulnerabilità e giudizio sul rischio

NGINX ha rilasciato 1.30.6 (Stable) e 1.31.7 (Mainline) il 14 ottobre 2026, risolvendo cinque problemi di sicurezza. Tre riguardano overflow dell’heap o use-after-free e hanno ricevuto punteggi F5 CVSS v4.0 9.2 / Critico. Gli altri due influiscono sull’integrità della richiesta HTTP/3 e sull’autenticazione del certificato client TLS. S1S2S3

Distinguere i sistemi di classificazione: nginx.org elenca tutti e cinque i problemi come medium, mentre F5 CVSS v4.0 e alcune agenzie di sicurezza nazionali classificano i tre problemi di memoria come critici. Ciò non significa che tutti e cinque consentano l’esecuzione incondizionata di codice remoto. La configurazione, la raggiungibilità del traffico e le condizioni al di fuori del controllo di un utente malintenzionato sono importanti. Corruzione della memoria e RCE affidabile sono diversi livelli di prova. S1S3S4

CVE	Problemi tecnici e condizioni tipiche di attivazione	impatto fondamentale	Valutazione e smaltimento
CVE-2026-15176	alias mappatura percorso + rewrite modifica URI + valutazione $request_filename	Overflow del buffer heap, arresto anomalo di Worker; potenziale RCE in determinate condizioni	F5 CVSS v4.0 9.2; dare priorità alla risoluzione dei problemi
CVE-2026-93479	Valutazione dello script HTTP/Stream, in particolare acquisizione regex map e directory root, riferimento incrociato alle variabili di registro	Il buffer riservato viene sovrascritto e l’heap va in overflow; potenziale RCE in determinate condizioni	F5 CVSS v4.0 9.2; è un rischio di regressione dopo le riparazioni precedenti
CVE-2026-97205	SSI include virtuali e AIO/funzionamento asincrono; overflow del conteggio delle operazioni in sospeso	Use-After-Free, arresto anomalo Worker, danneggiamento della memoria; potenziale RCE	F5 CVSS v4.0 9.2; richiede una configurazione non predefinita
CVE-2026-95101	HTTP/3 Il frame sconosciuto è frammentato nei buffer, il buffering del corpo della richiesta proxy è abilitato	Inserimento errato di byte non DATA nel corpo della richiesta upstream, possibilmente ignorando il limite delle dimensioni del corpo della richiesta	Questa vulnerabilità influisce sull’integrità della richiesta. Di per sé non fornisce l’esecuzione di codice remoto (RCE).
CVE-2026-97629	Cache di sessione TLS condivisa, rotazione automatica delle chiavi e mirroring delle chiavi Worker	Falsificazione del ticket di sessione; Potrebbe verificarsi un bypass dell’autenticazione del certificato client per il servizio mTLS interessato	È necessario prestare particolare attenzione all’impatto aziendale del tipo di autenticazione del certificato API

Il punteggio CVSS sopra riportato è dato da F5 utilizzando v4.0; la stessa vulnerabilità può mostrare una gravità diversa nei gradi propri di CVSS, 3.1 e nginx.org e nei livelli di gravità della distribuzione. S1S3S4

1.1 Dai priorità all’esposizione alla distribuzione piuttosto che ai soli punteggi CVE

Modulo di distribuzione	Punti chiave dell’indagine	Raccomandazioni sulle priorità di smaltimento
Proxy inverso della rete pubblica, inclusi rewrite personalizzato, alias e map complesso	CVE-2026-15176, CVE-2026-93479 e vulnerabilità di riscrittura/mappatura da maggio a luglio	P0: verifica e aggiornamento immediato
API / Piano di gestione che utilizza il certificato cliente come autenticazione unica o principale dell’ingresso	Ticket di sessione e configurazione della cache condivisa di CVE-2026-97629	P0: conferma immediatamente il limite di autenticazione e aggiorna
Fornire caricamento HTTP/3 esterno, interfaccia di modifica dello stato, classe di transazione API	CVE-2026-95101, in particolare il corpo della richiesta viene proxy al backend	P0/P1: organizzare in base all’importanza aziendale
SSI Pagina dinamica o I/O file asincrono	CVE-2026-97205	P1: Confermare le condizioni di combinazione e riparare il prima possibile
Solo pagine statiche + proxy inverso semplice HTTP/1.1/2	La configurazione e la versione devono ancora essere controllate, ma alcune condizioni CVE potrebbero mancare	P1: Incluso nella finestra di aggiornamento della sicurezza di emergenza
Utilizza la comunità Kubernetes ritirata ingress-nginx	Il progetto interrompe il mantenimento della sicurezza e i rischi non si limitano a questi cinque CVE	Crea un piano di migrazione del controller individuale

P0/P1 sono i suggerimenti per lo smaltimento, il funzionamento e la manutenzione forniti in questo articolo per l’esposizione alla rete pubblica e la sensibilità della certificazione. Non si tratta di una classificazione ufficiale CVSS, né dovrebbe sostituire l’asset interno dell’impresa e modificare la valutazione del rischio.

1.2 Limite di impatto e autorizzazioni di attacco

Le principali vulnerabilità di questo batch si trovano principalmente nel Data Plane NGINX: il punto di ingresso dell’attacco è la connessione e la richiesta del client e l’impatto effettivo di solito si verifica nel processo Worker. Se vengono soddisfatte le condizioni sfruttabili per la corruzione della memoria, l’autorizzazione all’esecuzione del codice è generalmente limitata dall’utente in esecuzione, dai vincoli del contenitore, dalla funzionalità Linux, dal montaggio e dalle autorizzazioni di rete di Worker; il potenziale RCE non implica automaticamente i privilegi root o la compromissione dell’host. S4

Ma anche se il processo non è privilegiato, potrebbe comunque avere accesso a credenziali proxy, file leggibili contenenti chiavi private del certificato, token di servizio upstream, file temporanei, API interno e reti raggiungibili. Per mTLS, il bypass dell’autenticazione stesso può rappresentare una grave conseguenza aziendale e non deve necessariamente essere accompagnato dall’esecuzione di codice.

2. Analisi delle cause

2.1 Comprendere i tre limiti soggetti a errori in NGINX

Un NGINX worker è un processo di lunga durata, basato sugli eventi, che mantiene lo stato della richiesta, le operazioni asincrone e i parser di protocollo. Questa vulnerabilità incorpora vincoli a tre livelli tecnici:

1. la valutazione della variabile e la dimensione della memoria devono essere coerenti: rewrite Dopo aver modificato la richiesta URI, la mappatura del percorso deve essere coerente con lo location attualmente effettivo; quando l’interprete dello script calcola la lunghezza variabile, lo spazio di scrittura deve coprire l’output effettivo e le aree riservate.
2. Le operazioni asincrone devono estendere il ciclo di vita della memoria richiesta: in caso di lettura e scrittura di file non completate, attesa della cache o attività di thread, il relativo pool di memoria della richiesta non può essere rilasciato in anticipo.
3. lo stato del protocollo e lo stato di sicurezza non possono essere mischiati o omessi: HTTP/3 La lunghezza del salto del frame sconosciuto non può essere considerata come la lunghezza del corpo della richiesta DATA; TLS Tutti gli slot chiave che partecipano alla verifica della firma devono essere inizializzati e sincronizzati correttamente durante la rotazione del ticket di sessione.

Il contenuto seguente si basa sul commit della correzione upstream NGINX e sull’annuncio del fornitore per spiegare il meccanismo di errore che può essere attivato; il frammento di esempio serve per l’analisi, non è il codice completo che può essere utilizzato direttamente per riparare l’ambiente di produzione. S5S6S7S8S9

2.2 CVE-2026-15176: la mappatura del percorso tra alias e URI riscritto non è valida.

In NGINX, lo location corrispondente e il suo alias determinano il percorso del file; rewrite può modificare la richiesta corrente URI. Dopo la riscrittura, i presupposti utilizzati dalla mappatura location originale potrebbero non essere più validi.

Il percorso di elaborazione interessato non ha verificato adeguatamente se la richiesta era stata riscritta durante il controllo dello stato alias in ngx_http_map_uri_to_path(). Quando la configurazione continua a valutare $request_filename dopo la riscrittura, il percorso potrebbe essere costruito con presupposti non conformi allo stato corrente di URI, attivando infine una scrittura fuori dai limiti nella memoria heap. S5

Combinazione tipica (utilizzata solo come controesempio per il controllo della configurazione, la distribuzione non è consigliata):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

Il pericolo non si limita a return: anche set, if, add_header, log_format, ecc. devono essere controllati se la valutazione $request_filename viene attivata nello stesso processo di richiesta. return nell’esempio rende solo questo percorso di stato facile da vedere, non può essere utilizzato per dedurre che tutte le configurazioni di produzione produrranno overflow. S5S10

Conseguenze dell’attacco: la costruzione di una richiesta può causare il riavvio di Worker o l’interruzione del servizio; in condizioni come ASLR chiuso o bypassabile, esiste un potenziale RCE. Il nocciolo della patch upstream è rifiutarsi di completare la mappatura del percorso URI riscritta nel contesto alias che non è più valido, piuttosto che espandere semplicemente un determinato buffer. S5S10

2.3 CVE-2026-93479: mancata corrispondenza tra “spazio riservato” e lunghezza variabile reale nella valutazione dello script

I moduli HTTP e Stream di NGINX dispongono di analizzatori di script che concatenano stringhe letterali e valori variabili nella stringa del risultato. Esempi di applicazioni includono percorsi di documenti HTTP root, percorsi di log di accesso ed espressioni variabili in Stream.

Alcune configurazioni di map + espressioni regolari consentono la lettura dei valori acquisiti da altre espressioni prima che la variabile risultato map venga valutata. Combinata con il metodo di esecuzione dello script con lunghezza riservata, la vecchia implementazione conterà in anticipo lo spazio riservato len nell’accumulatore della lunghezza valutata, in modo che i successivi calcoli del puntatore di scrittura non siano più coerenti con il limite del buffer. In una specifica sequenza di valutazione delle variabili, le successive scritture di stringhe potrebbero sovrascrivere l’area riservata, causando un overflow dell’heap. S6

elementi partecipativi	Perché vale la pena prestare attenzione
espressione regolare in map	La valutazione delle variabili di acquisizione può avere un ciclo di vita e un comportamento di memorizzazione nella cache indipendenti
Acquisizioni anonime come $1, $2, ecc.	Facilmente sovrascritto da altre espressioni regolari o espressioni, rendendo difficile tracciarne la proprietà
Variabili in root	Esecuzione dello script e prenotazione del buffer durante l’attivazione della creazione del percorso
log_format/Percorso registro dinamico	Lo stesso tipo di valutazione potrà essere attivato successivamente nella richiesta
Espressioni di script in stream	La correzione upstream modifica anche ngx_stream_script_run(). Non puoi solo rivedere il modulo HTTP.

Importante relazione di regressione: il codice relativo a questa vulnerabilità è correlato alle modifiche precedenti che hanno corretto CVE-2026-42533. Il DSA ufficiale per Debian 13 afferma chiaramente che il codice interessato è stato introdotto nel pacchetto trixie tramite un precedente backport di sicurezza. Pertanto, “la patch di vulnerabilità map di luglio è stata installata” non significa che la CVE-2026-93479 di ottobre sia stata coperta; è necessario controllare l’intera catena di soluzioni di sicurezza. S6S14S17

Il potenziale rischio RCE qui è legato all’ambiente di protezione della memoria e non si dovrebbe affermare che la sola regex map potrà essere sfruttata da aggressori anonimi. S11

2.4 CVE-2026-97205: AIO Il conteggio delle operazioni non completate causa il wraparound Use-After-Free

Questa vulnerabilità non è semplicemente “accendi SSI e otterrai UAF”. La chiave sta nel conteggio dei riferimenti all’operazione asincrona detenuti dalla richiesta principale.

NGINX Utilizzare r->main->blocked per tenere traccia dell’elaborazione asincrona che non è stata ancora completata, nella vecchia implementazione era un conteggio a 8 bit; alcuni percorsi non hanno eseguito un controllo del limite superiore prima di incrementare il conteggio. Quando la stessa richiesta principale accumula 256 operazioni in sospeso, il conteggio può variare da 255 a 0. I processi successivi crederanno erroneamente che non vi sia alcuna operazione asincrona che impedisca il rilascio della richiesta, rilasciando così il pool di memoria della richiesta a cui fa ancora riferimento l’attività. S7

Il processo di fallimento può essere suddiviso in:

1. Con il percorso I/O/thread asincrono associato abilitato, la pagina SSI introduce più sottorichieste o operazioni di lettura tramite include virtual.
2. Le operazioni in sospeso di una determinata richiesta principale vengono accumulate fino al limite superiore rappresentato dal campo conteggio.
3. Il conteggio a 8 bit va a capo, espresso erroneamente come “nessuna operazione in sospeso”.
4. Il pool di memoria della richiesta viene rilasciato, mentre le letture di file, le attese della cache o i callback delle attività del thread mantengono ancora i riferimenti ad esso.
5. I successivi callback di completamento asincrono accedono alla memoria rilasciata, provocando arresti anomali di UAF, Worker o potenziale danneggiamento della memoria.

La correzione ufficiale aggiunge NGX_HTTP_MAX_BLOCKED 250 al file di intestazione della richiesta e aggiunge restrizioni al filtro di output, alla lettura della cache e al percorso del thread upstream; quando viene raggiunta la soglia, le operazioni con percorsi sincronizzati vengono completate in modo sincrono e, se non possono essere elaborate in sicurezza, l’ulteriore aggiunta di attività pendenti verrà rifiutata. S7

Giudizio di applicabilità: Va valutato se SSI, AIO, inclusione virtuale, sottorichieste e relative operazioni asincrone possono verificarsi in combinazione nella stessa catena di richieste. Di solito queste non sono le configurazioni proxy statiche semplici predefinite. aio off; o ssi off; possono rimuovere specifici elementi di attivazione, ma le dipendenze delle funzioni aziendali devono essere prima confermate. S4S7S25

2.5 CVE-2026-95101: il frame sconosciuto HTTP/3 viene confuso con lo stato del corpo della richiesta DATA

Il parser di frame HTTP/3 deve distinguere tra frame DATA (che devono essere passati all’elaborazione del corpo della richiesta HTTP) e frame sconosciuti che devono essere ignorati. Anche la lunghezza dei frame sconosciuti deve essere preservata accuratamente durante la frammentazione nei buffer di rete.

La vecchia implementazione di ngx_http_v3_parse_data() utilizzava il campo st->length per salvare il “numero rimanente di byte da saltare” quando si saltavano frame sconosciuti, mentre il filtro del corpo della richiesta interpretava lo stesso campo come “lunghezza rimanente del payload DATA”. Se il frame sconosciuto si estende su più chiamate di analisi, il batch di byte successivo dopo l’interruzione dell’analisi potrebbe essere erroneamente considerato parte del corpo della richiesta. S8

Si presentano due tipi di rischi:

• request body injection: il payload del frame non DATA inviato dal client può essere trasmesso all’applicazione upstream, modificando i dati effettivamente ricevuti dal backend.
• bypass del limite di dimensione: client_max_body_size e altre restrizioni. I controlli previsti sono concentrati sul percorso DATA e il contenuto convertito in modo errato potrebbe ignorare la verifica corrispondente.

Il tipico scenario di attivazione descritto dal funzionario è quando ngx_http_v3_module riceve la richiesta HTTP/3 e inoltra proxy_request_buffering on. Il buffering del corpo della richiesta proxy è abilitato per impostazione predefinita in ngx_http_proxy_module. Pertanto, è necessario controllare prima il proxy inverso che attiva HTTP/3. Non è appropriato presupporre che non vi sia alcuna condizione di trigger solo perché proxy_request_buffering on; non è scritto esplicitamente. S8S18

La conseguenza diretta di questa vulnerabilità appartiene all’integrità della richiesta di backend e alla modifica dei limiti di sicurezza, che non è l’espressione equivalente di RCE completata direttamente nel core NGINX. L’impatto finale sull’azienda dipende dal modo in cui questi byte vengono analizzati e considerati attendibili a monte. S24

2.6 CVE-2026-97629: TLS La rotazione del ticket manca il terzo slot chiave

Nelle configurazioni interessate, NGINX può generare e ruotare automaticamente le chiavi del ticket di sessione TLS tramite la cache di memoria condivisa, consentendo a più Worker di elaborare lo stesso batch di ticket.

La relativa logica di sincronizzazione alloca 3 slot chiave per ciascuno Worker e anche la richiamata di decrittografia attraverserà questi slot; ma la vecchia implementazione copia ogni volta solo 2 slot chiave dalla memoria condivisa, ottenendo il nome della chiave, la chiave HMAC e l’AES del terzo slot. La chiave potrebbe rimanere non inizializzata. Se l’identificatore della chiave di un ticket corrisponde a questo stato, il materiale della chiave non inizializzata può essere utilizzato per la verifica e la decrittografia della firma, formando così un percorso per falsificare la sessione TLS. S9

Le combinazioni di distribuzione ad alto rischio sono in genere:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

La conseguenza aziendale più grave di questa vulnerabilità è che sui servizi che utilizzano l’autenticazione del certificato client (mTLS) in ssl_verify_client on; e in altri modi, le sessioni di ripristino contraffatte potrebbero ignorare la verifica del certificato client. Anche il successo dell’attacco è soggetto a condizioni incontrollabili; un sito che utilizza solo un normale certificato HTTPS lato server e nessuna autenticazione tramite certificato client non deve essere descritto in modo errato come “l’aggressore può ignorare l’intero accesso al sito Web”. S9S12

Si tratta di un problema relativo allo stato di autenticazione della sessione TLS e non ha nulla a che fare con il fatto che la chiave privata TLS del server sia violata o che il certificato pubblico CA root sia interessato. S24

2.7 Come comprendere DoS, RCE, bypass dell’autenticazione ed exploit noti

• DoS: l’errore di memoria causa l’arresto anomalo o il riavvio massiccio di Worker. L’eventuale indisponibilità complessiva è correlata alla pressione del traffico, alla capacità di riavvio del processo, al tempo di manutenzione della connessione e all’architettura ad alta disponibilità.
• potenziale RCE: alcuni annunci indicano che esiste la possibilità di esecuzione del codice quando ASLR viene chiuso o bypassato. Ciò non significa che sia stata svelata una catena di attacco pubblica in grado di eseguire comandi in modo stabile e universale. S4
• Richiedi bypass di iniezione/autenticazione: può modificare direttamente lo stato aziendale protetto o richiedere contenuto e non può essere ignorato solo perché non ottiene direttamente la shell.
• ha scoperto tentativi di attacco: CVE-2026-42945 nel maggio 2026 ha segnalazioni di attività di sfruttamento in natura; non si dovrebbe dedurre direttamente da questo fatto storico che tutti e cinque i CVE di ottobre siano stati sfruttati con successo su larga scala. S23

3. Ripara la versione e la selezione della patch

Base ufficiale della patch 3.1 NGINX Open Source

ramo a monte	La prima versione ufficiale che copre cinque vulnerabilità in ottobre	Raccomandazioni a partire da 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Installa almeno 1.30.6 e segui le versioni di sicurezza successive.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
Il ramo precedente NGINX Open Source	Non può essere giudicato esclusivamente sulla base del fatto che “sono state applicate vecchie patch di vulnerabilità”	Migrare prima al ramo mantenuto; in caso contrario, il venditore è tenuto a fornire prova formale della garanzia su base CVE-by-CVE.

Queste sono le conclusioni della versione del codice sorgente/ramo ufficiale upstream nginx.org e non dovrebbero essere utilizzate per negare direttamente il pacchetto di sicurezza con correzioni backport fornite dal fornitore della distribuzione. Anche se il valore di 1.31.6 è maggiore di 1.30.6, è comunque inferiore alla linea di base della patch del ramo della linea principale. S1S2

3.2 L’ambito dell’impatto a monte di cinque CVE

I seguenti intervalli sono elencati in base al testo originale del bollettino sulla sicurezza nginx.org e devono essere compresi insieme al “ramo in esecuzione corrente” e al “percorso di configurazione effettivo”:

CVE	Versioni interessate dai tag upstream	Versione fissa ufficialmente etichettata
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ o 1.31.7+, all’interno delle rispettive filiali
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	Come sopra
CVE-2026-97205	0.8.11–1.31.6	Come sopra
CVE-2026-95101	1.25.0–1.31.6	Come sopra
CVE-2026-97629	1.23.2–1.31.6	Come sopra

CVE-2026-93479 ha limiti specifici della versione di introduzione; non tutte le vecchie versioni NGINX sono interessate da questa regressione. Le versioni precedenti al di fuori di questi intervalli potrebbero essere ancora interessate dalla precedente vulnerabilità regex map CVE-2026-42533. S1

3.3 Ubuntu: backport di distribuzione (USN-8955-1)

Canonical USN-8955-1 del 26 ottobre 2026 fornisce un aggiornamento di sicurezza per quattro build Ubuntu: S13

Versione Ubuntu	nginx e la stessa versione fissa del pacchetto sorgente	Descrizione
22.04 LTS	1.18.0-6ubuntu14.22	È un backport del fornitore; il numero della versione upstream mostra ancora 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	Come sopra
26.04 LTS	1.28.3-2ubuntu1.12	Come sopra
26.10	1.30.4-7ubuntu1.1	Come sopra

L’annuncio contiene versioni fisse corrispondenti di pacchetti omologhi come nginx-core, nginx-extras, nginx-full e nginx-light. Non trarre conclusioni sull’opportunità di risolverlo dalla parte a monte mostrata solo da nginx -v. come Ubuntu 24.04 e 1.24.0-2ubuntu7.19 sono stati aggiornati da questo fornitore, ma 1.24.0 da qualsiasi fonte non è intrinsecamente sicuro.

Ubuntu ha anche ufficialmente indicato chiaramente che CVE-2026-95101 influisce solo su Ubuntu 26.04 / 26.10 e CVE-2026-97629 influisce solo su Ubuntu 24.04 / 26.04 /26.10. Ecco la confezione e l’ambito funzionale di Ubuntu, che non può essere promosso direttamente ad altre distribuzioni. S13

3.4 Debian: Le differenze tra le versioni devono essere verificate separatamente

L’avviso Debian DSA-6575-1 (2026-10-21) copre questi cinque CVE e identifica il pacchetto nginx fisso per Debian 13 / trixie come:

1.26.3-3+deb13u10

Tuttavia, al momento della verifica di questo rapporto, 1.22.1-9+deb12u10 per Debian 12 / bookworm è ancora contrassegnato come vulnerabile dal Debian Security Tracker. Pertanto:

• Debian 13 Basta aggiornare e accettare secondo DSA-6575-1.
• Debian 12 deve verificare le correzioni di sicurezza fornite dall’attuale Security Tracker o dal fornitore ELTS uno per uno; prima che la correzione venga confermata nell’annuncio, non dichiarare che tutti e cinque gli elementi sono stati corretti in base al successo di apt upgrade.
• Il pacchetto sorgente Debian può contenere un set di patch indipendente dal numero di versione nginx.org. Per le build personalizzate, è necessario controllare il set completo di correzioni del pacchetto del codice sorgente e non è possibile copiare semplicemente un singolo commit upstream e considerarlo completo.

La distinzione di cui sopra si basa sui record di tracciabilità DSA e CVE. S14S15S16

3.5 NGINX Plus, njs e controller di ingresso

Prodotti/Componenti	Punti chiave di selezione e verifica dei titoli
NGINX Plus (versione commerciale)	Si prega di fare riferimento all’annuncio e alle istruzioni di aggiornamento del ramo Plus corrispondente a F5. L’ultima CR al momento della verifica è PLS.37.2.0.1 e la build di sicurezza di LTS è PLS.37.0.7.1; la versione Plus e il backport incluso non possono essere sostituiti direttamente dalla soglia 1.30/1.31 di Open Source. S19
njs/ngx_http_js_module	2026-10-14 rilascia njs 1.0.2 e corregge CVE-2026-101019 e CVE-2026-101025; se si utilizza njs è necessario verificare anche la compatibilità del modulo con NGINX. S20
F5 NGINX Controller di ingresso/struttura gateway	Il core NGINX è una catena di distribuzione software correlata ma indipendente. Risolvi le vulnerabilità rilevanti con i rispettivi controller, immagini e note di rilascio. Non puoi semplicemente sostituire un file binario NGINX nel Pod.
Kubernetes Comunità kubernetes/ingress-nginx	Il progetto verrà disattivato nel marzo 2026 e non prevederà più nuovi interventi di manutenzione della sicurezza. È necessario pianificare la migrazione a un controller gestito o Gateway API anziché confondere il numero di versione con il controller di ingresso F5 NGINX. S21

3.6 Quale patch dovresti effettivamente scegliere?

Modulo di distribuzione	Pratiche consigliate	Prova di riparazione
Pacchetto DEB/RPM ufficiale nginx.org	Aggiorna alla versione fissa del ramo upstream	nginx -v/-V, fonte del pacchetto, annuncio ufficiale di sicurezza
Archivio ufficiale Ubuntu/Debian	Installa i pacchetti di sicurezza del fornitore	Versione pacchetto completo + USN/DSA del fornitore + stato CVE
RHEL/Alma/Rocky/SUSE/Altre distribuzioni	Aggiornamento in base ai bollettini sulla sicurezza della distribuzione e alle versioni dei pacchetti specifici	CSAF/annuncio del fornitore corrispondente, la versione Ubuntu/Debian non può essere applicata
Immagini del contenitore ufficiali o personalizzate	Ricostruisci o estrai l’immagine di riparazione verificata e sostituiscila periodicamente	Digest immagine, build SBOM, esecuzione dell’ID immagine pod/contenitore
NGINX, OpenResty, Tengine autocompilati o versioni patchate con moduli di terze parti	Dare priorità all’uso della versione di sicurezza completa del manutentore; eseguire backport di patch revisionati per l’albero di origine di destinazione quando necessario	Cinque correzioni di vulnerabilità, compatibilità ABI/modulo, regressione di unità e business

OpenResty e Tengine sono sistemi di sgancio diversi; questa tabella descrive solo il metodo di verifica. non significa che tutte le sue versioni siano interessate contemporaneamente allo standard NGINX, né la patch del codice upstream può essere applicata incondizionatamente.

4. Processo di riparazione formale

4.1 Inventario delle istanze effettive di ricezione del traffico esterno

Raccogliere per ciascuna voce almeno:

• Nome di dominio, collegamento bilanciamento del carico/CDN/edge proxy, metodo di esposizione del sito di origine e protocollo di rete utilizzato.
• Prodotti NGINX (Open Source, Plus, Ingress, ecc.), versione completa, sorgente del repository di pacchetti, digest di immagini.
• nginx -V visualizza i moduli edilizi ed i parametri di compilazione; se sono presenti moduli njs, Lua, OpenResty e moduli dinamici di terze parti.
• PID master/worker in esecuzione reale, unità di servizio/contenitore/pod, replica e nodo Worker.
• Le effettive configurazioni http/stream, server, location, include.
• Se abilitare HTTP/3, mTLS, SSI/AIO, percorso di registro dinamico, map complesso e acquisizione regex.

Non limitarti a controllare il valore predefinito /etc/nginx/nginx.conf. L’ambiente di produzione spesso carica più siti, TLS e configurazioni di moduli tramite include. Potrebbero inoltre essere presenti più percorsi di installazione NGINX o più livelli proxy.

4.2 Controllare la versione e le informazioni sulla compilazione

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V riporta la build del binario trovato nel percorso della riga di comando; non dimostra che lo worker in esecuzione lo abbia caricato. nginx -v potrebbe omettere il suffisso completo del pacchetto della distribuzione, quindi controlla anche il gestore dei pacchetti o i record della catena di fornitura.

4.3 Esporta la configurazione effettiva ed esegui il primo giro di screening statico

nginx -T testerà la configurazione e scaricherà la configurazione unita. L’output può contenere informazioni sensibili come credenziali di autenticazione, percorsi chiave, nomi host interni, ecc. Si consiglia di salvare il terminale controllato con autorizzazioni root e autorizzazioni per file privati e non pubblicare i file originali su ordini di lavoro pubblici:

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

Questo è solo il localizzatore del percorso del candidato, non uno strumento affidabile di determinazione automatica CVE:

1. grep non può determinare se le variabili si trovano nello stesso location o nella stessa catena di valutazione delle richieste, né può dedurre la relazione di ereditarietà della configurazione.
2. proxy_request_buffering on, alcune configurazioni di cache e ticket hanno valori predefiniti e non scrivere le istruzioni corrispondenti non significa che il rischio scompare.
3. Le configurazioni generate da proxy inversi, CDN, sidecar di contenitori o controller possono differire dai file ispezionati manualmente.
4. Potrebbe essere necessario confermare le caratteristiche di NGINX Plus e dei moduli dinamici utilizzando i rispettivi strumenti di gestione ufficiali.

4.4 Distribuire la correzione tramite canali attendibili

Debian/Ubuntu (repository di distribuzione ufficiale):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

Questo insieme di comandi non può generare dal nulla soluzioni di sicurezza che non sono ancora disponibili. Soprattutto per Debian 12, se il pacchetto aggiornato è ancora ritenuto vulnerabile dal sistema di monitoraggio della sicurezza, sono necessarie ulteriori misure di riparazione, isolamento o migrazione da parte del fornitore. S13S14S15

Pacchetto ufficiale nginx.org:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

Se si utilizza OpenResty, Tengine o NGINX Plus autocompilato, utilizzare la versione di correzione supportata dal manutentore corrispondente e non mescolare nginx.org, distribuzione e pacchetti di repository di terze parti. I file binari/immagini, le configurazioni, le firme e i manifesti di distribuzione di rollback originali devono essere conservati.

Containers/Kubernetes: aggiorna l’immagine immutabile, registra il suo digest e sostituisci tutte le vecchie repliche con un’implementazione graduale. kubectl rollout status conferma solo che il controller di distribuzione è terminato; verificare inoltre i digest delle immagini, il routing in ingresso e le repliche non integre.

4.5 Verifica configurazione e sostituisci vecchio Worker

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

Non considerare nginx -s reload come prova che un nuovo binario è in esecuzione: i normali ricaricamenti della configurazione consentono al vecchio master di avviare nuovi lavoratori senza sostituire il suo eseguibile. NGINX supporta una procedura di aggiornamento binario online dedicata, ma richiede passaggi e verifiche aggiuntivi. Senza una procedura stabilita, utilizzare uno switch del traffico ad alta disponibilità seguito da un riavvio del servizio o implementare contenitori sostitutivi. S22

Se gestisci NGINX tramite il socket systemd, lo script della voce contenitore o più installazioni, dovresti controllare la destinazione di lancio effettiva e il percorso del processo invece di dare per scontato direttamente che systemctl restart nginx copra tutte le istanze.

4.6 Accetta e fai regressione aziendale dal vero ingresso esterno

Si consiglia di eseguire almeno:

• Il normale HTTPS, i percorsi riscritti, le risorse statiche e le pagine di mappatura alias sono corretti.
• La distribuzione regolare map, il percorso variabile root, il percorso del registro di accesso, il routing SNI/certificato e il proxy Stream sono corretti.
• I caricamenti normali, i caricamenti in blocchi, le richieste API e i limiti di volume upstream per HTTP/3 (se abilitati) sono ancora come previsti.
• mTLS: le richieste di certificato legittime dovrebbero avere esito positivo; i certificati mancanti, scaduti o non autorizzati devono comunque essere rifiutati e la ripresa/riconnessione di TLS non deve modificare accidentalmente le autorizzazioni.
• Se la pagina SSI e l’accesso asincrono ai file sono normali; il registro degli errori non mostra richieste anomale di riferimenti alla memoria o arresti anomali ripetuti di Worker.
• Dopo il cambio di traffico, il processo della vecchia versione e la vecchia replica dell’immagine dovrebbero essere terminati.

I test devono essere condotti in un ambiente proprio o autorizzato. Il normale test del fumo delle richieste non può da solo dimostrare che la vulnerabilità della memoria è stata risolta; alla fine, la versione fissa del fornitore, la patch del codice sorgente e il test di runtime devono essere accettati congiuntamente per l’accettazione.

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

Questa sezione è un’opzione di riduzione del rischio, non una sostituzione della patch. È necessario eseguire il backup di tutte le modifiche temporanee alla configurazione, eseguirle nginx -t, rilasciarle in batch e ripristinarle rapidamente se necessario. S3S4

5.1 Controlla la priorità del traffico in base all’esposizione esterna

Dare priorità alla riduzione della superficie di attacco dei servizi che non possono essere aggiornati in tempo: sulla superficie di gestione e interna API Aggiungere il controllo degli accessi all’origine attendibile, l’isolamento della rete upstream o offline a breve termine; aggiungere connessione, ente di richiesta e limiti tariffari agli ingressi a rischio; garantire che l’autenticazione dell’origine avvenga nel punto NGINX correlato alla voce prima della catena di elaborazione della richiesta. Va notato che la maggior parte delle vulnerabilità stesse si trovano in NGINX All’interno del piano dati, le tradizionali regole WAF potrebbero non determinare con precisione le condizioni di attivazione della configurazione personalizzata.

5.2 alias / rewrite: evitare di valutare $request_filename dopo la riscrittura

Si consiglia di controllare e regolare:

• Cerca di non eseguire rewrite che cambierà URI contemporaneamente a location utilizzando alias.
• Evitare di utilizzare $request_filename quando URI è stato riscritto ma la corrispondenza della posizione corretta non è stata ancora completata.
• Controlla i riferimenti alle variabili indirette in return, set, if, add_header, il formato del registro di accesso e i file di inclusione.
• Utilizzare root/try_files trasparente/location indipendente quando l’azienda lo consente, ma modifica solo alias in root. Potrebbe anche modificare la semantica del percorso del file, che deve essere verificata una per una.

Non copiare direttamente il comune “modello di riscrittura sicura” su Internet per sovrascrivere la configurazione esistente. Diversi prefissi location e destinazioni di riscrittura determinano una giunzione del percorso con significati completamente diversi. S5

5.3 map/Regex: riduce la miscelazione dello stato variabile di acquisizione

Si consiglia di dare priorità alle acquisizioni denominate e limitarne l’ambito di propagazione, anziché consentire il riutilizzo nel tempo di acquisizioni anonime come $1 in diversi percorsi di valutazione regex. Ad esempio:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

Questo frammento dimostra solo una struttura di proprietà variabile più facile da controllare; non significa che è stato dimostrato che elimina in modo indipendente tutti i percorsi di trigger CVE-2026-93479. In particolare, verificare se alle variabili di acquisizione viene fatto riferimento in anticipo da altri root o log_format e se sono presenti volatile, percorsi dinamici e catene di valutazione interdipendenti. F5/CERT consiglia di utilizzare l’acquisizione denominata e di limitare l’ambito di utilizzo alla corrispondente configurazione di corrispondenza regolare come sollievo a breve termine. S3S6

5.4 AIO + SSI: disattiva le combinazioni di funzioni non necessarie

Per server/percorsi che non richiedono SSI o I/O di file asincrono, utilizzare:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

Dal punto di vista delle condizioni di attivazione della vulnerabilità, la chiusura di una delle due è solitamente sufficiente per rimuovere la specifica catena descritta; la chiusura contemporanea è applicabile solo agli scenari in cui l’azienda non fa affidamento su questa capacità. Controllare include virtual, richieste secondarie, cache e comportamento del pool di thread; quando il carico del proxy inverso è elevato, lo spegnimento di AIO può modificare la latenza e le prestazioni I/O. S7

5.5 HTTP/3 Richiesta iniezione corporea: chiudere temporaneamente l’ingresso se necessario

Disabilita il listener quic che coinvolge HTTP/3, annulla l’intestazione di risposta Alt-Svc che annuncia HTTP/3 e controlla se l’edge layer/bilanciatore del carico invia ancora richieste QUIC direttamente allo NGINX non riparato:

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

Quanto sopra è solo una descrizione della differenza di modifica, non una configurazione completa del server che può essere abilitata individualmente. La sintassi di impostazione di HTTP/2 è correlata alla versione NGINX; se è necessario conservare HTTP/2, è necessario utilizzare http2 on; o la sintassi valida esistente in base alla versione corrispondente e verificare con nginx -t. deve essere unito alla configurazione del server esistente prima della distribuzione, invece di sostituire l’intera sezione con questa sezione. controlla anche il firewall UDP 443, la posizione di terminazione HTTP/3 e il percorso di fallback del client di CDN/proxy anteriore.

Un altro tipo di mitigazione a breve termine consiste nell’utilizzare proxy_request_buffering off; sul percorso proxy interessato, ma ciò modificherà il comportamento dello streaming del corpo della richiesta upstream, dei tentativi di errore e di alcuni flussi di lavoro di caricamento; essere utilizzato solo dopo test sufficienti e conferma che la direttiva raggiunga il percorso proxy HTTP/3 interessato. S8S18

5.6 TLS Ticket di sessione: Protezione priorità mTLS Limite di autenticazione

Se l’aggiornamento non è possibile e l’istanza si basa sulla cache della sessione condivisa + rotazione automatica della chiave del ticket, valutare:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

Ciò può disattivare il meccanismo del ticket di sessione TLS, rimuovendo così il percorso di falsificazione del ticket descritto in questa vulnerabilità; tuttavia, potrebbe influire sulle prestazioni di ripresa della sessione. Non è possibile disattivare semplicemente la verifica del certificato client mTLS per “evitare le vulnerabilità”, poiché ciò eliminerà direttamente il limite di autenticazione originale. S9S12

I file ssl_session_ticket_key espliciti e la rotazione sicura possono essere utilizzati anche dai processi di gestione professionali TLS per aggirare le condizioni generate automaticamente, ma la custodia delle chiavi, la distribuzione dell’intero nodo, la rotazione e i cicli di vita dei vecchi ticket devono essere tutti attentamente controllati. Non è consigliabile codificare una chiave riutilizzabile a lungo termine nella normale configurazione Web o negli script per le emergenze temporanee. I servizi critici che utilizzano mTLS devono inoltre essere monitorati per il comportamento di ripresa della sessione TLS e il rifiuto delle richieste senza un certificato client valido. S12

5.7 Il ruolo del sistema operativo e la protezione delle frontiere

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, lavoratori non root, file system contenitori di sola lettura, autorizzazioni minime sui file e isolamento della rete possono ridurre l’impatto del potenziale RCE. ASLR non risolve gli overflow dell’heap o UAF e non può garantire che i lavoratori non si blocchino. WAF, i limiti di tariffa e i limiti di dimensione corporea della richiesta non risolvono la sincronizzazione della chiave del ticket TLS. S4

5.8 Malinteso comune: Queste operazioni non sono sufficienti per completare la riparazione

Operazioni comuni	Perché è insufficiente?
“nginx -v sembra relativamente nuovo”	Il ramo a cui appartiene, la versione completa del pacchetto backport della versione di rilascio e il processo online non vengono controllati.
“Solo una delle intranet è stata aggiornata”	La vecchia istanza di origine Worker/vecchio contenitore/vecchia CDN riceve ancora richieste
”Il sito non utilizza tag PHP/dinamici”	Il difetto si verifica nel percorso principale NGINX o nell’analisi del protocollo e non si basa sull’esecuzione di PHP.
”Aprire WAF/Cloudflare è sufficiente”	Non è possibile dimostrare che WAF blocchi tutti i difetti di memoria dipendenti dalla configurazione NGINX o i difetti di ripresa di TLS
”Già aperto ASLR”	Approfittando semplicemente della mitigazione della difficoltà; DoS con richiesta iniezione è ancora possibile
”HTTP/3 non è esposto alla rete pubblica, quindi non è necessario alcun aggiornamento”	Gli altri quattro CVE richiedono ancora una valutazione indipendente; e potrebbero esserci collegamenti diretti con origini nascoste
”La vulnerabilità map di luglio è stata risolta”	Ottobre CVE-2026-93479 comporta successivi problemi di regressione della valutazione dello script
”Disabilitare la memorizzazione nella cache risolve tutti i problemi”	Interessa solo alcuni scenari della cache TLS o AIO e non copre alias, script, HTTP/3

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

Questa sezione segue le correzioni NGINX upstream di ottobre 2026. Gli snippet illustrano le modifiche rappresentative per la revisione delle patch; non sono correzioni complete e compilabili in modo indipendente. Per le build personalizzate, esamina i commit completi, il codice circostante e i test e preferisci una versione supportata completa. S5S6S7S8S9

6.1 CVE-2026-15176: URI è stato riscritto per includere le condizioni di rifiuto della mappatura del percorso alias

Il commit upstream ha modificato ngx_http_map_uri_to_path() in src/http/ngx_http_core_module.c:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

focus della revisione: non è possibile continuare a calcolare il percorso del file system quando URI è cambiato ma la semantica della posizione corrispondente di alias non è più affidabile. Si tratta di un miglioramento del vincolo pre-statale. Non è un semplice controllo se la richiesta URI contiene caratteri non validi. S5

6.2 CVE-2026-93479: Distinguere correttamente tra lunghezza dei dati di output e lunghezza riservata

Il commit upstream aggiorna src/http/ngx_http_script.c e src/stream/ngx_stream_script.c contemporaneamente. L’intenzione principale può essere riassunta come segue:

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

Qui, pool è un nome di parametro illustrativo: le espressioni di allocazione HTTP e Stream effettive differiscono. La modifica calcola prima la lunghezza dell’output dello script, quindi aggiunge la lunghezza riservata all’allocazione finale in modo che l’output non sovrascriva lo spazio riservato. S6

Durante l’auditing e il backport, deve essere coperto anche il corrispondente valutatore di HTTP/Stream; il solo controllo del file di sintassi di configurazione di map non può dimostrare che il difetto sia stato corretto.

6.3 CVE-2026-97205: imposta la soglia di sicurezza per il conteggio delle operazioni asincrone a 8 bit

A monte aggiunto a src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

E aggiungi voci simili alla lettura asincrona dei file, all’attesa della cache, al filtraggio dell’output e al funzionamento del thread:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

focus della revisione: tutti i percorsi di codice effettivi che aggiungeranno r->main->blocked devono essere coperti. Non puoi semplicemente scrivere la costante di soglia nel file di intestazione. Backport deve inoltre verificare il coordinamento completo del fallback sincrono, del callback asincrono e della restituzione degli errori per garantire che lo stallo o la perdita di riferimenti non siano causati dal rifiuto diretto delle attività. S7

6.4 CVE-2026-95101: mantiene lo stato skip separatamente per frame sconosciuti

L’upstream aggiunge il campo skip nella struttura di stato del parser HTTP/3 ed esegue la separazione degli stati:

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

La chiave non è “disabilitare i frame HTTP/3 sconosciuti”, ma garantire che, tra letture multiple, il conteggio dei byte saltati e la lunghezza del payload DATA siano sempre gestiti da stati indipendenti. Le revisioni dovrebbero concentrarsi sullo sharding del frame cross-buffer sconosciuto e sull’eventuale coerenza di client_max_body_size. S8

6.5 CVE-2026-97629: sincronizza l’intero array di slot per chiavi TLS

Le modifiche a monte si trovano in src/event/ngx_event_openssl.c:

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

L’immagine originale conteneva tre slot per tasti, ma solo i primi due sono stati copiati. Eseguire invece la sincronizzazione in base al numero effettivo di elementi dell’array per garantire che il set di chiavi di voto di Worker sia coerente con la memoria condivisa. Durante la revisione, verificare anche che l’allocazione dell’array, l’inizializzazione, il blocco condiviso e la logica di rotazione siano coerenti, anziché controllare semplicemente la modifica della lunghezza memcpy una volta. S9

6.6 Perché non è consigliabile applicare solo frammenti di patch sparsi?

Queste cinque modifiche riguardano rispettivamente src/http, src/stream, src/http/v3 e src/event e le versioni precedenti potrebbero avere backport di sicurezza ed estensioni non ufficiali. Il backport dovrebbe formare la seguente matrice di controllo:

Controllare l’oggetto	Cosa deve essere confermato
fonte della patch	Invio ufficiale, versione target corrispondente, patch completa e verifica della firma
Set di toppe originali	Non è in conflitto con modifiche storiche come CVE-2026-42533, backport di distribuzione, ecc.
percorso del codice	Script HTTP + Stream, AIO/thread, HTTP/3, OpenSSL Ticket sono tutti coperti
Compatibile compilato	OpenSSL, PCRE, modulo ABI, modulo dinamico e dipendenze di collegamento sono coerenti
regressione funzionale	Riscrittura alias, registro dinamico, SSI/AIO, caricamento HTTP/3, ripresa della sessione mTLS
tempo di esecuzione	Tutti i Worker/Pod eseguono nuove build verificate, non rimangono immagini legacy

Per i team che mantengono le proprie versioni, si consiglia di conservare ID patch, versioni dei pacchetti, registri di build e report di regressione verificabili per ciascun CVE; per il funzionamento e la manutenzione ordinaria, la soluzione più sicura è installare gli aggiornamenti di sicurezza completi del fornitore.

7. Backtracking delle vulnerabilità storiche, vecchie filiali e altri prodotti

7.1 NGINX vulnerabilità principale degna di conferma simultanea da maggio a settembre 2026

Molte istanze NGINX che non vengono aggiornate da molto tempo non sono interessate solo dalla nuova edizione di ottobre. Di seguito sono riportati i nodi di riparazione rappresentativi nel prossimo futuro: S1S2

CVE	Prima versione della correzione	Principali rischi e condizioni che richiedono un audit
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, 13 maggio	rewrite La logica di acquisizione e sostituzione di regex anonima attiva l’overflow dell’heap, potenziale RCE; ci sono segnalazioni pubbliche di tentativi di attacco in natura
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, 22 maggio	La sovrapposizione dell’acquisizione di espressioni regolari e della stima della lunghezza in rewrite porta all’overflow
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, 17 giugno	HTTP/2 Configurazione specifica per upstream o gRPC, la condizione dell’intestazione della richiesta di grandi dimensioni attiva l’overflow del buffer
CVE-2026-42530	Mainline 1.31.2, 17 giugno	HTTP/3 Usa-dopo-libero; marchio ufficiale interessato dalla gamma 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, 15 luglio	map + valutazione della variabile di acquisizione regex causa overflow dell’heap e le patch successive hanno una correlazione di regressione con CVE-2026-93479 in ottobre
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, 15 luglio	ngx_http_slice_module Il contenuto della memoria è trapelato in condizioni specifiche di variabile e aggiornamento della cache
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, 15 luglio	SSI è correlato a UAF; non è la stessa causa root della vulnerabilità di conteggio AIO di ottobre
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, 15 settembre	Overflow dell’heap limitato di HTTP/3 + combinazione di versioni specifiche di OpenSSL, manifestato principalmente come arresto anomalo/corruzione della memoria limitata

Anche altre vulnerabilità come NGINX Core, HTTP/2, charset e SMTP annunciate nel 2026 dovrebbero essere indagate secondo i bollettini di sicurezza ufficiali; questa tabella si concentra intenzionalmente sugli eventi tipici più rilevanti per le attuali distribuzioni del proxy inverso NGINX rivolte al pubblico e che hanno implicazioni sulla sicurezza della memoria o sull’integrità delle richieste. non sono tutti i CVE nel 2026. Elenco. S1

Perché prestare particolare attenzione a CVE-2026-42945

Esistono bollettini sulla sicurezza di agenzie governative che registrano attività di sfruttamento in-the-wild e informazioni pubbliche sui codici di exploit per questa vulnerabilità rewrite a maggio. Pertanto, per i casi a cui non sono state applicate patch per molto tempo da maggio ad oggi e che hanno aperte complesse riscritture di espressioni regolari sulla rete pubblica, oltre a completare la riparazione, il crash anomalo Worker, i registri di accesso e le modifiche sospette in quel momento dovrebbero essere ulteriormente esaminati. S23

“Si è verificato un tentativo di attacco” non dimostra automaticamente che l’attaccante abbia eseguito i comandi in modo affidabile su ogni bersaglio; quando è coinvolta la risposta agli incidenti, gli indicatori di compromissione e i crash dei processi dovrebbero essere studiati separatamente dalle prove reali dell’escalation o della persistenza dei privilegi.

7.2 Riparazione per versioni precedenti e backport di distribuzione

NGINX Diversi rami hanno i propri cicli di supporto e diversi tempi di introduzione delle vulnerabilità. Le cinque nuove patch non possono essere distribuite a tutti i primi alberi dei sorgenti senza revisione.

scena	Strategia consigliata
La versione di rilascio ha annunciato patch di sicurezza complete	Utilizzare i pacchetti del fornitore e documentare le versioni complete del pacchetto; evitare la sostituzione con binari nudi upstream incompatibili
Debian 12 e altre versioni interessate che non sono ancora coperte da tutti i CVE in questo batch	Invia ordini di lavoro a rischio, limita l’esposizione esterna e controlla lo stato del fornitore/ELTS; migrare o utilizzare una catena di rilascio di manutenzione verificabile quando necessario
Rami storici che hanno terminato il supporto a monte	Dare priorità alla migrazione alle versioni supportate; se è necessario il backporting a breve termine, i manutentori valuteranno le dipendenze e la compatibilità delle patch e scriveranno test completi.
Viene fornito con forcella NGINX (OpenResty, Tengine, gateway personalizzato)	Determinare innanzitutto se è incluso il percorso del codice corrispondente, quindi utilizzare la dichiarazione di sicurezza del manutentore del fork. Non può essere direttamente equivalente alla versione upstream.
Le patch di sicurezza portano a cambiamenti nelle funzionalità aziendali	Adottare implementazioni graduali, passaggio del traffico tra versioni e adattamento della configurazione; non è opportuno ripristinare la versione non riparata della rete pubblica senza isolamento.

7.3 Riparazione separata per njs, Ingress e NGINX Core

• njs: oltre al programma principale NGINX, è necessario controllare anche la versione del modulo JavaScript NGINX stesso. njs 1.0.2 risolve un problema di esaurimento della memoria di analisi XML di ottobre 2026 e di incoerenza di convalida XML con gli attributi di riferimento dell’entità. Per le distribuzioni associate alla verifica della firma XML utilizzando nginx-saml, è necessario leggere ulteriormente le istruzioni ufficiali njs per gli scenari di plug-in. S20
• F5 NGINX Plus / NGINX Controller di ingresso: inoltre, il controller e il Gateway Fabric possono avere ciascuno bollettini di sicurezza aggiuntivi, diverse versioni di pacchetti e vulnerabilità delle policy uniche. L’aggiornamento di un livello non significa l’aggiornamento automatico di un altro livello. S19
• Kubernetes Comunità ingress-nginx: i funzionari Kubernetes hanno già annunciato che il controller ha interrotto la manutenzione a marzo 2026 e il suo magazzino non può essere confuso con il controller F5. Le aziende interessate dovrebbero pianificare una migrazione senza intoppi e verificare le annotazioni Ingress e le differenze semantiche Gateway API invece di aspettare una nuova versione di sicurezza. S21

8. Criteri di accettazione e ispezioni di follow-up

Si consiglia di utilizzare il seguente elenco come condizioni di accettazione per gli ordini di lavoro di modifica:

Progetto	Standard di qualificazione	Prove che possono essere conservate
Copertura degli asset e del portale	Sono state inventariate tutte le istanze esterne e connesse direttamente che possono bypassare CDN.	Nome di dominio, LB, IP, elenco pod/contenitori
Origine del pacchetto e ambito di riparazione	Utilizzare le versioni confermate per coprire tutti i CVE applicabili	Avviso di sicurezza upstream, USN/DSA, versione del pacchetto, digest dell’immagine
il vecchio processo esce	Tutti i vecchi master/worker/contenitori sono stati sostituiti	PID/ora di inizio, stato di distribuzione in sequenza, immagine in esecuzione
Controllo della configurazione	Le combinazioni ad alto rischio sono state eliminate o coperte da patch e le relazioni di ereditarietà sono state verificate	riepilogo redatto e registro di audit di nginx -T
TLS/mTLS	I certificati attendibili passano; i certificati non validi o mancanti vengono rifiutati; la ripresa della sessione non ignora l’autenticazione	Test di autorizzazione negativo/positivo, risultati del test TLS controllati
HTTP/3 corpo richiesta	Abilita percorso fisso; il corpo della richiesta upstream e la limitazione si comportano correttamente	HTTP/3, caricamento proxy, test di regressione del limite di volume
SSI/AIO	La funzione soddisfa i requisiti, Worker non presenta interruzioni anomale	Monitoraggio della regressione aziendale, dei crash e del tasso di errore
Monitoraggio del funzionamento e della manutenzione	Nessuna eccezione ovvia 5xx, SIGSEGV, il processo esce ripetutamente	Indicatori di servizio e registri prima e dopo le modifiche
Strategia di rollback	Se è necessario il rollback, limitare innanzitutto l’esposizione e preservare i limiti di sicurezza	Ordini di modifica, flussi di emergenza e piani di quarantena
ciclo di vita successivo	Determinare gli abbonamenti ai bollettini sulla sicurezza, la frequenza di aggiornamento dei contenitori e i piani di migrazione dei rami	Aggiornamento del registro, della persona responsabile e della prossima data di audit

8.1 Su cosa dovresti concentrarti nei registri e nello stato di esecuzione?

Risolvere i problemi relativi ad anomalie su server che sono stati esposti per molto tempo worker process exited on signal 、 SIGSEGV, picchi di richieste di errori, aggregazione anomala dell’accesso all’origine, TLS imprevisto ripresa/autenticazione della sessione riuscita e comportamento anomalo del corpo della richiesta backend. Questi indicatori possono essere utilizzati solo come indizi investigativi e non sono prove sufficienti per dimostrare direttamente che un determinato CVE è stato sfruttato. ;La mancanza di registri rilevanti non dimostra che non ci sia stato un attacco.

8.2 Formulazione finale raccomandata della conclusione sul rischio

Il rapporto di accettazione per l’ambiente di produzione dovrebbe utilizzare la seguente precisa espressione:

Sono stati identificati l’ingresso del servizio esterno NGINX e l’origine del pacchetto software. Tutte le istanze applicabili sono state aggiornate alla versione di sicurezza ufficiale upstream o il backport confermato dal fornitore della versione è stato completato; sono stati sostituiti il ​​vecchio Worker ed i vecchi contenitori. L’alias/riscrittura/mappa, AIO/SSI, corpo della richiesta HTTP/3 e le configurazioni relative al ticket di sessione TLS/mTLS sono state controllate e hanno superato test funzionali, di autenticazione e di regressione dell’integrità della richiesta. Per i casi che non hanno ancora completato l’aggiornamento, registrare inoltre le aree di esposizione, le misure di compensazione, le persone responsabili e le scadenze di completamento.

Se la patch per Debian 12 o altre release risultasse ancora incompleta, non è opportuno giudicare “completato” l’intero modulo di accettazione; il CVE irrisolto, se esiste una configurazione di trigger corrispondente, lo stato di isolamento e il percorso di aggiornamento finale dovrebbero essere chiaramente registrati.

---

Appendice: fonti e link citati

Descrizione: I numeri [Sx] nel testo corrispondono uniformemente a questa sezione. Quanto segue dà priorità agli annunci di sicurezza del progetto a monte, agli impegni del codice, agli annunci di rilascio dei fornitori e alle informazioni dell’agenzia di sicurezza nazionale. La gravità delle vulnerabilità citate è descritta secondo i criteri di rating di ciascun organismo emittente; la data di verifica dei dati è il 27 ottobre 2026.

S1 — NGINX Open Source Bollettino ufficiale di sicurezza

• https://nginx.org/en/security_advisories.html

Contiene le versioni interessate upstream, i rami corretti e i livelli di gravità ufficiali di cinque CVE di ottobre e copre anche le vulnerabilità storiche fino al 2026.

S2: record di rilascio della versione ufficiale NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

Conferma 1.30.6 / 1.31.7 di 2026-10-14, 1.31.8 di 2026-10-21 e le tappe fondamentali del rilascio della sicurezza da maggio a settembre.

S3 - Cyber Security Agency di Singapore: F5 NGINX Tre vulnerabilità critiche

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

Descrizione dei punteggi CVSS v4.0 9.2, condizioni di configurazione richieste e raccomandazioni di mitigazione temporanee per CVE-2026-15176, CVE-2026-93479 e CVE-2026-97205.

S4 - NHS Inghilterra: F5 NGINX Avviso ad alto rischio

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

Descrive l’impatto DoS/potenziale RCE dei problemi di sicurezza della memoria e vincoli come ASLR disattivato o ignorato.

S5: commit della fonte ufficiale: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

Corrisponde al controllo dello stato di alias e r->uri_changed in ngx_http_map_uri_to_path().

S6: commit della fonte ufficiale: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

Corrispondente alla lunghezza dello script HTTP/Stream e alla logica di allocazione del buffer riservato.

S7 - Commit della fonte ufficiale: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

Corrisponde alla soglia di conteggio r->main->blocked NGX_HTTP_MAX_BLOCKED 250 e al fallback del percorso asincrono.

S8: commit della fonte ufficiale: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

La separazione degli stati corrispondente alla lunghezza rimanente del frame sconosciuto HTTP/3 e alla lunghezza del corpo della richiesta DATA.

S9: commit della fonte ufficiale: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

Corrisponde a tutti gli slot chiave durante la sincronizzazione TLS Rotazione del ticket di sessione.

S10 — F5: CVE-2026-15176 Annuncio del fornitore

• https://my.f5.com/manage/s/article/K000162416

Elenca i fattori di attivazione come alias, rewrite, $request_filename e i registri di accesso.

S11 — F5: CVE-2026-93479 Annuncio del fornitore

• https://my.f5.com/manage/s/article/K000162607

Elenca l’acquisizione di espressioni regolari della mappa, il percorso root e registra le condizioni di valutazione delle variabili.

S12: documentazione ufficiale del modulo NGINX TLS/SSL

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

Descrizione ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key e autenticazione del certificato client e altre istruzioni.

S13 — Consulenza sulla sicurezza: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Fornire la versione fissa del pacchetto software completo e l’ambito di distribuzione di Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Consulenza sulla sicurezza: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Confermare il pacchetto di correzioni di sicurezza 1.26.3-3+deb13u10 per Debian 13 / trixie e registrare l’associazione backport per CVE-2026-93479.

S15 — Monitoraggio delle vulnerabilità: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Utilizzato per verificare lo stato della correzione della distribuzione di Debian 12 / bookworm e Debian 13 / trixie. Questo stato potrebbe cambiare con futuri aggiornamenti di sicurezza.

S16 — Monitoraggio delle vulnerabilità: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

Conferma supplementare dello stato di sicurezza della vulnerabilità HTTP/3 su diverse filiali Debian.

S17 — Consulenza sulla sicurezza: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

Comprensione supplementare della correlazione tra la vulnerabilità di regressione di ottobre e la correzione per CVE-2026-42533 di luglio.

S18: documento ufficiale del modulo proxy inverso NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

Interroga la semantica e i valori predefiniti di configurazioni come proxy_request_buffering, client_max_body_size, alias, aio, ecc.

S19 — NGINX Plus Note di rilascio ufficiali

• https://docs.nginx.com/nginx/releases/

Elenca inoltre rami, versioni, patch e promemoria sulla compatibilità degli aggiornamenti CR/LTS.

S20 — NGINX JavaScript / njs Bollettino ufficiale di sicurezza

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

Contiene ottobre 2026 njs 1.0.2 e relativi problemi di convalida XML e di esaurimento della memoria.

S21 — Kubernetes: Istruzioni ufficiali per il pensionamento della Comunità ingress-nginx

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

Tieni presente che il progetto ha interrotto le nuove versioni e le correzioni di sicurezza nel marzo 2026 e si consiglia di migrare il controller mantenuto o Gateway API.

S22: controllo del servizio ufficiale NGINX e istruzioni di aggiornamento binario online

• https://nginx.org/en/docs/control.html

Distinguere i metodi di ricaricamento della configurazione, riavvio e aggiornamento dei file eseguibili online per l’accettazione del cambio di processo.

S23 - Avviso di sicurezza governativa: vulnerabilità di riscrittura NGINX di maggio 2026

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

Fornire background storico sui rischi e suggerimenti sugli aggiornamenti di sicurezza per CVE-2026-42945; i giudizi relativi allo sfruttamento in natura dovrebbero basarsi sull’annuncio dell’agenzia all’epoca e su ulteriori prove dell’incidente.

S24 - F5: CVE-2026-95101 e CVE-2026-97629 Annunci dei fornitori

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

Copre rispettivamente i rischi dell’iniezione del corpo della richiesta HTTP/3 e della rotazione automatica della chiave del ticket TLS.

S25 — F5: CVE-2026-97205 Annuncio del venditore

• https://my.f5.com/manage/s/article/K000162608

Descrizione Condizioni di attivazione SSI/AIO e potenziali rischi di danneggiamento della memoria.

Aggiornamento di sicurezza NGINX: controlli di configurazione, aggiornamenti e verifica