Vulnerabilități NGINX: cauze, remedieri și verificarea producției

Data istorică a articolului: 2026-10-14 (data dezvăluirii și lansării securității). Surse verificate și informații completate prin 2026-10-27.

Acest articol este arhivat după data evenimentului; versiunile și actualizările de lansare lansate după 14 octombrie sunt incluse mai jos. Public: site-ul web NGINX Open Source / NGINX Plus și personal de operare și întreținere proxy inversă, personal de răspuns de securitate, întreținerii distribuției, precum și ingineri care autocompilează NGINX și întrețin module terțe.

Acest articol se concentrează pe cele cinci vulnerabilități de bază NGINX care au fost dezvăluite și remediate intens pe 14 octombrie 2026 și, de asemenea, analizează vulnerabilitățile reprezentative de siguranță a memoriei și integritatea solicitărilor din mai până în septembrie 2026. Conținutul acoperă condiții de declanșare, cauze la nivel de cod, sfera impactului, flux de lucru de remediere, implementare de corecție, măsuri de reducere a ramurilor oficiale și vechi de atenuare a ramurilor vechi. verificarea producției. Referințe precum S1 leagă la anexa sursă. Exemplele de configurații sunt folosite doar pentru a ilustra ideile de implementare și auditare și ar trebui verificate pe baza versiunii reale, moștenirea configurației, dependențe și capacitatea de afaceri înainte de implementare.

TL;DR: Acțiuni prioritare

1. Prioritizează upgrade-urile de securitate. Pentru nginx.org Pachetele Open Source, actualizați Stable 1.30 ramură la cel puţin 1.30.6 iar cel Mainline 1.31 ramură la cel puţin 1.31.7. La data verificării, 1.31.8 este cel mai recent Mainline eliberare. Acestea sunt linii de bază separate ale ramurilor; nu compara numărul lor între ramuri. S1 S2
2. Verificați instalările de distribuție după versiunea pachetului complet. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 au backport-uri pentru furnizor; Debian 13 (trixie) necesită cel puțin 1.26.3-3+deb13u10. La verificare, pachetul Debian 12 (bookworm) 1.22.1-9+deb12u10 este încă marcat ca fiind afectat. Verificați fiecare CVE; avizul Debian 13 nu stabilește că Debian 12 este fix. S13S14S15
3. Audit cinci combinații de configurație: alias + rewrite + $request_filename , map + regex + evaluare variabilă, aio + ssi + include virtual , HTTP/3 cu proxy_request_buffering on , și ssl_session_cache shared:... cu automată TLS Rotația tastei biletului de sesiune. Numai prezența unei directive nu stabilește exploabilitatea; evaluează calea cererii și domeniul de aplicare a configurației. S1 S3 S4
4. Înlocuiți toate procesele și containerele vechi. Rulați nginx -t, apoi reporniți serviciul sau efectuați o implementare continuă de înaltă disponibilitate. Confirmați că vechile procese master/worker au ieșit; Numai nginx -s reload nu demonstrează că binarul care rulează s-a schimbat.
5. Verificați punctele finale reale: HTTP/1.1, HTTP/2, HTTP/3 dacă sunt activate, încărcări proxy și corpuri de solicitare API, autentificare certificat mTLS, pagini SSI și jurnalele de acces. Înregistrați proveniența pachetului, versiunea, rezumatul imaginii, procesele de rulare și rezultatele pentru fiecare punct final.
6. Dacă o actualizare imediată este imposibilă, eliminați condițiile de declanșare aplicabile: dezactivați inutil SSI / AIO sau HTTP/3 , recenzie vulnerabil alias / rewrite / map referințe variabile și evaluează temporar ssl_session_tickets off; pentru afectate mTLS servicii. WAF , ASLR , limitele ratei și modificările de configurare acoperă doar unele condiții și nu pot înlocui patch-urile oficiale. S3 S4 S8 S12

1. Privire de ansamblu asupra vulnerabilității și evaluarea riscurilor

NGINX a lansat 1.30.6 (Stable) și 1.31.7 (Mainline) pe 14 octombrie 2026, reparând cinci probleme de securitate. Trei implică depășiri de heap sau utilizare-după-free și primit F5 CVSS v4.0 scoruri de 9.2 / Critical. Celelalte două afectează integritatea cererii HTTP/3 și autentificarea certificatului clientului TLS. S1S2S3

Distingeți sistemele de evaluare: nginx.org listează toate cele cinci probleme ca medium, în timp ce F5 CVSS v4.0 și unele agenții naționale de securitate clasifică cele trei probleme de memorie drept Critice. Acest lucru nu înseamnă că toate cele cinci permit executarea necondiționată a codului de la distanță. Configurația, accesibilitatea traficului și condițiile în afara controlului unui atacator contează. Coruperea memoriei și RCE de încredere sunt niveluri diferite de dovezi. S1S3S4

CVE	Probleme tehnice și condiții tipice de declanșare	impact de bază	Evaluare și eliminare
CVE-2026-15176	alias maparea căilor + rewrite modificare URI + evaluare $request_filename	Depășirea memoriei tampon, Worker prăbușire; potenţialul RCE în anumite condiţii	F5 CVSS v4.0 9.2; prioritizează depanarea
CVE-2026-93479	Evaluarea scriptului HTTP/Stream, în special captarea regex map și directorul root, referință încrucișată a variabilelor de jurnal	Buffer-ul rezervat este suprascris și heap-ul se depășește; potențial RCE în anumite condiții	F5 CVSS v4.0 9.2; este un risc de regresie după reparațiile anterioare
CVE-2026-97205	SSI include virtuale și AIO/funcționare asincronă; depășire a numărului de operațiuni restante	Utilizare-After-Free, Worker accident, corupție de memorie; potențial RCE	F5 CVSS v4.0 9.2; necesită o configurație care nu este implicită
CVE-2026-95101	HTTP/3 Cadrul necunoscut este fragmentat în buffere, tamponarea corpului solicitării proxy este activată	Injectarea incorectă de octeți non-DATA în corpul cererii din amonte, eventual ocolind limita de dimensiune a corpului cererii	Această vulnerabilitate afectează integritatea cererii. El însuși nu oferă execuție de cod la distanță (RCE).
CVE-2026-97629	Cache de sesiune TLS partajat, rotire automată a tastelor și oglindire a tastei Worker	Falsificare de bilete de sesiune; Ocolirea autentificării certificatului clientului poate apărea pentru serviciul mTLS afectat	Trebuie acordată o atenție specială impactului asupra afacerii al autentificării cu certificat de tip API

Scorul CVSS de mai sus este dat de F5 folosind v4.0; aceeași vulnerabilitate poate prezenta o gravitate diferită în CVSS 3.1, nginx.org propriile note și evaluări de severitate a distribuției. S1S3S4

1.1 Prioritizează expunerea la implementare, mai degrabă decât doar scorurile CVE

Formular de desfășurare	Puncte cheie de investigare	Recomandări cu prioritate de eliminare
Proxy invers de rețea publică, inclusiv rewrite, alias și complex map personalizat	CVE-2026-15176, CVE-2026-93479 și rescrie/hartă vulnerabilități din mai până în iulie	P0: auditați și actualizați imediat
API / Plan de management care utilizează certificatul clientului ca autentificare unică sau principală	Tichetul de sesiune și configurația cache partajată a CVE-2026-97629	P0: Confirmați imediat limita de autentificare și actualizați
Furnizați încărcare externă HTTP/3, interfață de schimbare a stării, clasa de tranzacție API	CVE-2026-95101, în special corpul cererii este proxy către backend	P0/P1: Aranjați în funcție de importanța afacerii
SSI Pagina dinamică sau I/O fișier asincron	CVE-2026-97205	P1: Confirmați condițiile combinației și reparați cât mai curând posibil
Doar pagini statice + proxy invers simplu HTTP/1.1/2	Configurația și versiunea trebuie încă auditate, dar unele condiții CVE pot lipsi	P1: Inclus în fereastra de actualizare de securitate de urgență
Utilizați comunitatea Kubernetes retrasă ingress-nginx	Proiectul oprește întreținerea securității, iar riscurile nu se limitează la aceste cinci CVE	Faceți un plan individual de migrare a controlerului

