--- title: "Vulnerabilità NGINX: cause, soluzioni e verifica della produzione" description: "Esamina cinque vulnerabilità NGINX di ottobre 2026, i relativi prerequisiti di configurazione, correzioni specifiche del ramo, backport di distribuzione e verifica della produzione." language: "it" url: "https://keendigit.com/it/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # Vulnerabilità NGINX: cause, soluzioni e verifica della produzione Esamina cinque vulnerabilità NGINX di ottobre 2026, i relativi prerequisiti di configurazione, correzioni specifiche del ramo, backport di distribuzione 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-1) 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. [S1](https://keendigit.com/it/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/it/insights/nginx-remediation-guide#source-2) 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. [S13](https://keendigit.com/it/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/it/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/it/insights/nginx-remediation-guide#source-15) 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. [S1](https://keendigit.com/it/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/it/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/it/insights/nginx-remediation-guide#source-4) 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. [S3](https://keendigit.com/it/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/it/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/it/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/it/insights/nginx-remediation-guide#source-12) ## 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. [S1](https://keendigit.com/it/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/it/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/it/insights/nginx-remediation-guide#source-3) 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. [S1](https://keendigit.com/it/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/it/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/it/insights/nginx-remediation-guide#source-4) | 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. [S1](https://keendigit.com/it/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/it/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/it/insights/nginx-remediation-guide#source-4) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-4) 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. [S5](https://keendigit.com/it/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/it/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/it/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/it/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/it/insights/nginx-remediation-guide#source-9) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-5) Combinazione tipica (utilizzata solo come controesempio per il controllo della configurazione, la distribuzione non è consigliata): ```nginx # 仅用于识别风险模式：不是修复配置 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. [S5](https://keendigit.com/it/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/it/insights/nginx-remediation-guide#source-10) 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. [S5](https://keendigit.com/it/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/it/insights/nginx-remediation-guide#source-10) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-6) | 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. [S6](https://keendigit.com/it/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/it/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/it/insights/nginx-remediation-guide#source-17) 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-11) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-7) 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-7) 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. [S4](https://keendigit.com/it/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/it/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/it/insights/nginx-remediation-guide#source-25) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-8) 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. [S8](https://keendigit.com/it/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/it/insights/nginx-remediation-guide#source-18) 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-24) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-9) Le combinazioni di distribuzione ad alto rischio sono in genere: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 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". [S9](https://keendigit.com/it/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/it/insights/nginx-remediation-guide#source-12) 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-24) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-4) - 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-23) ## 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. [S1](https://keendigit.com/it/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/it/insights/nginx-remediation-guide#source-2) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-1) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-13) | 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-13) ### 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: ```text 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. [S14](https://keendigit.com/it/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/it/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/it/insights/nginx-remediation-guide#source-16) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-19) | | 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-20) | | 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-21) | ### 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 ```bash # 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: ```bash 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): ```bash 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. [S13](https://keendigit.com/it/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/it/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/it/insights/nginx-remediation-guide#source-15) Pacchetto ufficiale nginx.org: ```bash # 先确认仓库来自 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 ```bash 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-22) 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. [S3](https://keendigit.com/it/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/it/insights/nginx-remediation-guide#source-4) ### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-5) ### 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: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[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. [S3](https://keendigit.com/it/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/it/insights/nginx-remediation-guide#source-6) ### 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: ```nginx # 在适当的 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-7) ### 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: ```nginx # 示意：保留 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. [S8](https://keendigit.com/it/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/it/insights/nginx-remediation-guide#source-18) ### 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 # 在 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. [S9](https://keendigit.com/it/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/it/insights/nginx-remediation-guide#source-12) 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-12) ### 5.7 Il ruolo del sistema operativo e la protezione delle frontiere ```bash # 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-4) ### 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. [S5](https://keendigit.com/it/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/it/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/it/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/it/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/it/insights/nginx-remediation-guide#source-9) ### 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`: ```diff - 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-5) ### 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: ```diff - 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-6) 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`: ```c #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: ```c 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-7) ### 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: ```c 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-8) ### 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`: ```diff 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-9) ### 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: [S1](https://keendigit.com/it/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/it/insights/nginx-remediation-guide#source-2) | 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-1) #### 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-23) "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](https://keendigit.com/it/insights/nginx-remediation-guide#source-20) - 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-19) - 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](https://keendigit.com/it/insights/nginx-remediation-guide#source-21) ## 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 - 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 - - 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 - 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 - 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 - 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 - Corrispondente alla lunghezza dello script HTTP/Stream e alla logica di allocazione del buffer riservato. ### S7 - Commit della fonte ufficiale: CVE-2026-97205 - 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 - 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 - Corrisponde a tutti gli slot chiave durante la sincronizzazione TLS Rotazione del ticket di sessione. ### S10 — F5: CVE-2026-15176 Annuncio del fornitore - Elenca i fattori di attivazione come `alias`, `rewrite`, `$request_filename` e i registri di accesso. ### S11 — F5: CVE-2026-93479 Annuncio del fornitore - 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 - 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) - 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) - 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 - 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 - Conferma supplementare dello stato di sicurezza della vulnerabilità HTTP/3 su diverse filiali Debian. ### S17 — Consulenza sulla sicurezza: Red Hat: 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 - - 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 - Elenca inoltre rami, versioni, patch e promemoria sulla compatibilità degli aggiornamenti CR/LTS. ### S20 — NGINX JavaScript / njs Bollettino ufficiale di sicurezza - - 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 - - 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 - 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 - - 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 - - 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 - Descrizione Condizioni di attivazione SSI/AIO e potenziali rischi di danneggiamento della memoria. [Aggiornamento di sicurezza NGINX: controlli di configurazione, aggiornamenti e verifica](https://keendigit.com/it/news/nginx-security-update) ## Consulenza sulla manutenzione della sicurezza Non sei sicuro di come le modifiche all'attendibilità dei certificati influiscano sui tuoi sistemi? Possiamo aiutare a valutare i client interessati e a pianificare gli aggiornamenti di sicurezza. [Discuti gli aggiornamenti di sicurezza]() [Pagina originale]() · [Indice dei contenuti]() KeenDigit LLC · ID di deposito del Wyoming: 2026-002106155 [Verificare con il Segretario di Stato del Wyoming]() © 2026 KeenDigit LLC · Sheridan, Wyoming, Stati Uniti · Tutti i diritti riservati.