P0/P1 este sugestiile de eliminare a operațiunii și întreținerii date în acest articol pentru expunerea la rețelele publice și sensibilitatea la certificare. Nu este o clasificare oficială CVSS și nici nu ar trebui să înlocuiască activele interne ale întreprinderii și să modifice evaluarea riscului.

1.2 Limite de impact și permisiuni de atac

Vulnerabilitățile de bază din acest lot sunt localizate în principal în planul de date NGINX: punctul de intrare al atacului este conexiunea și cererea clientului, iar impactul real are loc de obicei în procesul Worker. Dacă sunt îndeplinite condițiile de exploatare pentru coruperea memoriei, permisiunea de execuție a codului este în general restricționată de utilizatorul care rulează, constrângerile containerului, capacitatea Linux, permisiunile de montare și de rețea ale Worker; potențialul RCE nu implică automat privilegii root sau compromisuri ale gazdei. S4

Dar chiar dacă procesul nu este privilegiat, acesta poate avea în continuare acces la acreditările proxy, fișierele care pot fi citite care conțin chei private de certificat, jetoane de serviciu în amonte, fișiere temporare, API interne și rețele accesibile. Pentru mTLS, ocolirea autentificării în sine poate fi o consecință comercială serioasă și nu trebuie neapărat însoțită de execuția codului.

2. Analiza cauzei

2.1 Înțelegeți cele trei limite predispuse la erori din NGINX

Un NGINX worker este un proces de lungă durată, bazat pe evenimente, care menține starea cererii, operațiunile asincrone și analizatorii de protocol. Această vulnerabilitate include constrângeri la trei niveluri de inginerie:

1. evaluarea variabilelor și dimensiunea memoriei trebuie să fie consecvente: rewrite După modificarea cererii URI, maparea căii trebuie să fie consecventă cu location în vigoare în prezent; când interpretul de script calculează lungimea variabilă, spațiul de scriere trebuie să acopere ieșirea reală și zonele rezervate.
2. Operațiunile asincrone trebuie să prelungească ciclul de viață al memoriei solicitate: atunci când există fișiere neterminate de citire și scriere, așteptare în cache sau sarcini de fir, pool-ul de memorie de solicitare relevant nu poate fi eliberat în avans.
3. starea protocolului și starea securității nu pot fi amestecate sau omise: HTTP/3 Lungimea săritării cadrelor necunoscute nu poate fi considerată lungimea corpului cererii DATA; TLS Toate sloturile de cheie care participă la verificarea semnăturii trebuie să fie corect inițializate și sincronizate în timpul rotației biletului de sesiune.

Următorul conținut se bazează pe confirmarea remedierii NGINX în amonte și pe anunțul furnizorului pentru a explica mecanismul de defecțiune care poate fi declanșat; fragmentul exemplu este pentru analiză, nu este codul complet care poate fi utilizat direct pentru a repara mediul de producție. S5S6S7S8S9

2.2 CVE-2026-15176: Maparea căii dintre alias și URI rescris este nevalidă.

În NGINX, location potrivit și alias determină calea fișierului; rewrite poate modifica cererea curentă URI. După rescriere, este posibil ca ipotezele utilizate de maparea originală location să nu mai fie valabile.

Calea de procesare afectată nu a verificat în mod adecvat dacă cererea a fost rescrisă la verificarea stării alias în ngx_http_map_uri_to_path(). Când configurația continuă să evalueze $request_filename după rescriere, calea poate fi construită cu ipoteze care nu sunt conforme cu starea curentă URI, declanșând în cele din urmă o scriere în afara limitelor în memoria heap. S5

Combinație tipică (utilizată doar ca contraexemplu pentru auditul de configurare, implementarea nu este recomandată):

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

Pericolul nu se limitează la return: set, if, add_header, log_format etc. trebuie, de asemenea, auditate dacă evaluarea $request_filename este declanșată în același proces de solicitare. return din exemplu face doar această cale de stare ușor de văzut, nu poate fi folosită pentru a deduce că toate configurațiile de producție vor produce debordări. S5S10

Consecințele atacului: Construirea unei cereri poate determina repornirea Worker sau întreruperea serviciului; în condiții precum ASLR fiind închis sau poate fi ocolit, există un potențial RCE. Miezul patch-ului din amonte este refuzul de a finaliza maparea traseului URI rescrisă în contextul alias care nu mai este valabil, mai degrabă decât să extindeți pur și simplu un anumit buffer. S5S10

2.3 CVE-2026-93479: Nepotrivire între „spațiu rezervat” și lungimea variabilă reală în evaluarea scriptului

Modulele HTTP și Stream ale NGINX au evaluatori de script care concatenează șiruri literale și valori variabile în șirul rezultat. Exemplele de aplicații includ căile pentru documentul HTTP root, căile pentru jurnalul de acces și expresiile variabile în Stream.

Anumite configurații ale map + expresii regulate permit ca valorile capturate să fie citite de alte expresii înainte ca variabila rezultat map să fie evaluată. Combinată cu metoda de execuție a scriptului cu lungime rezervată, vechea implementare va număra spațiul rezervat len în acumulatorul de lungime evaluată în avans, astfel încât calculele ulterioare ale pointerului de scriere nu mai sunt în concordanță cu limita tamponului. Într-o anumită secvență de evaluare a variabilelor, scrierile ulterioare de șir pot suprascrie zona rezervată, provocând o depășire a heap-ului. S6

elemente participative	De ce merită să fii atent
regex în map	Evaluarea variabilelor de captură poate avea un ciclu de viață independent și un comportament de stocare în cache
Capturi anonime, cum ar fi $1, $2 etc.	Suprascris cu ușurință de alte expresii sau expresii regulate, ceea ce face dificilă urmărirea proprietății
Variabile în root	Execuția scriptului și rezervarea bufferului la declanșarea construirii căii
log_format/Cale jurnal dinamic	Același tip de evaluare poate fi declanșat ulterior în cerere
Expresii de script în stream	Remedierea în amonte modifică și ngx_stream_script_run(). Nu puteți revizui doar modulul HTTP.

Relație de regresie importantă: Codul legat de această vulnerabilitate este legat de modificările anterioare care au remediat CVE-2026-42533. DSA oficial pentru Debian 13 afirmă clar că codul afectat a fost introdus în pachetul trixie printr-un backport de securitate anterior. Prin urmare, „patch-ul de vulnerabilitate map din iulie a fost instalat” nu înseamnă că CVE-2026-93479 din octombrie a fost acoperit; trebuie verificat întregul lanț de soluții de securitate. S6S14S17

Riscul potențial RCE aici este legat de mediul de protecție a memoriei și nu trebuie pretins că regex-ul map singur va putea fi exploatat de atacatori anonimi. S11

2.4 CVE-2026-97205: AIO Numărul de operațiuni neterminate cauzează înglobare Utilizare-după-liber

Această vulnerabilitate nu este pur și simplu „porniți SSI și veți obține UAF”. Cheia constă în numărul de referințe al operațiunii asincrone deținut de cererea principală.

NGINX Utilizați r->main->blocked pentru a urmări procesarea asincronă care nu s-a finalizat încă, în vechea implementare era număr de 8 biți; unele căi nu au efectuat o verificare a limitei superioare înainte de a incrementa numărul. Când aceeași cerere principală acumulează 256 de operațiuni restante, numărul se poate încheia de la 255 la 0. Procesele ulterioare vor crede în mod eronat că nu există nicio operațiune asincronă care să împiedice eliberarea cererii, eliberând astfel pool-ul de memorie al cererii care este încă referit de sarcină. S7

Procesul de eșec poate fi împărțit în:

1. Cu calea I/O/thread asincronă asociată activată, pagina SSI introduce mai multe subcereri sau operații de citire prin include virtual.
2. Operațiunile restante ale unei anumite cereri principale se acumulează până la limita superioară reprezentată de câmpul de numărare.
3. Numărul de 8 biți se închide, exprimat incorect ca „fără operațiuni în așteptare”.
4. Pool-ul de memorie de solicitare este eliberat, în timp ce fișierele citesc, cache-ul așteaptă sau apelurile inverse ale sarcinilor de fir păstrează în continuare referințe la el.
5. Reapelurile ulterioare de finalizare asincronă accesează memoria eliberată, ceea ce duce la blocări UAF, Worker sau o potențială corupție a memoriei.

Remedierea oficială adaugă NGX_HTTP_MAX_BLOCKED 250 la fișierul antet cererii și adaugă restricții la filtrul de ieșire, citirea cache-ului și calea firului în amonte; când pragul este atins, operațiunile cu căi sincronizate sunt finalizate sincron, iar dacă nu pot fi procesate în siguranță, adăugarea ulterioară a sarcinilor în așteptare va fi refuzată. S7

judecată de aplicabilitate: trebuie evaluat dacă SSI, AIO, includerea virtuală, subcererile și operațiunile asincrone aferente pot apărea în combinație în același lanț de cereri. Acestea nu sunt, de obicei, configurațiile proxy static simple implicite. aio off; sau ssi off; pot elimina anumite elemente de declanșare, dar dependențele funcției de afaceri trebuie confirmate mai întâi. S4S7S25

2.5 CVE-2026-95101: HTTP/3 cadrul necunoscut este confundat cu starea corpului cererii DATA

Analizatorul de cadre HTTP/3 trebuie să facă distincția între cadrele DATA (care trebuie să fie transmise procesării corpului cererii HTTP) și cadrele necunoscute care ar trebui să fie omise. Lungimea cadrelor necunoscute trebuie, de asemenea, păstrată cu precizie atunci când se fragmentează în bufferele de rețea.

Vechea implementare a lui ngx_http_v3_parse_data() folosea câmpul st->length pentru a salva „numărul de octeți rămași de ignorat” atunci când se omite cadre necunoscute, în timp ce filtrul pentru corpul cererii interpreta același câmp ca „lungimea încărcării utile DATA rămasă”. Dacă se întâmplă ca cadrul necunoscut să acopere mai multe apeluri de analiză, următorul lot de octeți după ce analiza este întreruptă poate fi confundat ca parte a corpului cererii. S8

Apar două tipuri de riscuri:

• cerere de injectare a corpului: sarcina de cadru non-DATA transmisă de client poate fi transmisă aplicației din amonte, modificând datele primite efectiv de backend.
• ocolirea limitei de dimensiune: client_max_body_size și alte restricții. Verificările așteptate sunt concentrate pe calea DATA, iar conținutul convertit incorect poate ocoli verificarea corespunzătoare.

Scenariul tipic de declanșare descris de oficial este atunci când ngx_http_v3_module primește cererea HTTP/3 și transmite proxy_request_buffering on. Bufferul pentru corpul solicitării proxy este activat în mod implicit în ngx_http_proxy_module. Prin urmare, proxy-ul invers care pornește HTTP/3 ar trebui verificat mai întâi. Nu este adecvat să presupunem că nu există nicio condiție de declanșare doar pentru că proxy_request_buffering on; nu este scris în mod explicit. S8S18

Consecința directă a acestei vulnerabilități aparține integrității cererii backend și schimbării limitelor de securitate, care nu este expresia echivalentă a RCE completată direct în nucleul NGINX. Impactul final asupra afacerii depinde de modul în care acești octeți sunt analizați și de încredere în amonte. S24

2.6 CVE-2026-97629: TLS Rotația biletului ratează al treilea slot de cheie

În configurațiile afectate, NGINX poate genera și roti automat cheile TLS Session Ticket prin memoria cache partajată, permițând mai multor Worker să proceseze același lot de bilete.

Logica de sincronizare relevantă alocă 3 sloturi de cheie pentru fiecare Worker, iar apelul de decriptare va traversa, de asemenea, aceste sloturi; dar implementarea veche copiază doar 2 sloturi de cheie din memoria partajată de fiecare dată, rezultând numele cheii, cheia HMAC și AES ale celui de-al treilea slot. Cheia poate rămâne neinițializată. Dacă identificatorul de cheie al unui bilet este potrivit cu această stare, materialul cheie neinițializat poate fi utilizat pentru verificarea și decriptarea semnăturii, formând astfel o cale pentru a crea sesiunea TLS. S9

Combinațiile de implementare cu risc ridicat sunt de obicei:

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

Cea mai gravă consecință de afaceri a acestei vulnerabilități este că, în cazul serviciilor care utilizează autentificarea certificatelor client (mTLS) în ssl_verify_client on; și în alte moduri, sesiunile de recuperare falsificate pot ocoli verificarea certificatului clientului. Succesul atacului este, de asemenea, supus unor condiții incontrolabile; un site care folosește doar un certificat HTTPS normal pe partea de server și nicio autentificare cu certificat de client nu ar trebui să fie caracterizat greșit ca „atacatorul poate ocoli întreaga autentificare a site-ului web”. S9S12

Aceasta este o problemă privind starea de autentificare a sesiunii TLS și nu are nimic de-a face cu faptul că cheia privată TLS a serverului este spartă sau dacă certificatul public CA root este afectat. S24

2.7 Cum să înțelegeți DoS, RCE, bypass-ul de autentificare și exploit-urile cunoscute

• DoS: eroarea de memorie face ca Worker să se blocheze sau să repornească masiv. Dacă cauzează indisponibilitatea generală, este legat de presiunea traficului, capacitatea de repornire a procesului, timpul de întreținere a conexiunii și arhitectura de înaltă disponibilitate.
• potențial RCE: Unele anunțuri indică faptul că există o posibilitate de executare a codului atunci când ASLR este închis sau ocolit. Acest lucru nu înseamnă că a fost dezvăluit un lanț public de atac care poate executa în mod stabil și universal comenzi. S4
• Solicitare ocolire a injecției/autentificării: poate schimba direct starea de afaceri protejată sau poate solicita conținut și nu poate fi ignorată doar pentru că nu obține direct shell-ul.
• a descoperit încercări de atac: CVE-2026-42945 în mai 2026 are rapoarte despre activități de exploatare în sălbăticie; nu ar trebui să deducă în mod direct acest fapt istoric pentru a însemna că toate cele cinci CVE din octombrie au fost exploatate cu succes la scară largă. S23

3. Reparați versiunea și selectarea patch-urilor

3.1 NGINX Open Source linia de bază oficială a plasturii

ramura din amonte	Prima versiune oficială acoperă cinci vulnerabilități în octombrie	Recomandări începând cu 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Instalați cel puțin 1.30.6 și continuați cu versiunile de securitate ulterioare.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
Sucursala anterioară NGINX Open Source	Nu poate fi judecat doar pe baza „au fost aplicate vechi patch-uri de vulnerabilitate”	Migrați mai întâi la filiala întreținută; în caz contrar, vânzătorul este obligat să furnizeze dovezi oficiale de sprijin pe baza CVE-by-CVE.

Acestea sunt concluziile versiunii ale codului sursă/ramurului oficial nginx.org în amonte și nu ar trebui folosite pentru a nega direct pachetul de securitate cu corecții backportate furnizate de furnizorul de distribuție. Chiar dacă valoarea lui 1.31.6 este mai mare decât 1.30.6, este totuși mai mică decât linia de bază a patch-ului din ramura principală. S1S2

3.2 Domeniul de impact din amonte a cinci CVE

Următoarele intervale sunt listate conform textului original al buletinului de securitate nginx.org și trebuie înțelese împreună cu „ramura curentă care rulează” și „calea de configurare reală”:

CVE	Etichetele din amonte au afectat versiunile	Versiune fixă etichetată oficial
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ sau 1.31.7+, în cadrul filialelor lor respective
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	La fel ca mai sus
CVE-2026-97205	0.8.11–1.31.6	La fel ca mai sus
CVE-2026-95101	1.25.0–1.31.6	La fel ca mai sus
CVE-2026-97629	1.23.2–1.31.6	La fel ca mai sus

CVE-2026-93479 are limite specifice pentru versiunea introductivă; nu fiecare versiune veche a NGINX este afectată de această regresie. Versiunile mai vechi din afara acestor intervale pot fi încă afectate de vulnerabilitatea anterioară map regex CVE-2026-42533. S1

3.3 Ubuntu: backport-uri de distribuție (USN-8955-1)

Canonical USN-8955-1 26 octombrie 2026 oferă o actualizare de securitate pentru patru versiuni Ubuntu: S13

Versiunea Ubuntu	nginx și aceeași versiune fixă a pachetului sursă	Descriere
22.04 LTS	1.18.0-6ubuntu14.22	Este un backport pentru furnizor; numărul versiunii din amonte arată în continuare 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	La fel ca mai sus
26.04 LTS	1.28.3-2ubuntu1.12	La fel ca mai sus
26.10	1.30.4-7ubuntu1.1	La fel ca mai sus

Anunțul conține versiuni fixe corespunzătoare ale pachetelor omoloage, cum ar fi nginx-core, nginx-extras, nginx-full și nginx-light. Nu trageți concluzii dacă să o remediați din partea din amonte afișată doar de nginx -v. cum ar fi Ubuntu 24.04 și 1.24.0-2ubuntu7.19 au fost corectate de acest furnizor, dar 1.24.0 din orice sursă nu este în mod inerent sigur.

Ubuntu oficial, de asemenea, a marcat clar că CVE-2026-95101 afectează doar Ubuntu 26.04 / 26.10 , și CVE-2026-97629 afectează doar Ubuntu 24.04 / 26.04 / 26.10. Iată Ubuntu ambalajul propriu și domeniul funcțional, care nu poate fi promovat direct la alte distribuții. S13

3.4 Debian: Diferențele dintre versiuni trebuie verificate separat

Avizul Debian DSA-6575-1 (2026-10-21) acoperă aceste cinci CVE și identifică pachetul fix nginx pentru Debian 13 / trixie ca:

1.26.3-3+deb13u10

Cu toate acestea, la momentul verificării acestui raport, 1.22.1-9+deb12u10 pentru Debian 12 / bookworm este încă semnalat ca vulnerabil de către Debian Security Tracker. Prin urmare:

• Debian 13 Doar actualizați și acceptați conform DSA-6575-1.
• Debian 12 trebuie să verifice corecturile de securitate furnizate de Security Tracker sau furnizorul ELTS una câte una; înainte ca remedierea să fie confirmată în anunț, nu declarați că toate cele cinci elemente au fost remediate pe baza succesului apt upgrade.
• Pachetul sursă Debian poate conține un set de corecții independent de numărul versiunii nginx.org. Pentru versiunile personalizate, trebuie să verificați setul complet de corecții ale pachetului de cod sursă și nu puteți doar să copiați un singur commit din amonte și să îl considerați complet.

Distincția de mai sus se bazează pe înregistrările de urmărire DSA și CVE. S14S15S16

3.5 NGINX Plus, njs și controler de intrare

Produse/Componente	Puncte cheie pentru selecția și verificarea securității
NGINX Plus (versiunea comercială)	Vă rugăm să consultați anunțul și instrucțiunile de actualizare ale filialei Plus corespunzătoare lui F5. Cel mai recent CR la momentul verificării este PLS.37.2.0.1, iar versiunea de securitate a LTS este PLS.37.0.7.1; versiunea Plus și backport-ul inclus nu pot fi înlocuite direct de pragul 1.30/1.31 al Open Source. S19
njs / ngx_http_js_module	2026-10-14 lansează njs 1.0.2 și remediază CVE-2026-101019 și CVE-2026-101025; dacă utilizați njs, trebuie să verificați și compatibilitatea modulului cu NGINX. S20
F5 NGINX Controller de intrare / Fabrică de gateway	Nucleul NGINX este un lanț de distribuție de software conex, dar independent. Remediați vulnerabilitățile relevante cu controlerele, imaginile și notele de lansare ale acestora. Nu puteți înlocui pur și simplu un binar NGINX în Pod.
Kubernetes Comunitate kubernetes/ingress-nginx	Proiectul este dezafectat în martie 2026 și nu va mai asigura o nouă întreținere de securitate. Ar trebui să plănuiți să migrați la un controler întreținut sau la Gateway API, în loc să confundați numărul de lansare cu F5 NGINX Controller de intrare. S21

3.6 Ce patch ar trebui să alegeți de fapt?

Formular de desfășurare	Practici recomandate	Dovada reparatiei
Pachetul oficial DEB/RPM nginx.org	Faceți upgrade la versiunea fixă a ramurii din amonte	nginx -v/-V, sursa pachetului, anunț oficial de securitate
Ubuntu/Debian depozit oficial	Instalați pachetele de securitate ale furnizorului	Versiunea pachetului complet + starea USN/DSA de furnizor + CVE
RHEL/Alma/Rocky/SUSE/Alte distribuții	Actualizați în funcție de buletinele de securitate specifice distribuției și versiunile de pachete	Furnizorul corespondent CSAF/anunț, versiunea Ubuntu/Debian nu poate fi aplicată
Imagini de containere oficiale sau personalizate	Reconstruiți sau trageți imaginea de reparație verificată și înlocuiți-o în mod continuu	Rezumat imagini, construiți SBOM, rulează ID-ul imaginii pod/container
NGINX, OpenResty, Tengine autocompilate sau versiuni corectate cu module terțe	Prioritizează utilizarea versiunii de securitate completă a întreținătorului; efectuați backport-uri de corecție revizuite pentru arborele sursă țintă atunci când este necesar	Cinci remedieri de vulnerabilități, compatibilitate ABI/module, regresie unități și afaceri

OpenResty și Tengine sunt sisteme de eliberare diferite; acest tabel descrie doar metoda de verificare. nu înseamnă că toate versiunile sale sunt afectate în același timp cu standardul NGINX și nici patch-ul de cod din amonte nu poate fi aplicat necondiționat.

4. Procesul formal de reparare

4.1 Inventarul cazurilor reale de primire a traficului extern

Colaționați pentru fiecare intrare cel puțin:

• Numele domeniului, echilibrarea încărcăturii/CDN/link proxy Edge, metoda de expunere a site-ului de origine și protocolul de rețea utilizat.
• Produse NGINX (Open Source, Plus, Ingress etc.), versiunea completă, sursa depozitului de pachete, imagine digest.
• nginx -V afișează modulele de construcție și parametrii de compilare; dacă există module dinamice njs, Lua, OpenResty și terțe părți.
• Funcționează real master/worker PID, unitate de service/container/pod, replică și nod Worker.
• Configurațiile efective efective http/stream, server, location, include.
• Dacă se activează HTTP/3, mTLS, SSI/AIO, calea dinamică a jurnalului, map complexă și captarea regex.

Nu verificați doar /etc/nginx/nginx.conf implicit. Mediul de producție încarcă adesea mai multe site-uri, TLS și configurații de module prin include. De asemenea, pot exista mai multe căi de instalare NGINX sau mai multe straturi proxy.

4.2 Verificați informațiile despre versiune și compilare

# 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 raportează construirea binarului găsit pe calea liniei de comandă; nu dovedește că worker care rulează l-a încărcat. nginx -v poate omite sufixul pachetului complet al distribuției, așa că verificați și înregistrările managerului de pachete sau ale lanțului de aprovizionare.

4.3 Exportați configurația efectivă și efectuați prima rundă de screening statice

nginx -T va testa configurația și va elimina configurația îmbinată. Ieșirea poate conține informații sensibile, cum ar fi acreditările de autentificare, căile cheilor, numele gazdei interne etc. Se recomandă salvarea terminalului controlat cu permisiuni root și permisiuni pentru fișiere private și să nu postați fișierele originale în comenzile publice de lucru:

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

Acesta este doar localizatorul de cale candidat, nu un instrument de determinare automată CVE de încredere:

1. grep nu poate determina dacă variabilele se află în același location sau în același lanț de evaluare a cererilor și nici nu poate deduce relația de moștenire a configurației.
2. proxy_request_buffering on, unele configurații de cache și bilete au valori implicite, iar nescrierea instrucțiunilor corespunzătoare nu înseamnă că riscul dispare.
3. Configurațiile generate de proxy invers, CDN, sidecars container sau controlere pot diferi de fișierele inspectate manual.
4. Este posibil ca caracteristicile modulelor NGINX Plus și ale modulelor dinamice să fie confirmate utilizând instrumentele de management oficiale respective.

4.4 Implementați remedierea prin canale de încredere

Debian/Ubuntu (magazin oficial de distribuție):

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

Acest set de comenzi nu poate genera soluții de securitate din aer care nu sunt încă disponibile. În special pentru Debian 12, dacă pachetul actualizat este încă considerat vulnerabil de sistemul de urmărire a securității, sunt necesare măsuri suplimentare de reparare, izolare sau migrare a furnizorului. S13S14S15

Pachetul oficial nginx.org:

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

Dacă utilizați OpenResty, Tengine sau NGINX Plus autocompilat, utilizați versiunea de corecție acceptată de întreținătorul corespunzător și nu amestecați pachetele nginx.org, de distribuție și de depozite terță parte. Binarele/imaginile originale, configurațiile, semnăturile și manifestele de implementare rollback ar trebui păstrate.

Containers/Kubernetes: actualizați imaginea imuabilă, înregistrați rezumatul acesteia și înlocuiți toate replicile vechi cu o lansare în etape. kubectl rollout status confirmă doar faptul că controlerul de implementare s-a terminat; verificați, de asemenea, rezumatele imaginilor, rutarea de intrare și replicile nesănătoase.

4.5 Verificați configurația și înlocuiți vechiul 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'

Nu tratați nginx -s reload ca o dovadă că rulează un nou binar: reîncărcările obișnuite ale configurației permit vechiului master să înceapă noi lucrători fără a-și înlocui executabilul. NGINX acceptă o procedură de actualizare binară online dedicată, dar necesită pași suplimentari și verificare. Fără o procedură stabilită, utilizați un comutator de trafic de mare disponibilitate urmat de o repornire a serviciului sau lansați containere de înlocuire. S22

Dacă gestionați NGINX prin socket-ul systemd, script de intrare container sau instalări multiple, ar trebui să verificați ținta reală de lansare și calea procesului în loc să presupuneți direct că systemctl restart nginx acoperă toate instanțele.

4.6 Acceptați și faceți regresia afacerii de la intrarea externă reală

Se recomanda efectuarea cel putin:

• Sunt corecte HTTPS-ul normal, rutele rescrise, resursele statice și paginile de mapare alias.
• Distribuția obișnuită map, calea variabilă root, calea jurnalului de acces, rutarea SNI/certificat și proxy Stream sunt corecte.
• Încărcările normale, încărcările fragmentate, solicitările API și limitele de volum în amonte pentru HTTP/3 (când sunt activate) sunt în continuare conform așteptărilor.
• mTLS: Solicitările de certificate legitime ar trebui să aibă succes; certificatele lipsă, expirate sau neautorizate ar trebui în continuare respinse, iar reluarea/reconectarea TLS nu ar trebui să modifice accidental permisiunile.
• Dacă pagina SSI și accesul la fișiere asincron sunt normale; jurnalul de erori nu arată solicitări anormale pentru referințe de memorie sau blocări repetate Worker.
• După schimbarea traficului, procesul de versiune veche și replica veche a imaginii ar fi trebuit să iasă.

Testarea trebuie efectuată în mediu propriu sau autorizat. Testul de fum la cererea normală nu poate dovedi singur că vulnerabilitatea memoriei a fost remediată; în cele din urmă, versiunea fixă ​​a furnizorului, patch-ul codului sursă și testul de rulare trebuie să fie acceptate în comun pentru acceptare.

5. Măsuri de atenuare atunci când actualizarea imediată nu este posibilă

Această secțiune este o opțiune de reducere a riscurilor, nu o înlocuire a plasturelui. Toate modificările temporare ale configurației ar trebui să fie copiate de rezervă, executate nginx -t, eliberate în loturi și anulate rapid dacă este necesar. S3S4

5.1 Controlați prioritatea traficului pe baza expunerii externe

Prioritizează reducerea suprafeței de atac a serviciilor care nu pot fi actualizate în timp: pe suprafața de management și API internă Adăugați controlul accesului la sursă de încredere, izolarea rețelei în amonte sau offline pe termen scurt; adăugați limite de conexiune, de solicitare și de tarif la intrările cu risc ridicat; asigurați-vă că autentificarea sursă are loc la NGINX legate de intrare înainte de lanțul de procesare a cererii. Trebuie remarcat faptul că majoritatea vulnerabilităților în sine sunt localizate în NGINX În interiorul planului de date, este posibil ca regulile tradiționale WAF să nu determine cu exactitate condițiile de declanșare a configurației personalizate.

5.2 alias / rewrite: evitați evaluarea $request_filename după rescriere

Se recomandă verificarea și reglarea:

• Încercați să nu efectuați rewrite care va schimba URI în același timp cu location folosind alias.
• Evitați să utilizați $request_filename când URI a fost rescris, dar potrivirea corectă a poziției nu a fost încă finalizată.
• Verificați referințele la variabile indirecte în return, set, if, add_header, formatul jurnalului de acces și includeți fișierele.
• Folosiți clar root/try_files/independent location atunci când afacerea o permite, dar schimbă numai alias în root. De asemenea, poate schimba semantica căii fișierului, care trebuie verificată unul câte unul.

Nu copiați direct „șablonul de rescriere sigur” obișnuit pe Internet pentru a suprascrie configurația existentă. Diferitele prefixe location și ținte de rescriere au ca rezultat îmbinarea căilor cu semnificații complet diferite. S5

5.3 map/Regex: Reduceți amestecarea stărilor variabile de captare

Este recomandat să prioritizați capturile cu nume și să limitați domeniul de propagare a acestora, mai degrabă decât să permiteți reutilizarea captărilor anonime, cum ar fi $1, pe diferite căi de evaluare regex în timp. De exemplu:

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

Acest fragment demonstrează doar o structură mai ușor de auditat a proprietății variabilelor; nu înseamnă că s-a dovedit că elimină în mod independent toate căile de declanșare CVE-2026-93479 către. În special, verificați dacă variabilele de captare sunt referite în avans de către alte root sau log_format și dacă există volatile, căi dinamice și lanțuri de evaluare interdependente. F5/CERT recomandă utilizarea captării denumite și limitarea domeniului de utilizare la configurația de potrivire obișnuită corespunzătoare ca o ușurare pe termen scurt. S3S6

5.4 AIO + SSI: Opriți combinațiile de funcții inutile

Pentru servere/căi care nu necesită SSI sau I/O pentru fișiere asincrone, utilizați:

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

Din perspectiva condițiilor de declanșare a vulnerabilității, închiderea unuia dintre cele două este de obicei suficientă pentru a elimina lanțul specific descris; închiderea în același timp este aplicabilă doar scenariilor în care afacerea nu se bazează pe această capacitate. Verificați include virtual, subcereri, cache și comportamentul pool-ului de fire; când încărcarea proxy inversă este mare, închiderea AIO poate modifica latența și performanța I/O. S7

5.5 HTTP/3 Solicitați injecție corporală: închideți temporar intrarea dacă este necesar

Dezactivați quic ascultător implicând HTTP/3 , anulați Alt-Svc antet de răspuns care anunță HTTP/3 și verificați dacă stratul de margine/echilibratorul de încărcare mai trimite QUIC solicită direct către cei nereparați 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 等配置保持不变
}

Cele de mai sus sunt doar o descriere a diferenței de modificare, nu o configurație completă a serverului care poate fi activată individual. Sintaxa de setare a lui HTTP/2 este legată de versiunea NGINX; dacă trebuie să păstrați HTTP/2, ar trebui să utilizați http2 on; sau sintaxa validă existentă în conformitate cu versiunea corespunzătoare și să verificați cu nginx -t. trebuie să fie îmbinat cu configurația serverului existent înainte de implementare, în loc să înlocuiască întreaga secțiune cu această secțiune. de asemenea, verifică paravanul de protecție UDP 443, locația de terminare HTTP/3 și calea de rezervă a clientului a CDN/proxy frontal.

Un alt tip de atenuare pe termen scurt este utilizarea proxy_request_buffering off; pe calea proxy afectată, dar acest lucru va schimba comportamentul fluxului în flux al corpului cererii în amonte, încercările de eșec și unele fluxuri de lucru de încărcare; poate fi utilizat numai după teste suficiente și după confirmarea faptului că directiva atinge calea proxy HTTP/3 afectată. S8S18

5.6 TLS Tichet de sesiune: Protecție prioritară mTLS Limită de autentificare

Dacă actualizarea nu este posibilă și instanța se bazează pe memoria cache de sesiune partajată + rotația automată a cheii de bilet, evaluați:

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

Acest lucru poate dezactiva mecanismul TLS Session Ticket, eliminând astfel calea de falsificare a biletului descrisă în această vulnerabilitate; cu toate acestea, poate afecta performanța reluării sesiunii. Nu puteți dezactiva pur și simplu verificarea certificatului clientului mTLS pentru a „evita vulnerabilitățile”, deoarece aceasta va șterge direct limita de autentificare inițială. S9S12

Fișierele ssl_session_ticket_key explicite și rotația securizată pot fi folosite și de procesele profesionale de management TLS pentru a evita condițiile generate automat, dar custodia cheii, distribuția completă a nodurilor, rotația și ciclurile de viață vechi ale biletelor trebuie să fie auditate cu atenție. Nu este recomandat să codificați o cheie reutilizabilă pe termen lung în configurația web obișnuită sau scripturi pentru urgențe temporare. Serviciile critice care utilizează mTLS ar trebui monitorizate suplimentar pentru comportamentul de reluare a sesiunii TLS și respingerea cererilor fără un certificat de client valid. S12

5.7 Rolul sistemului de operare și al protecției frontierelor

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

ASLR, lucrătorii non-root, sistemele de fișiere container numai pentru citire, permisiunile minime pentru fișiere și izolarea rețelei pot reduce impactul potențialului RCE. ASLR nu remediază depășirile de heap sau UAF și nu poate garanta că lucrătorii nu se vor prăbuși. WAF, limitele ratei și limitele dimensiunii corpului cererii nu fixează TLS Sincronizarea cheii biletului. S4

5.8 Neînțelegere frecventă: Aceste operațiuni nu sunt suficiente pentru a finaliza reparația

Operații comune	De ce este insuficient?
„nginx -v arată relativ nou”	Ramura căreia îi aparține, versiunea completă a pachetului backported a versiunii de lansare și procesul online nu sunt verificate.
„Doar unul dintre intraneturi a fost actualizat”	Vechea instanță de origine Worker/container vechi/vechea instanță de origine CDN încă primește solicitări
„Site-ul nu folosește PHP/etichete dinamice”	Defectul apare în calea de bază NGINX sau în analiza protocolului și nu se bazează pe execuția PHP.
„Deschiderea WAF/Cloudflare este suficientă”	Nu se poate dovedi că WAF blochează toate erorile de memorie NGINX dependente de configurație sau defectele de reluare TLS
„S-a deschis deja ASLR”	Doar profitând de reducerea dificultăților; DoS cu injecție la cerere este încă posibilă
„HTTP/3 nu este expus la rețeaua publică, așa că nu este nevoie deloc de upgrade”	Celelalte patru CVE necesită încă o evaluare independentă; și pot exista conexiuni directe cu origini ascunse
„Vulnerabilitatea map din iulie a fost remediată”	Octombrie CVE-2026-93479 implică probleme de regresie ulterioare de evaluare a scriptului
„Dezactivarea memoriei cache rezolvă toate problemele”	Afectează doar unele scenarii cache TLS sau AIO și nu acoperă alias, script, HTTP/3

6. Idei de implementare a corecțiilor oficiale și puncte de revizuire

Această secțiune urmează remedierile NGINX din amonte din octombrie 2026. Fragmentele ilustrează modificări reprezentative pentru revizuirea patch-urilor; nu sunt remedieri complete, compilabile independent. Pentru versiuni personalizate, examinați commit-urile complete, codul și testele din jur și preferați o versiune completă acceptată. S5S6S7S8S9

6.1 CVE-2026-15176: URI a fost rescris pentru a include condițiile de respingere a mapării căilor alias

Comitarea din amonte a modificat ngx_http_map_uri_to_path() în src/http/ngx_http_core_module.c:

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

focus de revizuire: Calea sistemului de fișiere nu poate fi calculată în continuare când URI s-a schimbat, dar semantica locației corespunzătoare a lui alias nu mai este de încredere. Aceasta este o îmbunătățire a constrângerii pre-state. Nu este o simplă verificare dacă cererea URI conține caractere ilegale. S5

6.2 CVE-2026-93479: distingeți corect între lungimea datelor de ieșire și lungimea rezervată

Commiterea în amonte actualizează src/http/ngx_http_script.c și src/stream/ngx_stream_script.c în același timp. Intenția de bază poate fi rezumată astfel:

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

Aici, pool este un nume de parametru ilustrativ: expresiile reale de alocare HTTP și Stream diferă. Modificarea calculează mai întâi lungimea de ieșire a scriptului, apoi adaugă lungimea rezervată la alocarea finală, astfel încât rezultatul să nu suprascrie spațiul rezervat. S6

La auditare și backporting, trebuie acoperit și evaluatorul corespunzător HTTP/Stream; doar verificarea fișierului de sintaxă de configurare al lui map nu poate dovedi că defectul a fost remediat.

6.3 CVE-2026-97205: Setați pragul de siguranță pentru numărul de operațiuni asincrone pe 8 biți

În amonte adăugat la src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

Și adăugați intrări similare la citirea fișierelor asincrone, așteptarea cache-ului, filtrarea ieșirii și operarea firului:

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

Focus focus: Toate căile de cod reale care vor adăuga r->main->blocked trebuie acoperite. Nu puteți doar să scrieți constanta de prag în fișierul antet. Backport trebuie, de asemenea, să verifice coordonarea completă a rezervării sincrone, a apelului asincron și a revenirii erorilor pentru a se asigura că blocajul sau scurgerea de referință nu va fi cauzată de respingerea directă a sarcinilor. S7

6.4 CVE-2026-95101: Mențineți starea skip separat pentru cadre necunoscute

În amonte adaugă câmpul skip în structura de stare a parserului HTTP/3 și efectuează separarea stării:

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);

Cheia nu este „dezactivarea cadrelor HTTP/3 necunoscute”, ci asigurarea faptului că, în mai multe citiri, numărul de octeți omisi și lungimea sarcinii utile DATA sunt întotdeauna gestionate de stări independente. Recenziile ar trebui să se concentreze pe fragmentarea încrucișată a bufferului de cadre necunoscute și pe eventuala consistență a client_max_body_size. S8

6.5 CVE-2026-97629: Sincronizați matricea completă de sloturi pentru chei TLS

Modificările din amonte se află la 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));

Imaginea originală conținea trei sloturi pentru chei, dar numai primele două au fost copiate. În schimb, sincronizați pe baza numărului real de elemente ale matricei pentru a vă asigura că setul de chei de vot din Worker este în concordanță cu memoria partajată. Când revizuiți, confirmați, de asemenea, că alocarea matricei, inițializarea, blocarea partajată și logica de rotație sunt consecvente, mai degrabă decât să verificați o singură dată modificarea lungimii memcpy. S9

6.6 De ce nu este recomandat să aplicați doar fragmente de patch împrăștiate?

Aceste cinci modificări se întind pe src/http, src/stream, src/http/v3 și, respectiv, src/event, iar versiunile mai vechi pot avea backport-uri de securitate și extensii neoficiale. Backporting-ul ar trebui să formeze următoarea matrice de verificare:

Verificați obiectul	Ce trebuie confirmat
sursa de patch-uri	Trimitere oficială, versiune țintă potrivită, corecție completă și verificare a semnăturii
Set original de patch-uri	Nu intră în conflict cu modificările istorice, cum ar fi CVE-2026-42533, backport de distribuție etc.
calea codului	Scriptul HTTP + Stream, AIO/thread, HTTP/3, OpenSSL Biletul sunt toate acoperite
Compilat compatibil	OpenSSL, PCRE, modulul ABI, modulul dinamic și dependențele de legătură sunt consecvente
regresie funcțională	alias rescriere, jurnal dinamic, SSI/AIO, HTTP/3 încărcare, mTLS reluarea sesiunii
timpul de rulare	Toate Worker/Pod-urile rulează versiuni noi verificate, nu rămân imagini vechi

Pentru echipele care își mențin propriile versiuni, se recomandă să păstreze ID-uri de corecție auditabile, versiuni de pachete, jurnale de compilare și rapoarte de regresie pentru fiecare CVE; pentru operarea și întreținerea obișnuită, cea mai sigură soluție este instalarea actualizărilor complete de securitate ale furnizorului.

7. Vulnerabilitatea istorică înapoi, ramuri vechi și alte produse

7.1 NGINX vulnerabilitate de bază demnă de confirmare simultană din mai până în septembrie 2026

Multe instanțe NGINX care nu au fost actualizate de mult timp nu sunt doar afectate de noua problemă din octombrie. Următoarele sunt nodurile de reparații reprezentative în viitorul apropiat: S1S2

CVE	Prima ediție a remedierii	Riscuri cheie și condiții care necesită audit
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, 13 mai	rewrite Logica de captare și înlocuire a expresiilor regex anonime declanșează depășirea heap-ului, potențial RCE; există rapoarte publice despre încercări de atac în sălbăticie
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, 22 mai	Capturarea regex și estimarea lungimii suprapuse în rewrite duc la depășire
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, 17 iunie	HTTP/2 Configurație specifică pentru amonte sau gRPC, condiția antetului de cerere mare declanșează depășirea tamponului
CVE-2026-42530	Mainline 1.31.2, 17 iunie	HTTP/3 Utilizare-după-gratuit; marca oficială afectată zona 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, 15 iulie	Evaluarea variabilei de capturare map + regex provoacă depășirea grămezilor, iar patch-urile ulterioare au o corelație de regresie cu CVE-2026-93479 în octombrie
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, 15 iulie	ngx_http_slice_module Conținutul de memorie s-a scurs în anumite condiții de actualizare a variabilelor și a memoriei cache
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, 15 iulie	SSI este legat de UAF; nu este aceeași cauză root ca și vulnerabilitatea de numărare AIO din octombrie
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, 15 septembrie	Depășire limitată de heap de HTTP/3 + combinație specifică de versiuni OpenSSL, manifestată în principal ca blocare/corupție limitată a memoriei

Alte vulnerabilități, cum ar fi NGINX Core, HTTP/2, charset și SMTP anunțate în 2026, ar trebui, de asemenea, investigate conform buletinelor oficiale de securitate; acest tabel se concentrează în mod intenționat pe evenimentele tipice care sunt cele mai relevante pentru actualele implementări de proxy invers public NGINX și au implicații privind siguranța memoriei sau integritatea solicitărilor. nu sunt toate CVE-urile în 2026. Lista. S1

De ce să acordați o atenție deosebită lui CVE-2026-42945

Există buletine de securitate de la agențiile guvernamentale care înregistrează activități de exploatare în sălbăticie și informații despre codurile de exploatare publică pentru această vulnerabilitate rewrite în luna mai. Prin urmare, pentru cazurile care nu au fost corectate de mult timp din mai până în prezent și au deschise rescrieri complexe ale expresiilor regulate în rețeaua publică, pe lângă finalizarea reparației, ar trebui să fie revizuite suplimentar și blocarea anormală Worker, jurnalele de acces și modificările suspecte la acel moment. S23

„A avut loc o tentativă de atac” nu dovedește automat că atacatorul a executat în mod fiabil comenzi pentru fiecare țintă; atunci când este implicat răspunsul la incident, indicatorii de compromis și blocările de proces ar trebui investigate separat de dovezile adevărate ale escaladării sau persistenței privilegiilor.

7.2 Remediere pentru versiuni mai vechi și backport-uri de distribuție

NGINX Diferitele ramuri au propriile cicluri de suport și timpi diferiți de introducere a vulnerabilităților. Cele cinci noi patch-uri nu pot fi implementate în toți arborii sursă timpurii fără revizuire.

scena	Strategia recomandată
Versiunea de lansare a anunțat corecții de securitate complete	Utilizați pachete de furnizor și documentați versiunile de pachete complete; evitați înlocuirea cu binare goale în amonte incompatibile
Debian 12 și alte versiuni afectate care nu sunt încă acoperite de toate CVE-urile din acest lot	Trimiteți comenzi de lucru cu risc, limitați expunerea externă și verificați starea furnizorului/ELTS; migrați sau utilizați un lanț de eliberare de întreținere verificabil atunci când este necesar
Ramuri istorice care au încetat suportul în amonte	Prioritizează migrarea către versiunile acceptate; dacă este necesară backporting-ul pe termen scurt, întreținătorii vor evalua dependențele și compatibilitatea patch-urilor și vor scrie teste complete.
Vine cu furcă NGINX (OpenResty, Tengine, gateway personalizat)	Mai întâi determinați dacă este inclusă calea codului corespunzătoare și apoi utilizați declarația de securitate a întreținerii furcăturii. Nu poate fi echivalent direct cu versiunea din amonte.
Patch-urile de securitate duc la modificări ale funcționalității afacerii	Adoptarea lansărilor în etape, schimbarea traficului între versiuni și adaptarea configurației; nu este adecvată restaurarea versiunii nefixate a rețelei publice fără izolare.

7.3 Remediere separată pentru njs, Ingress și NGINX Core

• njs: Pe lângă programul principal NGINX, trebuie să verificați și versiunea modulului JavaScript NGINX în sine. njs 1.0.2 remediază o problemă de epuizare a memoriei de analiză XML din octombrie 2026 și o problemă de inconsecvență a validării XML cu atributele de referință ale entității. Pentru implementările asociate cu verificarea semnăturii XML folosind nginx-saml, ar trebui să citiți în continuare instrucțiunile oficiale njs pentru scenariile de plug-in. S20
• F5 NGINX Plus / NGINX Ingress Controller: În plus, controlerul și Gateway Fabric pot avea fiecare buletine de securitate suplimentare, versiuni diferite de ambalare și vulnerabilități unice de politică. Actualizarea unui strat nu înseamnă actualizarea automată a altui strat. S19
• Comunitatea Kubernetes ingress-nginx: Oficialii Kubernetes au anunțat deja că controlerul a oprit întreținerea în martie 2026, iar depozitul său nu poate fi confundat cu controlerul F5. Companiile afectate ar trebui să planifice o migrare fără probleme și să verifice adnotările de intrare și diferențele semantice Gateway API în loc să aștepte o nouă versiune de securitate. S21

8. Criterii de acceptare și inspecții ulterioare

Se recomandă ca următoarea listă să fie utilizată ca condiții de acceptare pentru modificarea comenzilor de lucru:

Proiect	Standarde de calificare	Dovezi care pot fi reținute
Acoperire a activelor și a portalului	Toate instanțele externe și conectate direct care pot ocoli CDN au fost inventariate.	Nume de domeniu, LB, IP, Pod/listă de containere
Sursa pachetului și domeniul de reparație	Utilizați versiunile confirmate pentru a acoperi toate CVE aplicabile	Aviz de securitate în amonte, USN/DSA, versiunea pachetului, imagine digest
ieșiri de proces vechi	Toate vechile master/worker/containere au fost înlocuite	PID/ora de pornire, starea de implementare continuă, imagine de rulare
Auditul configurației	Combinațiile cu risc ridicat au fost eliminate sau acoperite de patch-uri, iar relațiile de moștenire au fost verificate	rezumatul redactat și înregistrarea de audit a nginx -T
TLS/mTLS	Certificatele de încredere trec; certificatele invalide sau lipsă sunt respinse; reluarea sesiunii nu ocolește autentificarea	Test de autorizare negativ/pozitiv, rezultate controlate ale testului TLS
Corpul cererii HTTP/3	Activare cale fixă; Corpul cererii din amonte și throttlingul se comportă corect	HTTP/3, încărcare proxy, test de regresie a limitei de volum
SSI/AIO	Funcția îndeplinește cerințele, Worker nu are o întrerupere anormală	Monitorizarea regresiei în afaceri, a erorilor și a ratei de eroare
Monitorizarea functionarii si intretinerii	Nicio excepție evidentă 5xx, SIGSEGV, proces se iese în mod repetat	Indicatori de service și jurnalele înainte și după modificări
Strategia de rollback	Dacă este necesară derularea, mai întâi limitați expunerea și păstrați limitele de securitate	Modificarea comenzilor, a fluxurilor de urgență și a planurilor de carantină
ciclul de viață ulterior	Determinați abonamentele la buletinele de securitate, frecvența de actualizare a containerelor și planurile de migrare a filialelor	Actualizați registrul, persoana responsabilă și următoarea dată de audit

8.1 Pe ce ar trebui să vă concentrați în jurnalele și starea de rulare?

Depanați anomaliile de pe serverele care au fost expuse de mult timp worker process exited on signal 、 SIGSEGV , vârfurile de eșec la solicitare, agregarea anormală a accesului la sursă, TLS reluarea/succesul autentificării sesiunii și comportamentul anormal al corpului cererii de backend. Acești indicatori pot fi utilizați doar ca indicii de investigație și nu sunt dovezi suficiente pentru a demonstra în mod direct că un anumit CVE a fost exploatat. ;Lipsa jurnalelor relevante nu dovedește că nu a avut loc un atac.

8.2 Formulare recomandată pentru concluzia finală a riscului

Raportul de acceptare pentru mediul de producție trebuie să utilizeze următoarea expresie precisă:

NGINX au fost identificate intrarea în serviciul extern și sursa pachetului software. Toate instanțele aplicabile au fost actualizate la versiunea oficială de securitate din amonte sau backport-ul confirmat de furnizorul lansării a fost finalizat; vechiul Worker și containerele vechi au fost înlocuite. Aliasul/rescrierea/harta, AIO/SSI, corpul solicitării HTTP/3 și configurațiile asociate Tichet de sesiune TLS/mTLS au fost auditate și au trecut testul funcțional, autentificarea și integritatea solicitării de regresie. Pentru cazurile care nu au finalizat încă actualizarea, înregistrați suplimentar zonele de expunere, măsurile de compensare, persoanele responsabile și termenele de finalizare.

Dacă patch-ul pentru Debian 12 sau alte versiuni este încă incomplet, nu este adecvat să judecăm întregul formular de acceptare ca fiind „completat”; CVE nerezolvat, dacă există o configurație de declanșare corespunzătoare, starea de izolare și ruta finală de actualizare ar trebui să fie înregistrate clar.

---

Anexă: Surse și link-uri citate

Descriere: numerele [Sx] din text corespund în mod uniform acestei secțiuni. Următoarele acordă prioritate anunțurilor de securitate a proiectelor din amonte, comenzilor de cod, anunțurilor de eliberare a furnizorilor și informațiilor agenției naționale de securitate. Severitatea vulnerabilităților citate este descrisă în funcție de criteriile de rating ale fiecărei organizații emitente; data verificării datelor este 27 octombrie 2026.

S1 — NGINX Open Source Buletin oficial de securitate

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

Conține versiunile din amonte afectate, ramurile de remediere și nivelurile oficiale de severitate a cinci CVE-uri din octombrie și acoperă, de asemenea, vulnerabilitățile istorice până în 2026.

S2 — NGINX înregistrarea de lansare a versiunii oficiale

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

Confirmați 1.30.6 / 1.31.7 pentru 2026-10-14, 1.31.8 pentru 2026-10-21 și etapele de lansare de securitate critice din mai până în septembrie.

S3 - Agenția de securitate cibernetică din Singapore: F5 NGINX Trei vulnerabilități critice

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

Descrierea scorurilor CVSS v4.0 9.2, condițiile de configurare necesare și recomandările intermediare de atenuare pentru CVE-2026-15176, CVE-2026-93479 și CVE-2026-97205.

S4 - NHS Anglia: F5 NGINX Aviz de risc ridicat

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

Descrie impactul DoS / potențial RCE al problemelor de siguranță a memoriei și constrângeri precum ASLR dezactivate sau ocolite.

S5 — Sursa oficială confirmată: CVE-2026-15176

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

Corespunde cu verificarea stării alias și r->uri_changed în ngx_http_map_uri_to_path().

S6 — Sursa oficială confirmată: CVE-2026-93479

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

Corespunzător lungimii scriptului HTTP/Stream și logicii de alocare a bufferului rezervat.

S7 - Sursa oficială confirmată: CVE-2026-97205

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

Corespunde cu pragul de numărare r->main->blocked NGX_HTTP_MAX_BLOCKED 250 și cu calea de rezervă asincronă.

S8 — Sursa oficială confirmată: CVE-2026-95101

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

Separarea stării corespunzătoare lungimii rămase a cadrului necunoscute HTTP/3 și lungimea corpului cererii DATA.

S9 — Sursa oficială confirmată: CVE-2026-97629

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

Corespunde tuturor sloturilor cheie în timpul sincronizării TLS Rotație Ticket de sesiune.

S10 — F5: CVE-2026-15176 Anunțul furnizorului

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

Listați factorii de declanșare, cum ar fi alias, rewrite, $request_filename și jurnalele de acces.

S11 — F5: CVE-2026-93479 Anunț furnizor

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

Listați captarea expresiilor regex ale hărții, calea root și condițiile de evaluare a variabilelor de jurnal.

S12 — NGINX documentația oficială a modulului TLS/SSL

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

Descriere ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key și autentificare certificat client și alte instrucțiuni.

S13 — Consiliere de securitate: Ubuntu USN-8955-1 (2026-10-26)

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

Furnizați pachetul software complet versiunea fixă și domeniul de distribuție a Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Consiliere de securitate: Debian DSA-6575-1 (2026-10-21)

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

Confirmați pachetul de corecție de securitate 1.26.3-3+deb13u10 pentru Debian 13 / trixie și înregistrați asocierea backport-ului pentru CVE-2026-93479.

S15 — Urmărirea vulnerabilităților: Debian Security Tracker: CVE-2026-15176

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

Folosit pentru a verifica starea remedierii distribuției Debian 12 / bookworm și Debian 13 / trixie. Această stare se poate modifica odată cu actualizările de securitate viitoare.

S16 — Urmărirea vulnerabilităților: Debian Security Tracker: CVE-2026-95101

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

Confirmare suplimentară a stării de securitate a vulnerabilității HTTP/3 pe diferite filiale Debian.

S17 — Consiliere de securitate: Red Hat: CVE-2026-93479

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

Înțelegerea suplimentară a corelației dintre vulnerabilitatea regresiei din octombrie și remedierea pentru iulie CVE-2026-42533.

S18 — NGINX document oficial al modulului proxy invers

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

Interogați semantica și valorile implicite ale configurațiilor precum proxy_request_buffering, client_max_body_size, alias, aio etc.

S19 — NGINX Plus Note oficiale de lansare

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

List Plus CR/LTS ramuri, versiuni, patch-uri și mementouri de compatibilitate de upgrade.

S20 — NGINX JavaScript / njs Buletin oficial de securitate

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

Conține octombrie 2026 njs 1.0.2 și validarea XML aferentă, probleme de epuizare a memoriei.

S21 — Kubernetes: comunitatea ingress-nginx instrucțiuni oficiale de pensionare

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

Rețineți că proiectul a oprit noile versiuni și remedieri de securitate în martie 2026 și este recomandat să migrați controlerul întreținut sau Gateway API.

S22 — NGINX controlul serviciului oficial și instrucțiuni binare de actualizare online

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

Distingeți metodele de reîncărcare a configurației, repornire și actualizare a fișierelor executabile online pentru acceptarea comutării procesului.

S23 - Notificare de securitate guvernamentală: mai 2026 NGINX vulnerabilitate de rescriere

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

Furnizați antecedente de risc istoric și sugestii de actualizare de securitate pentru CVE-2026-42945; judecățile legate de exploatarea în sălbăticie ar trebui să se bazeze pe anunțul agenției la momentul respectiv și pe dovezi suplimentare ale incidentului.

S24 — F5: CVE-2026-95101 și CVE-2026-97629 Anunțuri furnizor

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

Acoperă riscurile de injectare corporală a cererii HTTP/3 și, respectiv, de rotație automată a cheii biletului TLS.

S25 — F5: CVE-2026-97205 Anunțul furnizorului

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

Descriere SSI/AIO declanșează condițiile și potențialele riscuri de corupție a memoriei.

Actualizare de securitate NGINX: verificări de configurare, upgrade și verificare