--- title: "NGINX zəiflikləri: səbəblər, düzəlişlər və istehsal yoxlanışı" description: "Beş oktyabr 2026-cı il NGINX zəifliklərini, onların konfiqurasiya ilkin şərtlərini, filiala xas düzəlişləri, paylama arxa portlarını və istehsalın yoxlanışını nəzərdən keçirin." language: "az" url: "https://keendigit.com/az/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # NGINX zəiflikləri: səbəblər, düzəlişlər və istehsal yoxlanışı Beş oktyabr 2026-cı il NGINX zəifliklərini, onların konfiqurasiya ilkin şərtlərini, filiala xas düzəlişləri, paylama arxa portlarını və istehsalın yoxlanışını nəzərdən keçirin. Tarixi məqalə tarixi: 2026-10-14 (açıqlama və təhlükəsizlik buraxılış tarixi). Mənbələr yoxlanılıb və məlumatlar 2026-10-27 vasitəsilə əlavə edilib. Bu məqalə hadisə tarixinə görə arxivləşdirilmişdir; 14 oktyabrdan sonra buraxılmış versiya və buraxılış yeniləmələri aşağıda verilmişdir. Auditoriya: NGINX Open Source / NGINX Plus veb-saytı və əks proksi əməliyyat və texniki xidmət işçiləri, təhlükəsizlik cavabdehləri, paylama xidmətçiləri, həmçinin NGINX-ni özü tərtib edən və üçüncü tərəf modullarını saxlayan mühəndislər. Bu məqalə 14 oktyabr 2026-cı il tarixində açıqlanmış və intensiv şəkildə düzəldilmiş beş NGINX əsas zəifliyinə diqqət yetirir, həmçinin 2026-cı ilin may-sentyabr ayları arasında təmsil olunan yaddaş təhlükəsizliyi və tələb bütövlüyü zəifliklərinə nəzər salır. Məzmun trigger şərtləri, kod səviyyəli səbəblər, qısamüddətli təsir tədbirləri, bərpa işlərinin əhatə dairəsi və bərpa işlərini əhatə edir. həyata keçirilməsi, köhnə filiallara məlumat verilməsi və istehsalın yoxlanılması. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1) kimi istinadlar mənbə əlavəsinə keçid verir. Nümunə konfiqurasiyalar yalnız yerləşdirmə və audit ideyalarını göstərmək üçün istifadə olunur və həyata keçirilməzdən əvvəl faktiki versiya, konfiqurasiya irsi, asılılıqlar və biznes imkanları əsasında yoxlanılmalıdır. ## TL;DR: Prioritet tədbirlər 1. Təhlükəsizlik təkmilləşdirmələrinə üstünlük verin. üçün nginx.org Açıq Mənbə paketləri, yeniləyin Stable 1.30 heç olmasa filiala 1.30.6 və Mainline 1.31 heç olmasa filiala 1.31.7. Doğrulama tarixində, 1.31.8 ən sondur Mainline azad edin. Bunlar ayrı-ayrı filial bazalarıdır; filiallar üzrə onların sayını müqayisə etməyin. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1) [S2](https://keendigit.com/az/insights/nginx-remediation-guide#source-2) 2. Dağıtım qurğularını tam paket versiyası ilə yoxlayın. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 satıcı arxa portlarına malikdir; Debian 13 (trixie) ən azı `1.26.3-3+deb13u10` tələb edir. Doğrulama zamanı Debian 12 (bookworm) paketinin `1.22.1-9+deb12u10` hələ də təsirə məruz qaldığı qeyd olunur. Hər CVE-ni yoxlayın; Debian 13 məsləhəti Debian 12-nin sabit olduğunu müəyyən etmir. [S13](https://keendigit.com/az/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/az/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/az/insights/nginx-remediation-guide#source-15) 3. Beş konfiqurasiya birləşməsini yoxlayın: `alias + rewrite + $request_filename` , `map` + regex + dəyişənlərin qiymətləndirilməsi, `aio + ssi + include virtual` , HTTP/3 ilə `proxy_request_buffering on` , və `ssl_session_cache shared:...` avtomatik ilə TLS Sessiya Bileti açarının fırlanması. Təkcə direktivin mövcudluğu istismar qabiliyyətini müəyyən etmir; sorğu yolunu və konfiqurasiya əhatəsini qiymətləndirin. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1) [S3](https://keendigit.com/az/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) 4. Bütün köhnə prosesləri və qabları dəyişdirin. `nginx -t`-ni işə salın, sonra xidməti yenidən başladın və ya yüksək əlçatanlığa malik yayma yerləşdirməni həyata keçirin. Köhnə master/worker proseslərindən çıxdığını təsdiqləyin; Təkcə `nginx -s reload` işləyən binarın dəyişdiyini sübut etmir. 5. Faktiki son nöqtələri yoxlayın: aktiv olduqda HTTP/1.1, HTTP/2, HTTP/3, proksiləşdirilmiş yükləmələr və API sorğu orqanları, mTLS sertifikatının autentifikasiyası, SSI səhifələri və giriş jurnalları. Hər bir son nöqtə üçün paket mənşəyini, versiyasını, təsvirin həzmini, işləyən prosesləri və nəticələri qeyd edin. 6. Dərhal təkmilləşdirmə mümkün deyilsə, müvafiq tetikleme şərtlərini silin: lazımsızları söndürün SSI / AIO və ya HTTP/3 , həssas nəzərdən keçirin `alias` / `rewrite` / `map` dəyişən istinadlar və müvəqqəti qiymətləndirin `ssl_session_tickets off;` təsirə məruz qalanlar üçün mTLS xidmətlər. WAF , ASLR , dərəcə limitləri və konfiqurasiya dəyişiklikləri yalnız bəzi şərtləri əhatə edir və rəsmi yamaları əvəz edə bilməz. [S3](https://keendigit.com/az/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) [S8](https://keendigit.com/az/insights/nginx-remediation-guide#source-8) [S12](https://keendigit.com/az/insights/nginx-remediation-guide#source-12) ## 1. Zəifliyə İcmal və Risk Mühakiməsi NGINX beş təhlükəsizlik məsələsini həll edərək, 14 oktyabr 2026-cı ildə 1.30.6 (Stable) və 1.31.7 (Mainline) buraxdı. Üçü yığın daşqınlarını və ya pulsuz istifadəni əhatə edir və F5 CVSS v4.0 9.2 / Kritik balları aldı. Digər ikisi HTTP/3 sorğunun bütövlüyünə və TLS müştəri sertifikatının autentifikasiyasına təsir göstərir. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/az/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/az/insights/nginx-remediation-guide#source-3) Reytinq sistemlərini fərqləndirin: nginx.org bütün beş məsələni `medium` kimi sadalayır, F5 CVSS v4.0 və bəzi milli təhlükəsizlik agentlikləri üç yaddaş problemini Kritik kimi təsnif edir. Bu o demək deyil ki, beşinin hamısı şərtsiz uzaqdan kod icrasına icazə verir. Konfiqurasiya, trafikin əlçatanlığı və təcavüzkarın nəzarətindən kənar şərtlər. Yaddaşın pozulması və etibarlı RCE müxtəlif səviyyəli sübutlardır. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/az/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) | CVE | Texniki problemlər və tipik tetikleme şərtləri | əsas təsir | Qiymətləndirmə və Utilizasiya | | -------------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | CVE-2026-15176 | `alias` yol xəritəsi + `rewrite` dəyişikliyi URI + qiymətləndirmə `$request_filename` | Yığın bufer daşması, Worker qəzası; müəyyən şərtlər altında potensial RCE | F5 CVSS v4.0 9.2; problemlərin aradan qaldırılmasına üstünlük verin | | CVE-2026-93479 | HTTP/Stream skriptinin qiymətləndirilməsi, xüsusilə `map` regex ələ keçirmə və root kataloqu, log dəyişən çarpaz istinad | Qorunan buferin üzərinə yazılır və yığın daşır; müəyyən şərtlər altında potensial RCE | F5 CVSS v4.0 9.2; əvvəlki təmirdən sonra reqressiya riskidir | | CVE-2026-97205 | SSI virtual daxildir və AIO/asinxron əməliyyat; görkəmli əməliyyat sayı daşması | İstifadədən sonra pulsuz, Worker qəzası, yaddaşın pozulması; potensial RCE | F5 CVSS v4.0 9.2; qeyri-standart konfiqurasiya tələb edir | | CVE-2026-95101 | HTTP/3 Naməlum çərçivə buferlər arasında parçalanıb, proksi sorğunun əsas buferləşdirilməsi aktiv edilib | Qeyri-DATA baytların yuxarı sorğu orqanına səhv yeridilməsi, ola bilsin, sorğunun əsas ölçüsü limitini keçərək | Bu zəiflik sorğunun bütövlüyünə təsir göstərir. O, özü uzaqdan kod icrasını (RCE) təmin etmir. | | CVE-2026-97629 | Paylaşılan TLS Sessiya Keşi, avtomatik düymələrin fırlanması və Worker açarının əks olunması | Sessiya Biletinin saxtalaşdırılması; Təsirə məruz qalan mTLS xidməti üçün müştəri sertifikatının identifikasiyası keçməsi baş verə bilər | API tipli sertifikatın autentifikasiyasının biznes təsirinə xüsusi diqqət yetirilməlidir. | Yuxarıdakı CVSS balı v4.0 istifadə edərək F5 tərəfindən verilir; eyni zəiflik CVSS 3.1, nginx.org öz qiymətlərində və paylanma ciddilik reytinqlərində fərqli ciddilik göstərə bilər. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/az/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) ### 1.1 Təkcə CVE balları deyil, yerləşdirmə ifşasına üstünlük verin | Yerləşdirmə forması | Əsas araşdırma nöqtələri | Utilizasiya üçün prioritet tövsiyələr | | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Fərdiləşdirilmiş `rewrite`, `alias` və kompleks `map` daxil olmaqla ictimai şəbəkə əks proksi | Maydan iyul ayına qədər CVE-2026-15176, CVE-2026-93479 və yenidən yazma/xəritə zəiflikləri | P0: Dərhal yoxlayın və yeniləyin | | API / Müştəri sertifikatından yeganə və ya əsas giriş identifikasiyası kimi istifadə edən idarəetmə təyyarəsi | Sessiya Bileti və CVE-2026-97629-nin paylaşılan keş konfiqurasiyası | P0: Doğrulama sərhədini dərhal təsdiqləyin və yeniləyin | | Xarici HTTP/3 yükləmə, status dəyişikliyi interfeysi, əməliyyat sinfi API təmin edin | CVE-2026-95101, xüsusən sorğu orqanı arxa tərəfə proksiləşdirilmişdir | P0/P1: Biznesin əhəmiyyətinə görə təşkil edin | | SSI Dinamik səhifə və ya asinxron fayl I/O | CVE-2026-97205 | P1: Kombinasiya şərtlərini təsdiqləyin və mümkün qədər tez təmir edin | | Yalnız statik səhifələr + sadə HTTP/1.1/2 əks proxy | Konfiqurasiya və versiya hələ də yoxlanılmalıdır, lakin bəzi CVE şərtləri çatışmayan ola bilər | P1: Təcili təhlükəsizlik təkmilləşdirmə pəncərəsinə daxildir | | Təqaüdçü Kubernetes İcmasından istifadə edin ingress-nginx | Layihə təhlükəsizlik xidmətini dayandırır və risklər bu beş CVE ilə məhdudlaşmır | Fərdi nəzarətçi miqrasiya planı hazırlayın | P0/P1 ictimai şəbəkəyə məruz qalma və sertifikatlaşdırma həssaslığı üçün bu məqalədə verilən əməliyyat və texniki tullantı təklifləridir. Bu, rəsmi CVSS təsnifatı deyil və müəssisənin daxili aktivini əvəz etməməli və risklərin qiymətləndirilməsini dəyişdirməməlidir. ### 1.2 Təsir sərhədi və hücum icazələri Bu dəstədəki əsas zəifliklər əsasən NGINX Data Plane-də yerləşir: hücumun giriş nöqtəsi müştəri bağlantısı və sorğudur və faktiki təsir adətən Worker prosesində baş verir. Yaddaşın pozulması üçün istifadə edilə bilən şərtlər yerinə yetirilərsə, kodun icrasına icazə ümumiyyətlə işləyən istifadəçi, konteyner məhdudiyyətləri, Linux imkanları, quraşdırma və Worker şəbəkə icazələri ilə məhdudlaşdırılır; potensial RCE avtomatik olaraq root imtiyazlarını və ya host kompromisini nəzərdə tutmur. [S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) Lakin proses qeyri-imtiyazlı olsa belə, o, hələ də proksi etimadnaməyə, sertifikatın şəxsi açarlarını ehtiva edən oxuna bilən fayllara, yuxarı axın xidmət nişanlarına, müvəqqəti fayllara, daxili API və əlçatan şəbəkələrə daxil ola bilər. mTLS üçün autentifikasiyadan yan keçmənin özü ciddi iş nəticəsi ola bilər və mütləq kodun icrası ilə müşayiət olunmalı deyil. ## 2. Səbəb təhlili ### 2.1 NGINX-də üç səhvə meyilli sərhədi anlayın NGINX worker sorğu statusunu, asinxron əməliyyatları və protokol təhlilçilərini saxlayan uzunmüddətli, hadisələrə əsaslanan prosesdir. Bu zəiflik üç mühəndislik səviyyəsində məhdudiyyətləri özündə cəmləşdirir: 1. dəyişənlərin qiymətləndirilməsi və yaddaş ölçüsü uyğun olmalıdır: `rewrite` URI sorğusunu dəyişdirdikdən sonra yolun xəritəsi hazırda qüvvədə olan `location` ilə uyğun olmalıdır; skript tərcüməçisi dəyişən uzunluğu hesabladıqda, yazı sahəsi faktiki çıxışı və ayrılmış sahələri əhatə etməlidir. 2. Asinxron əməliyyatlar tələb olunan yaddaşın ömrünü uzatmalıdır: Bitməmiş faylın oxunması və yazılması, keş gözləməsi və ya mövzu tapşırıqları olduqda, müvafiq sorğu yaddaş fondu əvvəlcədən buraxıla bilməz. 3. protokol statusu və təhlükəsizlik statusu qarışdırıla və ya buraxıla bilməz: HTTP/3 Naməlum kadr atlamasının uzunluğu DATA sorğunun əsas uzunluğu kimi qəbul edilə bilməz; TLS İmzanın yoxlanılmasında iştirak edən bütün açar yuvalar sessiya biletinin fırlanması zamanı düzgün işə salınmalı və sinxronlaşdırılmalıdır. Aşağıdakı məzmun NGINX upstream düzəltmə öhdəliyinə və tetiklene bilecek nasazlıq mexanizmini izah etmək üçün satıcı elanına əsaslanır; nümunə fraqment təhlil üçündür, istehsal mühitini təmir etmək üçün birbaşa istifadə edilə bilən tam kod deyil. [S5](https://keendigit.com/az/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/az/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/az/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/az/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/az/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176: `alias` və yenidən yazılmış URI arasında yol xəritəsi yanlışdır. NGINX-də uyğun gələn `location` və onun `alias` fayl yolunu müəyyən edir; `rewrite` cari sorğunu dəyişə bilər URI. Yenidən yazdıqdan sonra orijinal `location` xəritələşdirməsi tərəfindən istifadə edilən fərziyyələr artıq qüvvədə olmaya bilər. Təsirə məruz qalan emal yolu `ngx_http_map_uri_to_path()`-də `alias` statusunu yoxlayarkən sorğunun yenidən yazıldığını adekvat şəkildə yoxlamadı. Yenidən yazdıqdan sonra konfiqurasiya `$request_filename`-i qiymətləndirməyə davam etdikdə, yol cari URI vəziyyətinə uyğun gəlməyən fərziyyələrlə qurula bilər və nəticədə yığın yaddaşına hüduddan kənar yazmağa səbəb ola bilər. [S5](https://keendigit.com/az/insights/nginx-remediation-guide#source-5) Tipik birləşmə (yalnız konfiqurasiya auditi üçün əks nümunə kimi istifadə olunur, yerləşdirmə tövsiyə edilmir): ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` Təhlükə yalnız `return` ilə məhdudlaşmır: `set`, `if`, `add_header`, `log_format` və s. eyni sorğuda `$request_filename` qiymətləndirməsi işə salınarsa, yoxlanılmalıdır. Nümunədə `return` yalnız bu vəziyyət yolunu görmək asanlaşdırır, ondan bütün istehsal konfiqurasiyalarının daşqınlara səbəb olacağı qənaətinə gəlmək üçün istifadə edilə bilməz. [S5](https://keendigit.com/az/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/az/insights/nginx-remediation-guide#source-10) Hücumun nəticələri: Sorğunun qurulması Worker-nin yenidən başlamasına və ya xidmətin dayandırılmasına səbəb ola bilər; ASLR-nin bağlanması və ya yan keçməsi kimi şərtlər altında potensial RCE mövcuddur. Upstream patch-in əsas məqsədi sadəcə müəyyən buferi genişləndirmək əvəzinə, artıq etibarlı olmayan `alias` kontekstində yenidən yazılmış URI yol xəritəsini tamamlamaqdan imtina etməkdir. [S5](https://keendigit.com/az/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/az/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479: Skript qiymətləndirməsində "ehtiyat yer" və real dəyişən uzunluq arasında uyğunsuzluq NGINX-in HTTP və Stream modullarında hərfi sətirləri və dəyişən dəyərləri nəticə sətirinə birləşdirən skript qiymətləndiriciləri var. Tətbiq nümunələrinə HTTP sənədi root yolları, giriş jurnalı yolları və Stream-də dəyişən ifadələr daxildir. `map` + müntəzəm ifadələrin müəyyən konfiqurasiyaları `map` nəticə dəyişəni qiymətləndirilməmişdən əvvəl tutulan dəyərlərin digər ifadələr tərəfindən oxunmasına imkan verir. Qorunan uzunluğa malik skript icra üsulu ilə birlikdə köhnə tətbiq `len` rezervasiya edilmiş boşluğu əvvəlcədən qiymətləndirilmiş uzunluq akkumulyatoruna hesablayacaq, beləliklə, sonrakı yazma göstəricisi hesablamaları artıq bufer sərhədi ilə uyğun gəlməyəcək. Xüsusi dəyişənlərin qiymətləndirilməsi ardıcıllığında sonrakı sətir yazıları qorunan sahənin üzərinə yazıla bilər və bu, yığın daşmasına səbəb ola bilər. [S6](https://keendigit.com/az/insights/nginx-remediation-guide#source-6) | iştirakçı elementlər | Niyə buna diqqət yetirməyə dəyər | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | `map`-də regex | Dəyişən qiymətləndirmənin müstəqil həyat dövrü və keşləmə davranışı ola bilər | | `$1`, `$2` və s. kimi anonim çəkilişlər. | Asanlıqla digər müntəzəm ifadələr və ya ifadələr tərəfindən üzərinə yazılır, sahibliyi izləməyi çətinləşdirir | | `root`-də dəyişənlər | Skript icrası və yol qurmağa başladıqda bufer rezervasiyası | | `log_format`/Dinamik jurnal yolu | Eyni tipli qiymətləndirmə sorğuda daha sonra işə salına bilər | | `stream`-də skript ifadələri | Yuxarıdakı düzəliş `ngx_stream_script_run()`-ni də dəyişdirir. Siz yalnız HTTP modulunu nəzərdən keçirə bilməzsiniz. | Mühüm reqressiya əlaqəsi: Bu zəifliklə bağlı kod CVE-2026-42533-ni düzəldən əvvəlki dəyişikliklərlə bağlıdır. Debian 13 üçün rəsmi DSA açıq şəkildə bildirir ki, təsirə məruz qalan kodun trixie paketinə əvvəlki təhlükəsizlik portu vasitəsilə daxil edilib. Buna görə də, "İyul `map` zəiflik yaması quraşdırılıb" demək deyil ki, oktyabrın CVE-2026-93479 əhatə olunub; tam təhlükəsizlik düzəltmə zənciri yoxlanılmalıdır. [S6](https://keendigit.com/az/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/az/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/az/insights/nginx-remediation-guide#source-17) Burada potensial RCE riski yaddaşın mühafizəsi mühiti ilə bağlıdır və tək `map` regex-in anonim təcavüzkarlar tərəfindən istismar edilə biləcəyi iddia edilməməlidir. [S11](https://keendigit.com/az/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205: AIO Yarımçıq əməliyyat sayının əhatə dairəsi İstifadədən Sonra Pulsuzdur Bu zəiflik sadəcə olaraq "SSI-i yandırın və siz UAF əldə edəcəksiniz" deyil. Açar əsas sorğu tərəfindən saxlanılan asinxron əməliyyat istinad sayındadır. NGINX Hələ tamamlanmamış asinxron emal prosesini izləmək üçün `r->main->blocked` istifadə edin, köhnə tətbiqdə bu, 8 bitlik idi; bəzi yollar sayı artırmazdan əvvəl yuxarı hədd yoxlaması etməyib. Eyni əsas sorğu 256 gözlənilməz əməliyyatı topladıqda, sayma 255-dən 0-a qədər əhatə edə bilər. Sonrakı proseslər səhvən sorğunun buraxılmasına mane olan heç bir asinxron əməliyyat olmadığına inanacaq və bununla da hələ də tapşırığın istinad etdiyi sorğu yaddaş hovuzunu buraxacaq. [S7](https://keendigit.com/az/insights/nginx-remediation-guide#source-7) Uğursuzluq prosesini aşağıdakılara bölmək olar: 1. Əlaqədar asinxron giriş/çıxış/ip yolu aktiv olduqda, SSI səhifəsi `include virtual` vasitəsilə çoxlu alt sorğular və ya oxu əməliyyatları təqdim edir. 2. Müəyyən əsas sorğunun yerinə yetirilməmiş əməliyyatları sayma sahəsi ilə təmsil olunan yuxarı həddə qədər toplanır. 3. 8 bitlik hesablamalar "gözləyən əməliyyatlar yoxdur" kimi səhv ifadə edilir. 4. Sorğu yaddaş fondu buraxılır, fayl oxunarkən, keş gözləyərkən və ya mövzu tapşırıqlarının geri çağırışlarında hələ də ona istinadlar saxlanılır. 5. Sonrakı asinxron tamamlama geri çağırışları buraxılmış yaddaşa daxil olur, nəticədə UAF, Worker qəzaları və ya potensial yaddaş korlanması baş verir. Rəsmi düzəliş sorğunun başlıq faylına `NGX_HTTP_MAX_BLOCKED 250` əlavə edir və çıxış filtrinə, keş oxuna və yuxarı axınına məhdudiyyətlər əlavə edir; həddə çatdıqda, sinxronlaşdırılmış yollarla əməliyyatlar sinxron şəkildə tamamlanır və onları təhlükəsiz şəkildə emal etmək mümkün olmadıqda, gözlənilən tapşırıqların əlavə edilməsindən imtina ediləcək. [S7](https://keendigit.com/az/insights/nginx-remediation-guide#source-7) Tətbiq olunma mülahizəsi: SSI, AIO, virtual daxiletmə, alt sorğular və əlaqəli asinxron əməliyyatların eyni sorğu zəncirində kombinasiyada baş verə biləcəyi qiymətləndirilməlidir. Bunlar adətən standart düz statik proxy konfiqurasiyaları deyil. `aio off;` və ya `ssi off;` xüsusi tətik elementlərini silə bilər, lakin əvvəlcə biznes funksiyasından asılılıqlar təsdiqlənməlidir. [S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/az/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/az/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101: HTTP/3 naməlum çərçivə DATA sorğu orqanının statusu ilə qarışdırılıb HTTP/3 çərçivə təhlilçisi `DATA` çərçivələri (HTTP sorğu gövdəsinin işlənməsinə ötürülməlidir) və qaçırılmalı olan naməlum çərçivələri ayırd etməlidir. Şəbəkə buferləri arasında parçalanarkən naməlum çərçivələrin uzunluğu da dəqiq şəkildə qorunmalıdır. `ngx_http_v3_parse_data()`-in köhnə tətbiqi naməlum çərçivələri atlayarkən "qaçırılacaq baytların qalan sayını" saxlamaq üçün `st->length` sahəsindən istifadə etdi, sorğunun əsas filtri isə eyni sahəni "qalan DATA faydalı yük uzunluğu" ilə şərh etdi. Əgər naməlum çərçivə birdən çox analiz çağırışını əhatə edərsə, təhlil dayandırıldıqdan sonra növbəti bayt dəsti sorğunun bir hissəsi kimi səhv ola bilər. [S8](https://keendigit.com/az/insights/nginx-remediation-guide#source-8) İki növ risk yaranır: - sorğu orqanının inyeksiyası: Müştəri tərəfindən təqdim edilən qeyri-DATA kadr yükü backend tərəfindən faktiki olaraq alınan məlumatları dəyişdirərək yuxarı proqrama ötürülə bilər. - ölçü həddi keçmələri: `client_max_body_size` və digər məhdudiyyətlər. Gözlənilən yoxlamalar DATA yolunda cəmlənib və yanlış konvertasiya edilmiş məzmun müvafiq yoxlamadan keçə bilər. Rəsmi şəxs tərəfindən təsvir edilən tipik tətik ssenarisi `ngx_http_v3_module` HTTP/3 sorğusunu qəbul edib `proxy_request_buffering on`-ni yönləndirdiyi zamandır. Proksi sorğunun əsas buferləşdirilməsi `ngx_http_proxy_module`-də defolt olaraq aktivdir. Buna görə də, HTTP/3-ni işə salan əks proksi əvvəlcə yoxlanılmalıdır. Yalnız `proxy_request_buffering on;` açıq şəkildə yazılmadığı üçün heç bir tetikleyici şərtin olmadığını güman etmək düzgün deyil. [S8](https://keendigit.com/az/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/az/insights/nginx-remediation-guide#source-18) Bu zəifliyin birbaşa nəticəsi, birbaşa NGINX nüvəsində tamamlanan RCE-nin ekvivalent ifadəsi olmayan arxa sorğunun bütövlüyü və təhlükəsizlik sərhədinin dəyişməsinə aiddir. Biznesin son təsiri bu baytların necə təhlil edildiyindən və yuxarıda necə etibar edildiyindən asılıdır. [S24](https://keendigit.com/az/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS Bilet fırlanması üçüncü açar yuvasını qaçırır Təsirə məruz qalan konfiqurasiyalarda NGINX, TLS Sessiya Biletinin açarlarını ortaq yaddaş keşi vasitəsilə avtomatik yarada və döndərə bilər ki, bu da çoxlu Worker-yə eyni bilet partiyasını emal etməyə imkan verir. Müvafiq sinxronizasiya məntiqi hər bir Worker üçün 3 açar yuvası ayırır və deşifrə geri çağırışı da bu yuvaları keçəcək; lakin köhnə tətbiq hər dəfə paylaşılan yaddaşdan yalnız 2 açar yuvasını kopyalayır, nəticədə üçüncü yuvanın açar adı, HMAC açarı və AES olur. Açar işə salınmamış qala bilər. Biletin açar identifikatoru bu statusa uyğundursa, işə salınmamış açar materialı imzanın yoxlanılması və şifrənin açılması üçün istifadə oluna bilər, beləliklə, TLS sessiyasını saxtalaşdırmaq üçün yol yaradıla bilər. [S9](https://keendigit.com/az/insights/nginx-remediation-guide#source-9) Yüksək riskli yerləşdirmə birləşmələri adətən aşağıdakılardır: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` Bu zəifliyin ən ciddi biznes nəticəsi ondan ibarətdir ki, `ssl_verify_client on;`-də müştəri sertifikatının autentifikasiyasından (mTLS) və digər üsullardan istifadə edən xidmətlərdə saxta bərpa sessiyaları müştəri sertifikatının yoxlanışından yan keçə bilər. Hücumun müvəffəqiyyəti də idarəolunmaz şərtlərə tabedir; yalnız normal server tərəfində olan HTTPS sertifikatından istifadə edən və heç bir müştəri sertifikatı autentifikasiyası olmayan sayt "təcavüzkar bütün veb-sayta girişi keçə bilər" kimi yanlış xarakterizə edilməməlidir. [S9](https://keendigit.com/az/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/az/insights/nginx-remediation-guide#source-12) Bu, TLS sessiya identifikasiyası statusu məsələsidir və serverin TLS şəxsi açarının sındırılıb-sındırılmaması və ya ictimai CA root sertifikatına təsir edib-etməməsi ilə heç bir əlaqəsi yoxdur. [S24](https://keendigit.com/az/insights/nginx-remediation-guide#source-24) ### 2.7 DoS, RCE, autentifikasiya keçidi və məlum istismarları necə başa düşmək olar - DoS: Yaddaş xətası Worker-nin sıradan çıxmasına və ya kütləvi şəkildə yenidən başlamasına səbəb olur. Bunun ümumi əlçatmazlığa səbəb olub-olmaması trafik təzyiqi, prosesin yenidən başlama qabiliyyəti, əlaqənin saxlanma müddəti və yüksək əlçatanlıq arxitekturası ilə bağlıdır. - potensial RCE: Bəzi elanlar ASLR bağlandıqda və ya yan keçdikdə kodun icrası ehtimalının olduğunu göstərir. Bu, əmrləri sabit və universal şəkildə yerinə yetirə bilən ictimai hücum zəncirinin açıqlandığı anlamına gəlmir. [S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) - Sorğu inyeksiyası/identifikasiyası bypass: O, birbaşa qorunan biznes statusunu və ya sorğu məzmununu dəyişə bilər və sadəcə qabığı birbaşa əldə etmədiyi üçün nəzərə alına bilməz. - hücum cəhdləri aşkar etdi: 2026-cı ilin may ayında CVE-2026-42945 vəhşi istismar fəaliyyətləri haqqında hesabatlara malikdir; Bu tarixi faktdan birbaşa olaraq oktyabr ayında bütün beş CVE-nin geniş miqyasda uğurla istismar edildiyi anlamına gəlməməlidir. [S23](https://keendigit.com/az/insights/nginx-remediation-guide#source-23) ## 3. Təmir versiyası və yamaq seçimi ### 3.1 NGINX Open Source rəsmi yamaq bazası | yuxarı filial | Oktyabr ayında beş zəifliyi əhatə edən ilk rəsmi versiya | 2026-10-27 tarixinə olan tövsiyələr | | --------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | Ən azı 1.30.6 quraşdırın və sonrakı təhlükəsizlik versiyalarını izləyin. | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | Əvvəlki NGINX Open Source filialı | Bu, yalnız "köhnə zəiflik yamaları tətbiq edilib" əsasında qiymətləndirilə bilməz. | Əvvəlcə saxlanılan filiala köçürün; əks halda, satıcıdan CVE-by-CVE əsasında dəstəyin rəsmi sübutunu təqdim etməsi tələb olunur. | Bunlar nginx.org yuxarı mənbə kodunun/rəsmi filialının versiya nəticələridir və paylama satıcısı tərəfindən təmin edilmiş arxa portlu düzəlişlərlə təhlükəsizlik paketini birbaşa inkar etmək üçün istifadə edilməməlidir. `1.31.6` dəyəri `1.30.6`-dən böyük olsa belə, o, yenə də əsas filialın yamaq bazasından aşağıdır. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/az/insights/nginx-remediation-guide#source-2) ### 3.2 Beş CVE-nin yuxarı təsir dairəsi Aşağıdakı diapazonlar nginx.org təhlükəsizlik bülleteninin orijinal mətninə uyğun olaraq verilmişdir və "cari işləyən filial" və "faktiki konfiqurasiya yolu" ilə birlikdə başa düşülməlidir: | CVE | Upstream teqləri təsirlənmiş versiyalar | Rəsmi olaraq etiketlənmiş sabit versiya | | -------------- | --------------------------------------- | ------------------------------------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` və ya `1.31.7+`, müvafiq filialları daxilində | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | Yuxarıdakı kimi | | CVE-2026-97205 | `0.8.11–1.31.6` | Yuxarıdakı kimi | | CVE-2026-95101 | `1.25.0–1.31.6` | Yuxarıdakı kimi | | CVE-2026-97629 | `1.23.2–1.31.6` | Yuxarıdakı kimi | CVE-2026-93479 xüsusi giriş-versiya məhdudiyyətlərinə malikdir; hər köhnə NGINX versiyası bu reqressiyadan təsirlənmir. Bu diapazonlardan kənar köhnə versiyalar əvvəlki `map` regex zəifliyi CVE-2026-42533 tərəfindən hələ də təsirlənə bilər. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu: paylama arxa portları (USN-8955-1) Canonical USN-8955-1 26 oktyabr 2026-cı il dörd Ubuntu quruluşu üçün təhlükəsizlik yeniləməsini təqdim edir: [S13](https://keendigit.com/az/insights/nginx-remediation-guide#source-13) | Ubuntu versiyası | `nginx` və eyni mənbə paketinin sabit versiyası | Təsvir | | ---------------- | ----------------------------------------------- | ------------------------------------------------------------------------------ | | 22.04 LTS | `1.18.0-6ubuntu14.22` | Bu, satıcının arxa portudur; yuxarı versiya nömrəsi hələ də 1.18.0-ni göstərir | | 24.04 LTS | `1.24.0-2ubuntu7.19` | Yuxarıdakı kimi | | 26.04 LTS | `1.28.3-2ubuntu1.12` | Yuxarıdakı kimi | | 26.10 | `1.30.4-7ubuntu1.1` | Yuxarıdakı kimi | Elanda `nginx-core`, `nginx-extras`, `nginx-full` və `nginx-light` kimi homoloji paketlərin müvafiq sabit versiyaları var. Yalnız `nginx -v` tərəfindən göstərilən yuxarı hissədən onu düzəltmək barədə nəticə çıxarmayın. Ubuntu 24.04 və `1.24.0-2ubuntu7.19` kimi bu satıcı tərəfindən yamaq edilib, lakin hər hansı mənbədən olan `1.24.0` mahiyyət etibarilə təhlükəsiz deyil. Ubuntu rəsmi olaraq da bunu açıq şəkildə qeyd etdi CVE-2026-95101 yalnız təsir edir Ubuntu 26.04 / 26.10 , və CVE-2026-97629 yalnız təsir edir Ubuntu 24.04 / 26.04 / 26.10. Budur Ubuntu birbaşa digər paylamalara təqdim edilə bilməyən öz qablaşdırma və funksional əhatə dairəsi. [S13](https://keendigit.com/az/insights/nginx-remediation-guide#source-13) ### 3.4 Debian: Versiyalar arasındakı fərqlər ayrıca yoxlanılmalıdır Debian məsləhət DSA-6575-1 (2026-10-21) bu beş CVE-ni əhatə edir və Debian 13 / trixie üçün sabit `nginx` paketini müəyyən edir: ```text 1.26.3-3+deb13u10 ``` Bununla belə, bu hesabatın yoxlanılması zamanı `1.22.1-9+deb12u10` Debian 12 / bookworm üçün Debian Təhlükəsizlik İzləyicisi tərəfindən hələ də həssas olaraq qeyd olunur. Buna görə də: - Debian 13 Sadəcə DSA-6575-1-ə uyğun olaraq yeniləyin və qəbul edin. - Debian 12 cari Təhlükəsizlik İzləyicisi və ya ELTS satıcısı tərəfindən təmin edilmiş təhlükəsizlik düzəlişlərini bir-bir yoxlamalıdır; düzəliş elanda təsdiqlənməmişdən əvvəl `apt upgrade`-nin uğuru əsasında bütün beş elementin düzəldildiyini bəyan etməyin. - Debian mənbə paketi nginx.org versiya nömrəsindən asılı olmayaraq yamaq dəsti daşıya bilər. Fərdi quruluşlar üçün, tam mənbə kodu paketi düzəltmə dəstini yoxlamaq lazımdır və siz sadəcə bir yuxarı öhdəliyi kopyalayıb onu tam hesab edə bilməzsiniz. Yuxarıdakı fərq DSA və CVE izləmə qeydlərinə əsaslanır. [S14](https://keendigit.com/az/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/az/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/az/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus, njs və Giriş Nəzarətçisi | Məhsullar/komponentlər | Təhlükəsizlik Seçimi və Doğrulama Əsas Nöqtələri | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus (kommersiya versiyası) | Zəhmət olmasa F5-ə uyğun gələn Plus filialının elanı və təkmilləşdirmə təlimatlarına baxın. Yoxlama zamanı ən son CR `PLS.37.2.0.1` və LTS-nin təhlükəsizlik quruluşu `PLS.37.0.7.1`-dir; Plus versiyası və daxil edilmiş arxa port birbaşa Açıq Mənbənin 1.30/1.31 həddi ilə əvəz edilə bilməz. [S19](https://keendigit.com/az/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_modulu | 2026-10-14 `njs 1.0.2`-ni buraxır və CVE-2026-101019 və CVE-2026-101025-ni düzəldir; njs istifadə edirsinizsə, modulun NGINX ilə uyğunluğunu da yoxlamalısınız. [S20](https://keendigit.com/az/insights/nginx-remediation-guide#source-20) | | F5 NGINX Giriş Nəzarətçisi / Gateway Parça | NGINX nüvəsi əlaqəli, lakin müstəqil proqram paylama zənciridir. Müvafiq zəiflikləri öz nəzarətçiləri, şəkilləri və buraxılış qeydləri ilə düzəldin. Podda sadəcə NGINX binarını əvəz edə bilməzsiniz. | | Kubernetes İcması `kubernetes/ingress-nginx` | Layihə 2026-cı ilin martında istismardan çıxarılıb və artıq yeni təhlükəsizlik xidməti göstərməyəcək. Onun buraxılış nömrəsini F5 NGINX Giriş Nəzarətçisi ilə səhv salmaq əvəzinə saxlanılan nəzarətçiyə və ya Gateway API-ə keçməyi planlaşdırmalısınız. [S21](https://keendigit.com/az/insights/nginx-remediation-guide#source-21) | ### 3.6 Əslində hansı yamağı seçməlisiniz? | Yerləşdirmə forması | Tövsiyə olunan təcrübələr | Təmir sübutu | | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | nginx.org rəsmi DEB/RPM paketi | Upstream filialının sabit versiyasına təkmilləşdirin | `nginx -v/-V`, paket mənbəyi, rəsmi təhlükəsizlik elanı | | Ubuntu/Debian rəsmi depo | Satıcı təhlükəsizlik paketlərini quraşdırın | Tam paket versiyası + satıcı USN/DSA + CVE statusu | | RHEL/Alma/Rocky/SUSE/Digər paylamalar | Xüsusi paylama təhlükəsizlik bülletenlərinə və paket versiyalarına uyğun olaraq təkmilləşdirin | Müvafiq satıcı CSAF/elan, Ubuntu/Debian versiyası tətbiq edilə bilməz | | Rəsmi və ya xüsusi konteyner şəkilləri | Təsdiqlənmiş təmir şəklini yenidən qurun və ya çəkin və yuvarlanan şəkildə dəyişdirin | Şəkil həzm, SBOM qurun, pod/konteyner təsvir identifikatoru ilə işləyir | | Öz-özünə tərtib edilmiş NGINX, OpenResty, Tengine və ya üçüncü tərəf modulları ilə yamaqlanmış versiyalar | Baxıcının tam təhlükəsizlik versiyasının istifadəsinə üstünlük verin; zəruri hallarda hədəf mənbə ağacı üçün nəzərdən keçirilmiş patch backportları yerinə yetirin | Beş zəiflik aradan qaldırılması, ABI/modul uyğunluğu, vahid və biznes reqressiyası | OpenResty və Tengine fərqli buraxılış sistemləridir; bu cədvəl yalnız yoxlama metodunu təsvir edir. bu o demək deyil ki, onun bütün versiyaları standart NGINX ilə eyni vaxtda təsirlənir, nə də yuxarı axın kod yaması qeyd-şərtsiz tətbiq edilə bilməz. ## 4. Formal təmir prosesi ### 4.1 Xarici trafik qəbulunun faktiki hallarının inventarlaşdırılması Ən azı hər giriş üçün toplayın: - Domen adı, yük balansı/CDN/kənar proxy bağlantısı, mənşə saytının ifşa üsulu və istifadə edilən şəbəkə protokolu. - NGINX məhsulları (Open Source, Plus, Ingress və s.), tam versiya, paket anbar mənbəyi, image digest. - `nginx -V` bina modullarını və kompilyasiya parametrlərini göstərir; njs, Lua, OpenResty və üçüncü tərəf dinamik modullarının olub-olmaması. - Real işləyən master/worker PID, Xidmət Bölməsi/Konteyner/Pod, Replika və Worker Node. - Faktiki effektiv `http`/`stream`, `server`, `location`, `include` konfiqurasiyaları. - HTTP/3, mTLS, SSI/AIO, dinamik jurnal yolunu, kompleks `map` və regex ələ keçirmənin aktiv edilib-edilməməsi. Yalnız standart `/etc/nginx/nginx.conf`-i yoxlamayın. İstehsal mühiti tez-tez `include` vasitəsilə çoxlu saytlar, TLS və modul konfiqurasiyalarını yükləyir. Çoxlu NGINX quraşdırma yolları və ya çoxlu proxy təbəqələri də ola bilər. ### 4.2 Versiya və tərtib məlumatını yoxlayın ```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` komanda xətti yolunda tapılan binarın qurulmasını bildirir; bu, işləyən worker-nin onu yüklədiyini sübut etmir. `nginx -v` paylamanın tam paket şəkilçisini buraxa bilər, ona görə də paket menecerini və ya təchizat zənciri qeydlərini yoxlayın. ### 4.3 Effektiv konfiqurasiyanı ixrac edin və statik yoxlamanın birinci mərhələsini həyata keçirin `nginx -T` konfiqurasiyanı sınayacaq və birləşdirilmiş konfiqurasiyanı atacaq. Çıxışda autentifikasiya etimadnamələri, əsas yollar, daxili host adları və s. kimi həssas məlumatlar ola bilər. Nəzarət olunan terminalı root icazələri və şəxsi fayl icazələri ilə yadda saxlamaq tövsiyə olunur və orijinal faylları ictimai iş sifarişlərinə yerləşdirməyin: ```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 ``` Bu, etibarlı CVE avtomatik təyinetmə aləti deyil, sadəcə namizəd yolu lokatorudur: 1. `grep` dəyişənlərin eyni `location`-də və ya eyni sorğu qiymətləndirmə zəncirində yerləşib-yerləşmədiyini müəyyən edə bilməz və ya konfiqurasiyanın varislik əlaqəsini çıxara bilməz. 2. `proxy_request_buffering on`, bəzi keş və bilet konfiqurasiyalarının standart dəyərləri var və müvafiq təlimatları yazmamaq riskin aradan qalxması demək deyil. 3. Əks proksilər, CDN, konteyner yan arabaları və ya nəzarətçilər tərəfindən yaradılan konfiqurasiyalar əl ilə yoxlanan fayllardan fərqli ola bilər. 4. `NGINX Plus` və dinamik modulların xüsusiyyətlərini onların müvafiq rəsmi idarəetmə alətlərindən istifadə etməklə təsdiq etmək tələb oluna bilər. ### 4.4 Etibarlı kanallar vasitəsilə düzəliş yerləşdirin Debian/Ubuntu (rəsmi paylama deposu): ```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 ``` Bu əmrlər dəsti hələ mövcud olmayan təhlükəsizlik düzəlişlərini yarada bilməz. Xüsusilə Debian 12 üçün, təkmilləşdirilmiş paket təhlükəsizlik izləmə sistemi tərəfindən hələ də həssas hesab edilirsə, əlavə təchizatçı təmiri, izolyasiya və ya miqrasiya tədbirləri tələb olunur. [S13](https://keendigit.com/az/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/az/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/az/insights/nginx-remediation-guide#source-15) nginx.org rəsmi paketi: ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` Öz-özünə tərtib edilmiş, OpenResty, Tengine və ya NGINX Plus istifadə edirsinizsə, müvafiq texniki xidmətçi tərəfindən dəstəklənən düzəltmə versiyasını istifadə edin və nginx.org, paylama və üçüncü tərəf repozitor paketlərini qarışdırmayın. Orijinal ikiliklər/şəkillər, konfiqurasiyalar, imzalar və geriyə yerləşdirmə manifestləri qorunmalıdır. Konteynerlər/Kubernetes: dəyişməz şəkli yeniləyin, onun həzmini qeyd edin və bütün köhnə replikaları mərhələli təqdimatla əvəz edin. `kubectl rollout status` yalnız yerləşdirmə nəzarətçisinin başa çatdığını təsdiq edir; həmçinin görüntü həzmlərini, giriş marşrutunu və qeyri-sağlam replikaları yoxlayın. ### 4.5 Konfiqurasiyanı yoxlayın və köhnə Worker-ni dəyişdirin ```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' ``` `nginx -s reload`-ni yeni binarın işlədiyinin sübutu kimi qəbul etməyin: adi konfiqurasiyanın yenidən yüklənməsi köhnə master-yə icra olunanı əvəz etmədən yeni işçiləri işə salmağa imkan verir. NGINX xüsusi onlayn ikili təkmilləşdirmə prosedurunu dəstəkləyir, lakin bu, əlavə addımlar və yoxlama tələb edir. Müəyyən edilmiş prosedur olmadan, xidmətin yenidən başlaması ilə müşayiət olunan yüksək əlçatanlı trafik açarından istifadə edin və ya əvəzedici konteynerləri işə salın. [S22](https://keendigit.com/az/insights/nginx-remediation-guide#source-22) NGINX-ni `systemd` yuvası, konteynerə giriş skripti və ya bir neçə quraşdırma vasitəsilə idarə edirsinizsə, `systemctl restart nginx`-nin bütün nümunələri əhatə etdiyini birbaşa fərz etmək əvəzinə, faktiki işə salma hədəfini və proses yolunu yoxlamalısınız. ### 4.6 Həqiqi xarici girişdən biznes reqressiyasını qəbul edin və edin Ən azı yerinə yetirmək tövsiyə olunur: - Normal HTTPS, yenidən yazılmış marşrutlar, statik resurslar və `alias` xəritəçəkmə səhifələri düzgündürmü. - Adi `map` paylanması, dəyişən root yolu, giriş jurnalı yolu, SNI/sertifikat marşrutu və Stream proksi düzgündürmü. - Normal yükləmələr, parçalanmış yükləmələr, API sorğuları və HTTP/3 üçün yuxarı həcm limitləri (aktiv olduqda) hələ də gözlənildiyi kimidir. - mTLS: Qanuni sertifikat sorğuları uğur qazanmalıdır; əskik, vaxtı keçmiş və ya icazəsiz sertifikatlar hələ də rədd edilməlidir və TLS bərpası/yenidən qoşulması icazələri təsadüfən dəyişməməlidir. - SSI səhifəsi və asinxron fayl girişinin normal olub-olmaması; səhv jurnalı yaddaş istinadları və ya təkrarlanan Worker qəzaları üçün anormal sorğular göstərmir. - Trafik keçidindən sonra köhnə versiya prosesi və köhnə şəkil replikası çıxmalı idi. Test öz və ya səlahiyyətli mühitdə aparılmalıdır. Normal sorğu tüstü testi yaddaş zəifliyinin aradan qaldırıldığını tək başına sübut edə bilməz; nəhayət, tədarükçünün sabit versiyası, mənbə kodu yaması və icra müddəti testi qəbul üçün birgə qəbul edilməlidir. ## 5. Dərhal təkmilləşdirmə mümkün olmadıqda təsirin azaldılması tədbirləri Bu bölmə yamağın dəyişdirilməsi deyil, riskin azaldılması variantıdır. Bütün müvəqqəti konfiqurasiya dəyişiklikləri ehtiyat nüsxəsini çıxarmalı, `nginx -t` yerinə yetirilməli, partiyalar şəklində buraxılmalı və lazım gələrsə, tez bir zamanda geri qaytarılmalıdır. [S3](https://keendigit.com/az/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) ### 5.1 Xarici təsirə əsaslanan trafik prioritetinə nəzarət edin Vaxtında təkmilləşdirilə bilməyən xidmətlərin hücum səthinin azaldılmasına üstünlük verin: idarəetmə səthində və daxili API Etibarlı mənbəyə giriş nəzarəti, yuxarı şəbəkə izolyasiyası və ya qısa müddətli oflayn əlavə edin; yüksək riskli girişlərə əlaqə, sorğu orqanı və tarif limitləri əlavə etmək; sorğunun emal zəncirindən əvvəl mənbə identifikasiyasının girişlə əlaqəli NGINX-də baş verdiyinə əmin olun. Qeyd etmək lazımdır ki, zəifliklərin əksəriyyəti NGINX-də yerləşir Məlumat müstəvisinin içərisində ənənəvi WAF Qaydaları xüsusi konfiqurasiya tetikleme şərtlərini dəqiq müəyyən etməyə bilər. ### 5.2 `alias` / `rewrite`: yenidən yazdıqdan sonra `$request_filename`-ni qiymətləndirməkdən çəkinin Yoxlamaq və tənzimləmək tövsiyə olunur: - `alias` istifadə edərək `location` ilə eyni vaxtda URI dəyişdirəcək `rewrite` yerinə yetirməməyə çalışın. - URI yenidən yazılmış, lakin düzgün mövqe uyğunluğu hələ tamamlanmamış zaman `$request_filename` istifadə etməkdən çəkinin. - `return`, `set`, `if`, `add_header`, giriş jurnalı formatında dolayı dəyişən istinadları yoxlayın və faylları daxil edin. - Biznes icazə verdikdə aydın `root`/`try_files`/müstəqil `location` istifadə edin, lakin yalnız `alias`-ni `root`-ə dəyişir. O, həmçinin fayl yolunun semantikasını dəyişə bilər, bu da bir-bir yoxlanılmalıdır. Mövcud konfiqurasiyanın üzərinə yazmaq üçün İnternetdə ümumi "təhlükəsiz yenidən yazma şablonunu" birbaşa kopyalamayın. Fərqli `location` prefiksləri və yenidən yazma hədəfləri tamamilə fərqli mənalarla yolun birləşdirilməsi ilə nəticələnir. [S5](https://keendigit.com/az/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex: Çəkmə dəyişən vəziyyətinin qarışdırılmasını azaldın `$1` kimi anonim çəkilişlərin zamanla müxtəlif regex qiymətləndirmə yollarında təkrar istifadə edilməsinə icazə vermək əvəzinə, adlandırılmış çəkilişlərə üstünlük vermək və onların yayılma əhatəsini məhdudlaşdırmaq tövsiyə olunur. Məsələn: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` Bu fraqment yalnız dəyişən mülkiyyətin daha asan yoxlanılan strukturunu nümayiş etdirir; bütün CVE-2026-93479 tetikleyici yollarını müstəqil şəkildə aradan qaldırmasının sübut olunduğu anlamına gəlmir. Xüsusilə, tutma dəyişənlərinə digər `root` və ya `log_format` tərəfindən vaxtından əvvəl istinad edilib-edilmədiyini və `volatile`, dinamik yollar və bir-birindən asılı qiymətləndirmə zəncirlərinin olub olmadığını nəzərdən keçirin. F5/CERT qısamüddətli relyef kimi adlandırılmış tutmadan istifadə etməyi və istifadə sahəsini müvafiq müntəzəm uyğunluq konfiqurasiyası ilə məhdudlaşdırmağı tövsiyə edir. [S3](https://keendigit.com/az/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/az/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI: Lazımsız funksiya birləşmələrini bağlayın SSI və ya asinxron fayl I/O tələb etməyən serverlər/yollar üçün istifadə edin: ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` Zəifliyi tetikleyen şərtlər baxımından, təsvir edilən xüsusi zənciri aradan qaldırmaq üçün adətən ikisindən birinin bağlanması kifayətdir; eyni zamanda bağlanma yalnız biznesin bu qabiliyyətə etibar etmədiyi ssenarilərə şamil edilir. `include virtual`, alt sorğular, keş və mövzu hovuzunun davranışını yoxlayın; əks proksi yükü yüksək olduqda, AIO-nin bağlanması gecikmə və I/O performansını dəyişə bilər. [S7](https://keendigit.com/az/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 Bədən inyeksiyasını tələb edin: zəruri hallarda girişi müvəqqəti bağlayın deaktiv edin `quic` cəlb edən dinləyici HTTP/3 , ləğv edin `Alt-Svc` elan edən cavab başlığı HTTP/3 , və kənar qat/yük balanslaşdırıcısının hələ də göndərib-göndərmədiyini yoxlayın QUIC birbaşa təmirsizlərə müraciət edir NGINX : ```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 等配置保持不变 } ``` Yuxarıdakılar yalnız dəyişiklik fərqinin təsviridir, fərdi olaraq aktivləşdirilə bilən tam server konfiqurasiyası deyil. HTTP/2 parametrinin sintaksisi NGINX versiyası ilə əlaqədardır; HTTP/2-ni saxlamaq lazımdırsa, müvafiq versiyaya uyğun olaraq `http2 on;` və ya mövcud etibarlı sintaksisdən istifadə etməli və `nginx -t` ilə yoxlamalısınız. bütün bölməni bu bölmə ilə əvəz etmək əvəzinə, yerləşdirmədən əvvəl mövcud server konfiqurasiyası ilə birləşdirilməlidir. həmçinin UDP 443 təhlükəsizlik divarını, HTTP/3 sonlanma yerini və CDN/ön proksi-nin müştəri ehtiyat yolunu yoxlayır. Qısamüddətli təsirlərin azaldılmasının başqa bir növü təsirə məruz qalmış proksi yolunda `proxy_request_buffering off;`-dən istifadə etməkdir, lakin bu, yuxarı sorğunun əsas axınının, uğursuzluğun təkrar cəhdlərinin və bəzi yükləmə iş axınlarının davranışını dəyişəcək; yalnız kifayət qədər sınaqdan və direktivin təsirə məruz qalmış HTTP/3 proksi yoluna düşməsi təsdiqləndikdən sonra istifadə oluna bilər. [S8](https://keendigit.com/az/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/az/insights/nginx-remediation-guide#source-18) ### 5.6 TLS Sessiya Bileti: Prioritet qorunması mTLS Doğrulama sərhədi Təkmilləşdirmə mümkün deyilsə və nümunə paylaşılan sessiya keşinə + avtomatik bilet açarının fırlanmasına əsaslanırsa, qiymətləndirin: ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` Bu, TLS Sessiya Bileti mexanizmini söndürə bilər və bununla da bu zəiflikdə təsvir edilən bilet saxtakarlığı yolunu silə bilər; lakin bu, sessiyanın bərpasına təsir göstərə bilər. Siz "zəifliklərdən qaçmaq" üçün mTLS müştəri sertifikatının yoxlanmasını söndürə bilməzsiniz, çünki bu, orijinal autentifikasiya sərhədini birbaşa siləcək. [S9](https://keendigit.com/az/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/az/insights/nginx-remediation-guide#source-12) Açıq `ssl_session_ticket_key` faylları və təhlükəsiz fırlanma avtomatik yaradılan şərtlərdən yan keçmək üçün peşəkar TLS idarəetmə prosesləri tərəfindən də istifadə edilə bilər, lakin əsas saxlama, tam qovşaq paylanması, fırlanma və köhnə biletin həyat dövrləri diqqətlə yoxlanılmalıdır. Adi veb konfiqurasiyasında və ya müvəqqəti fövqəladə hallar üçün skriptlərdə uzunmüddətli təkrar istifadə edilə bilən açarın kodlaşdırılması tövsiyə edilmir. mTLS istifadə edən kritik xidmətlər əlavə olaraq TLS sessiyasının bərpası davranışına və etibarlı müştəri sertifikatı olmadan sorğuların rədd edilməsinə nəzarət edilməlidir. [S12](https://keendigit.com/az/insights/nginx-remediation-guide#source-12) ### 5.7 Əməliyyat sistemi və sərhəd mühafizəsinin rolu ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR, root olmayan işçilər, yalnız oxumaq üçün nəzərdə tutulmuş konteyner fayl sistemləri, minimal fayl icazələri və şəbəkə izolyasiyası potensial RCE təsirini azalda bilər. ASLR yığın daşqınlarını və ya UAF-ni düzəltmir və işçilərin qəzaya uğramayacağına zəmanət verə bilməz. WAF, tarif limitləri və sorğunun bədən ölçüsü limitləri TLS Bilet açarının sinxronizasiyasını düzəltmir. [S4](https://keendigit.com/az/insights/nginx-remediation-guide#source-4) ### 5.8 Ümumi anlaşılmazlıq: Bu əməliyyatlar təmiri başa çatdırmaq üçün kifayət deyil | Ümumi əməliyyatlar | Niyə kifayət deyil? | | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | "nginx -v nisbətən yeni görünür" | Onun aid olduğu filial, buraxılış versiyasının tam backported paket versiyası və onlayn proses yoxlanılmır. | | “İntranetlərdən yalnız biri təkmilləşdirildi” | Köhnə Worker/köhnə konteyner/köhnə CDN mənşəli nümunə hələ də sorğuları qəbul edir | | "Sayt PHP/dinamik teqlərdən istifadə etmir" | Qüsur NGINX əsas yolunda və ya protokolun təhlilində baş verir və PHP icrasına etibar etmir. | | "WAF/Cloudflare-i açmaq kifayətdir" | WAF bütün NGINX konfiqurasiyadan asılı yaddaş qüsurlarını və ya TLS bərpa qüsurlarını bloklamaq üçün sübut edilə bilməz | | "Artıq ASLR açılıb" | Sadəcə çətinliyin azaldılmasından istifadə etməklə; Sorğu inyeksiyası ilə DoS hələ də mümkündür | | "HTTP/3 ictimai şəbəkəyə məruz qalmır, ona görə də təkmilləşdirməyə ehtiyac yoxdur" | Digər dörd CVE hələ də müstəqil qiymətləndirmə tələb edir; və gizli mənşələrlə birbaşa əlaqələr ola bilər | | "İyul `map` zəifliyi aradan qaldırıldı" | Oktyabr CVE-2026-93479 sonrakı skript qiymətləndirmə reqressiya məsələlərini əhatə edir | | "Keşləməni söndürmək bütün problemləri həll edir" | Yalnız bəzi TLS keş və ya AIO ssenarilərinə təsir edir və ləqəbi, skripti, HTTP/3-ni əhatə etmir | ## 6. Rəsmi Patch tətbiqi ideyaları və nəzərdən keçirmə nöqtələri Bu bölmə 2026-cı ilin oktyabrında yuxarı NGINX düzəlişlərini izləyir. Parçalar yamaqların nəzərdən keçirilməsi üçün reprezentativ dəyişiklikləri təsvir edir; onlar tam, müstəqil tərtib edilə bilən düzəlişlər deyil. Fərdi quruluşlar üçün tam öhdəlikləri, ətrafdakı kodu və testləri nəzərdən keçirin və tam dəstəklənən buraxılışa üstünlük verin. [S5](https://keendigit.com/az/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/az/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/az/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/az/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/az/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176: URI, `alias` yol xəritəsinin rədd edilməsi şərtlərini daxil etmək üçün yenidən yazılmışdır Yuxarı axın `src/http/ngx_http_core_module.c`-də dəyişdirilmiş `ngx_http_map_uri_to_path()`: ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` nəzərdən keçirmə fokusu: URI dəyişdikdə fayl sisteminin yolunu hesablamaq mümkün deyil, lakin `alias`-nin müvafiq yer semantikası artıq etibarlı deyil. Bu, dövlətdən əvvəlki məhdudiyyətin gücləndirilməsidir. URI sorğusunda qeyri-qanuni simvolların olub olmadığını yoxlamaq sadə deyil. [S5](https://keendigit.com/az/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479: Çıxış məlumatının uzunluğu ilə qorunan uzunluq arasında düzgün fərqləndirin Upstream öhdəliyi eyni zamanda `src/http/ngx_http_script.c` və `src/stream/ngx_stream_script.c`-ni yeniləyir. Əsas niyyəti belə ümumiləşdirmək olar: ```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); ``` Burada `pool` illüstrativ parametr adıdır: faktiki HTTP və Stream ayırma ifadələri fərqlidir. Dəyişiklik əvvəlcə skript çıxışının uzunluğunu hesablayır, sonra ehtiyat ayrılmış uzunluğu yekun bölüşdürməyə əlavə edir ki, çıxış ehtiyatda saxlanan boşluğun üzərinə yazmasın. [S6](https://keendigit.com/az/insights/nginx-remediation-guide#source-6) Audit və backporting zamanı HTTP/Stream-nin müvafiq qiymətləndiricisi də əhatə olunmalıdır; yalnız `map` konfiqurasiya sintaksisi faylını yoxlamaq qüsurun düzəldildiyini sübut edə bilməz. ### 6.3 CVE-2026-97205: 8 bitlik asinxron əməliyyat sayı üçün təhlükəsizlik həddini təyin edin `src/http/ngx_http_request.h`-də yuxarı axın əlavə edildi: ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` Oxşar girişləri asinxron fayl oxumağa, keş gözləməyə, çıxış süzgəcinə və mövzu əməliyyatına əlavə edin: ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` baxış fokus: `r->main->blocked` əlavə edəcək bütün faktiki kod yolları əhatə olunmalıdır. Siz sadəcə başlıq faylında eşik sabitini yaza bilməzsiniz. Backport həmçinin tapşırıqların birbaşa rədd edilməsi nəticəsində çıxılmaz vəziyyətin və ya istinad sızmasının səbəb olmamasını təmin etmək üçün sinxron geriyə, asinxron geri çağırış və xətaların tam koordinasiyasını yoxlamalıdır. [S7](https://keendigit.com/az/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101: Naməlum çərçivələr üçün ayrıca `skip` statusunu qoruyun Yuxarı axın `skip` sahəsini HTTP/3 təhlilçi status strukturuna əlavə edir və statusun ayrılmasını həyata keçirir: ```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); ``` Əsas odur ki, "naməlum HTTP/3 çərçivələrini söndürmək" deyil, birdən çox oxunuşda atlanan bayt sayının və DATA faydalı yükün uzunluğunun həmişə müstəqil dövlətlər tərəfindən idarə olunmasını təmin etməkdir. Rəylər naməlum çərçivələr arası bufer parçalanmasına və `client_max_body_size`-in son uyğunluğuna diqqət yetirməlidir. [S8](https://keendigit.com/az/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629: Tam TLS açar yuvası massivini sinxronlaşdırın Yuxarı dəyişikliklər `src/event/ngx_event_openssl.c`-də yerləşir: ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` Orijinal şəkil üç əsas yuvadan ibarət idi, lakin yalnız ilk ikisi kopyalandı. Bunun əvəzinə, Worker səsvermə açar dəstinin paylaşılan yaddaşa uyğun olmasını təmin etmək üçün massiv elementlərinin faktiki sayına əsasən sinxronizasiya edin. Nəzərdən keçirərkən, həmçinin `memcpy` uzunluğu modifikasiyasını bir dəfə yoxlamaq əvəzinə, massivlərin ayrılması, işə salınması, paylaşılan kilidi və fırlanma məntiqinin ardıcıl olduğunu təsdiqləyin. [S9](https://keendigit.com/az/insights/nginx-remediation-guide#source-9) ### 6.6 Niyə yalnız səpələnmiş yamaq fraqmentlərini tətbiq etmək tövsiyə edilmir? Bu beş modifikasiya müvafiq olaraq `src/http`, `src/stream`, `src/http/v3` və `src/event`-ni əhatə edir və köhnə versiyalarda təhlükəsizlik arxa portları və qeyri-rəsmi genişləndirmələr ola bilər. Backporting aşağıdakı yoxlama matrisini təşkil etməlidir: | Obyekt yoxlayın | Nə təsdiq edilməlidir | | ----------------------- | ----------------------------------------------------------------------------------------- | | yamaq mənbəyi | Rəsmi təqdimat, uyğun hədəf versiya, tam yamaq və imza yoxlaması | | Orijinal yamaq dəsti | CVE-2026-42533, paylama portu və s. kimi tarixi dəyişikliklərlə ziddiyyət təşkil etmir. | | kod yolu | HTTP + Stream skripti, AIO/thread, HTTP/3, OpenSSL Bilet hamısı əhatə olunur | | Uyğun tərtib edilmişdir | OpenSSL, PCRE, modul ABI, dinamik modul və keçid asılılıqları ardıcıldır | | funksional reqressiya | `alias` yenidən yazma, dinamik jurnal, SSI/AIO, HTTP/3 yükləmə, mTLS sessiyanın bərpası | | icra müddəti | Bütün Worker/Podlar yeni təsdiqlənmiş quruluşlarla işləyir, heç bir köhnə şəkillər qalmır | Öz buraxılışlarını saxlayan komandalar üçün hər bir CVE üçün yoxlanıla bilən yamaq identifikatorlarını, paket versiyalarını, tərtib jurnallarını və reqressiya hesabatlarını saxlamaq tövsiyə olunur; adi əməliyyat və texniki xidmət üçün ən təhlükəsiz həll satıcının tam təhlükəsizlik yeniləmələrini quraşdırmaqdır. ## 7. Tarixi zəifliyin geri çəkilməsi, köhnə filiallar və digər məhsullar ### 7.1 NGINX əsas zəifliyi 2026-cı ilin may ayından sentyabr ayına qədər eyni vaxtda təsdiqlənməyə layiqdir Uzun müddətdir yenilənməmiş bir çox NGINX nümunələri təkcə oktyabr ayında yeni buraxılışdan təsirlənmir. Aşağıdakılar yaxın gələcəkdə təmsil olunan təmir qovşaqlarıdır: [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/az/insights/nginx-remediation-guide#source-2) | CVE | İlk düzəliş buraxılışı | Audit tələb edən əsas risklər və şərtlər | | -------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0, 13 may | `rewrite` Anonim regex ələ keçirmə və dəyişdirmə məntiqi yığın daşqını, potensial RCE; vəhşi hücum cəhdləri ilə bağlı ictimai məlumatlar var | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1, 22 may | `rewrite`-də üst-üstə düşən regex tutulması və uzunluğun qiymətləndirilməsi daşmağa səbəb olur | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, 17 iyun | HTTP/2 Upstream və ya gRPC üçün xüsusi konfiqurasiya, böyük sorğu başlığı vəziyyəti bufer daşqını tetikler | | CVE-2026-42530 | Mainline 1.31.2, 17 iyun | HTTP/3 İstifadədən Sonra Pulsuz; rəsmi marka `1.31.0–1.31.1` təsir diapazonu | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 15 iyul | `map` + regex tutma dəyişəninin qiymətləndirilməsi yığın daşmasına səbəb olur və sonrakı yamaqlar oktyabr ayında CVE-2026-93479 ilə reqressiya korrelyasiyasına malikdir | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, 15 iyul | `ngx_http_slice_module` Xüsusi dəyişən və keş yeniləmə şərtləri altında yaddaş məzmunu sızdı | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, 15 iyul | SSI UAF ilə əlaqəlidir; Oktyabr ayının AIO hesablama zəifliyi ilə eyni root səbəbi deyil | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, 15 sentyabr | HTTP/3 + xüsusi OpenSSL versiya kombinasiyasının məhdud yığılması, əsasən qəza/məhdud yaddaşın pozulması kimi özünü göstərir | 2026-cı ildə elan edilmiş NGINX Core, HTTP/2, charset və SMTP kimi digər zəifliklər də rəsmi təhlükəsizlik bülletenlərinə uyğun olaraq araşdırılmalıdır; bu cədvəl qəsdən cari NGINX ictimai yönümlü əks proksi yerləşdirmələrinə ən uyğun olan və yaddaş təhlükəsizliyi və ya sorğu bütövlüyünə təsir göstərən tipik hadisələrə diqqət yetirir. 2026-cı ildə bütün CVE-lər deyil. Siyahı. [S1](https://keendigit.com/az/insights/nginx-remediation-guide#source-1) #### Niyə CVE-2026-42945-ə xüsusi diqqət yetirin May ayında bu `rewrite` zəifliyi üçün vəhşi istismar fəaliyyətlərini və ictimai istismar kodu məlumatlarını qeyd edən dövlət qurumlarının təhlükəsizlik bülletenləri var. Buna görə də, may ayından indiyədək uzun müddət yamaqlaşdırılmayan və ictimai şəbəkədə açıq mürəkkəb müntəzəm ifadələrin yenidən yazılmasına malik olan nümunələr üçün təmiri tamamlamaqdan əlavə, anormal Worker qəzası, giriş qeydləri və həmin vaxt şübhəli dəyişikliklər əlavə olaraq nəzərdən keçirilməlidir. [S23](https://keendigit.com/az/insights/nginx-remediation-guide#source-23) "Hücum cəhdi baş verdi" avtomatik olaraq təcavüzkarın hər hədəfdə əmrləri etibarlı şəkildə yerinə yetirdiyini sübut etmir; insidentlərə cavab verildikdə, kompromis göstəriciləri və proses qəzaları imtiyazların artması və ya davamlılığının həqiqi sübutlarından ayrıca araşdırılmalıdır. ### 7.2 Köhnə versiyalar və paylama arxa portları üçün remediasiya NGINX Fərqli filialların öz dəstək dövrləri və fərqli zəifliyin tətbiqi vaxtları var. Beş yeni yamaq nəzərdən keçirilmədən bütün erkən mənbə ağaclarına yayıla bilməz. | səhnə | Tövsiyə olunan strategiya | | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Buraxılış versiyası tam təhlükəsizlik yamaqlarını elan etdi | Satıcı paketlərindən istifadə edin və tam paket versiyalarını sənədləşdirin; uyğun olmayan yuxarı axın çılpaq binarları ilə əvəz etməkdən çəkinin | | Debian 12 və bu topludakı bütün CVE-lər tərəfindən hələ əhatə olunmayan digər təsirə məruz qalmış buraxılışlar | Riskli iş sifarişlərini təqdim edin, xarici məruz qalmanı məhdudlaşdırın və təchizatçı/ELTS statusunu yoxlayın; köçürün və ya lazım olduqda yoxlanıla bilən texniki xidmət buraxılış zəncirindən istifadə edin | | Upstream dəstəyini sona çatdıran tarixi filiallar | Dəstəklənən versiyalara miqrasiyaya üstünlük verin; qısamüddətli backporting lazımdırsa, baxıcılar asılılıqları və yamaq uyğunluğunu qiymətləndirəcək və tam testlər yazacaqlar. | | NGINX çəngəl ilə gəlir (OpenResty, Tengine, xüsusi şlüz) | Əvvəlcə müvafiq kod yolunun daxil olub-olmadığını müəyyənləşdirin və sonra çəngəl baxıcısının təhlükəsizlik bəyanatından istifadə edin. O, yuxarı versiyaya birbaşa ekvivalent ola bilməz. | | Təhlükəsizlik yamaları biznes funksionallığında dəyişikliklərə səbəb olur | Mərhələli buraxılışları, versiyalar arasında trafik keçidini və konfiqurasiya uyğunlaşmasını qəbul edin; ictimai şəbəkənin sabitləşdirilməmiş versiyasını izolyasiya olmadan bərpa etmək məqsədəuyğun deyil. | ### 7.3 njs, Giriş və NGINX Əsas üçün ayrıca remediasiya - njs: NGINX əsas proqramına əlavə olaraq, NGINX JavaScript modulunun versiyasını da yoxlamaq lazımdır. `njs 1.0.2` 2026-cı ilin oktyabrında XML təhlili yaddaşının tükənməsi və obyektin istinad atributları ilə XML doğrulamasının uyğunsuzluğu problemini həll edir. `nginx-saml` istifadə edərək XML imzasının yoxlanılması ilə əlaqəli yerləşdirmələr üçün siz plug-in ssenariləri üçün rəsmi njs təlimatlarını oxumalısınız. [S20](https://keendigit.com/az/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX Giriş Nəzarətçisi: Üstəlik, nəzarətçi və Gateway Fabric hər birində əlavə təhlükəsizlik bülletenləri, müxtəlif qablaşdırma versiyaları və unikal siyasət zəiflikləri ola bilər. Bir təbəqənin yenilənməsi digər təbəqənin avtomatik yenilənməsi demək deyil. [S19](https://keendigit.com/az/insights/nginx-remediation-guide#source-19) - Kubernetes İcması ingress-nginx: Kubernetes rəsmiləri artıq nəzarətçinin 2026-cı ilin martında texniki xidmətini dayandırdığını və onun anbarını F5 nəzarətçisi ilə qarışdırmaq olmaz. Təsirə məruz qalan müəssisələr yeni təhlükəsizlik versiyasını gözləmək əvəzinə, hamar miqrasiya planlaşdırmalı və Giriş annotasiyalarını və Gateway API semantik fərqlərini yoxlamalıdırlar. [S21](https://keendigit.com/az/insights/nginx-remediation-guide#source-21) ## 8. Qəbul meyarları və sonrakı yoxlamalar İş sifarişlərinin dəyişdirilməsi üçün qəbul şərtləri kimi aşağıdakı siyahıdan istifadə edilməsi tövsiyə olunur: | Layihə | İxtisas standartları | Saxlanıla bilən sübut | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Aktiv və portalın əhatə dairəsi | CDN-dən yan keçə bilən bütün xarici və birbaşa əlaqəli nümunələr inventarlaşdırılıb. | Domen adı, LB, IP, Pod/konteyner siyahısı | | Paket mənbəyi və təmir sahəsi | Bütün müvafiq CVE-ləri əhatə etmək üçün təsdiqlənmiş versiyalardan istifadə edin | Upstream təhlükəsizlik məsləhəti, USN/DSA, paket versiyası, şəkil sindirimi | | köhnə proses çıxır | Bütün köhnə master/worker/konteynerlər dəyişdirilib | PID/başlama vaxtı, yuvarlanan yerləşdirmə statusu, işləyən şəkil | | Konfiqurasiya auditi | Yüksək riskli birləşmələr aradan qaldırıldı və ya yamaqlarla əhatə olundu və miras əlaqələri yoxlandı | `nginx -T`-nin redaktə edilmiş xülasəsi və audit qeydi | | TLS/mTLS | Etibarlı sertifikatlar keçir; etibarsız və ya çatışmayan sertifikatlar rədd edilir; sessiyanın bərpası autentifikasiyadan yan keçmir | Mənfi/müsbət avtorizasiya testi, nəzarət edilən TLS test nəticələri | | HTTP/3 sorğu orqanı | Sabit yolu aktivləşdirin; yuxarı sorğu orqanı və tənzimləmə düzgün davranır | HTTP/3, proxy yükləmə, həcm həddi reqressiya testi | | SSI/AIO | Funksiya tələblərə cavab verir, Worker-də anormal abort yoxdur | Biznes reqressiya, qəza və səhv dərəcəsi monitorinqi | | Əməliyyat və texniki xidmət monitorinqi | Aşkar istisna yoxdur 5xx, SIGSEGV, proses dəfələrlə çıxır | Xidmət göstəriciləri və dəyişikliklərdən əvvəl və sonra qeydlər | | Geri çəkilmə strategiyası | Geriyə qayıtmaq lazımdırsa, əvvəlcə məruz qalmanı məhdudlaşdırın və təhlükəsizlik sərhədlərini qoruyun | Sifarişləri, Fövqəladə Hallar Axınlarını və Karantin Planlarını dəyişdirin | | sonrakı həyat dövrü | Təhlükəsizlik bülleteni abunələrini, konteyner yeniləmə tezliyini və filial miqrasiya planlarını müəyyənləşdirin | Defter, məsul şəxs və növbəti yoxlama tarixini təkmilləşdirin | ### 8.1 Qeydlərdə və işlək statusda nəyə diqqət etməlisiniz? Uzun müddət məruz qalmış serverlərdə anormallıqları aradan qaldırın `worker process exited on signal` 、 `SIGSEGV` , sorğu uğursuzluğu sıçrayışları, anormal mənbəyə giriş toplaması, gözlənilməz TLS Sessiyanın bərpası/identifikasiyası sorğu orqanının uğuru və anormal arxa uç davranışı. Bu göstəricilər yalnız təhqiqat ipuçları kimi istifadə edilə bilər və müəyyən CVE-dən istifadə edildiyini birbaşa sübut etmək üçün kifayət qədər sübut deyil. ;Müvafiq qeydlərin olmaması hücumun olmadığını sübut etmir. ### 8.2 Tövsiyə olunan son risk rəyi İstehsal mühiti üçün qəbul hesabatı aşağıdakı dəqiq ifadədən istifadə etməlidir: > NGINX xarici xidmət girişi və proqram paketinin mənbəyi müəyyən edilmişdir. Bütün müvafiq instansiyalar yuxarı axının rəsmi təhlükəsizlik versiyasına yüksəldilib və ya buraxılış satıcısı tərəfindən təsdiqlənmiş arxa port tamamlanıb; köhnə Worker və köhnə konteynerlər dəyişdirilib. Ləqəb/yenidən yazma/xəritə, AIO/SSI, HTTP/3 sorğu orqanı və TLS Sessiya Bileti/mTLS ilə əlaqəli konfiqurasiyalar yoxlanılıb və funksional, autentifikasiya və sorğuda reqressiyadan keçib. Təkmilləşdirməni hələ tamamlamamış hallar üçün əlavə olaraq məruz qalma sahələrini, kompensasiya tədbirlərini, məsul şəxsləri və tamamlama müddətlərini qeyd edin. Debian 12 və ya digər buraxılışlar üçün yamaq hələ də natamamdırsa, bütün qəbul formasını "tamamlanmış" kimi qiymətləndirmək düzgün deyil; həll edilməmiş CVE, müvafiq tetikleyici konfiqurasiyanın olub-olmaması, izolyasiya statusu və son təkmilləşdirmə marşrutu aydın şəkildə qeyd edilməlidir. *** ## Əlavə: İstinad edilən mənbələr və keçidlər Təsvir: Mətndəki `[Sx]` nömrələri eyni şəkildə bu bölməyə uyğun gəlir. Aşağıdakılar yuxarıda göstərilən layihə təhlükəsizliyi elanlarına, kod öhdəliklərinə, təchizatçının buraxılış elanlarına və milli təhlükəsizlik agentliyi məlumatlarına üstünlük verir. Göstərilən zəifliklərin ciddiliyi hər bir emitent təşkilatın reytinq meyarlarına uyğun olaraq təsvir edilir; məlumatların yoxlanılması tarixi 27 oktyabr 2026-cı ildir. ### S1 — NGINX Open Source Rəsmi Təhlükəsizlik Bülleteni - Beş Oktyabr CVE-nin yuxarı axının təsirinə məruz qalmış versiyalarını, düzəliş filiallarını və rəsmi ciddilik səviyyələrini ehtiva edir, həmçinin 2026-cı ilə qədər tarixi zəiflikləri əhatə edir. ### S2 — NGINX rəsmi versiya buraxılış rekordu - - 2026-10-14 1.30.6 / 1.31.7, 2026-10-21 1.31.8 və maydan sentyabr ayına qədər kritik təhlükəsizlik buraxılış mərhələlərini təsdiqləyin. ### S3 - Sinqapur Kiber Təhlükəsizlik Agentliyi: F5 NGINX Üç Kritik Zəiflik - CVSS v4.0 9.2 ballarının təsviri, tələb olunan konfiqurasiya şərtləri və CVE-2026-15176, CVE-2026-93479 və CVE-2026-97205 üçün müvəqqəti azaldılması tövsiyələri. ### S4 - NHS İngiltərə: F5 NGINX Yüksək risklə bağlı məsləhət - Yaddaş təhlükəsizliyi problemlərinin DoS / potensial RCE təsirini və ASLR kimi məhdudiyyətlərin söndürülməsi və ya yan keçməsini təsvir edir. ### S5 — Rəsmi mənbə öhdəliyi: CVE-2026-15176 - `ngx_http_map_uri_to_path()`-də `alias` və `r->uri_changed` status yoxlamasına uyğundur. ### S6 — Rəsmi mənbə öhdəliyi: CVE-2026-93479 - HTTP/Stream skript uzunluğuna və qorunan buferin ayrılması məntiqinə uyğundur. ### S7 - Rəsmi mənbə öhdəliyi: CVE-2026-97205 - `r->main->blocked` say həddinə `NGX_HTTP_MAX_BLOCKED 250` və asinxron yolun geri qaytarılmasına uyğundur. ### S8 — Rəsmi mənbə öhdəliyi: CVE-2026-95101 - HTTP/3 naməlum çərçivənin qalan uzunluğuna və DATA sorğunun gövdə uzunluğuna uyğun statusun ayrılması. ### S9 — Rəsmi mənbə öhdəliyi: CVE-2026-97629 - Sinxronizasiya TLS Sessiya Biletinin fırlanması zamanı bütün əsas yuvalara uyğun gəlir. ### S10 — F5: CVE-2026-15176 Satıcının Elanı - `alias`, `rewrite`, `$request_filename` və giriş qeydləri kimi tetikleyici amilləri sadalayın. ### S11 — F5: CVE-2026-93479 Satıcı Elanı - Xəritənin regex ələ keçirilməsini, root yolunu və dəyişən qiymətləndirmə şərtlərini qeyd edin. ### S12 — NGINX rəsmi TLS/SSL modul sənədləri - Təsvir `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` və müştəri sertifikatının autentifikasiyası və digər təlimatlar. ### S13 — Təhlükəsizlik məsləhəti: Ubuntu USN-8955-1 (2026-10-26) - Ubuntu 22.04 / 24.04 / 26.04 / 26.10. tam proqram paketinin sabit versiyasını və paylama sahəsini təmin edin ### S14 — Təhlükəsizlik məsləhəti: Debian DSA-6575-1 (2026-10-21) - Debian 13 / trixie üçün `1.26.3-3+deb13u10` təhlükəsizlik düzəliş paketini təsdiqləyin və CVE-2026-93479 üçün arxa port assosiasiyasını qeyd edin. ### S15 — Zəifliyin izlənməsi: Debian Security Tracker: CVE-2026-15176 - Debian 12 / bookworm və Debian 13 / trixie-nin paylama düzəliş statusunu yoxlamaq üçün istifadə olunur. Bu status gələcək təhlükəsizlik yeniləmələri ilə dəyişə bilər. ### S16 — Zəifliyin izlənməsi: Debian Security Tracker: CVE-2026-95101 - Müxtəlif Debian filiallarında HTTP/3 zəifliyinin təhlükəsizlik statusunun əlavə təsdiqi. ### S17 — Təhlükəsizlik məsləhəti: Red Hat: CVE-2026-93479 - Oktyabr ayı reqressiya zəifliyi ilə iyul ayı üçün düzəliş arasında əlaqə haqqında əlavə anlayış CVE-2026-42533. ### S18 — NGINX rəsmi əks proxy modulu sənədi - - `proxy_request_buffering`, `client_max_body_size`, `alias`, `aio` və s. kimi konfiqurasiyaların semantikasını və standart dəyərlərini sorğulayın. ### S19 — NGINX Plus Rəsmi Buraxılış Qeydləri - List Plus CR/LTS filialları, versiyaları, yamaları və təkmilləşdirmə uyğunluğu xatırlatmaları. ### S20 — NGINX JavaScript / njs Rəsmi Təhlükəsizlik Bülleteni - - Oktyabr 2026 njs 1.0.2 və əlaqəli XML doğrulaması, yaddaş tükənməsi problemlərini ehtiva edir. ### S21 — Kubernetes: İcma ingress-nginx rəsmi pensiya təlimatları - - Qeyd edək ki, layihə 2026-cı ilin martında yeni buraxılışları və təhlükəsizlik düzəlişlərini dayandırıb və saxlanılan nəzarətçi və ya Gateway API-ni köçürmək tövsiyə olunur. ### S22 — NGINX rəsmi xidmət nəzarəti və onlayn ikili təkmilləşdirmə təlimatları - Proseslərin dəyişdirilməsinin qəbulu üçün konfiqurasiyanın yenidən yüklənməsi, yenidən başlaması və onlayn icra edilə bilən fayl təkmilləşdirmə üsullarını fərqləndirin. ### S23 - Hökumət Təhlükəsizliyi Bildirişi: May 2026 NGINX yenidən yazma zəifliyi - - CVE-2026-42945 üçün tarixi risk fonu və təhlükəsizlik yeniləməsi təklifləri təqdim edin; Vəhşi istismarla bağlı qərarlar agentliyin həmin an verdiyi elana və hadisə ilə bağlı əlavə sübutlara əsaslanmalıdır. ### S24 — F5: CVE-2026-95101 və CVE-2026-97629 Satıcı Elanları - - HTTP/3 sorğu orqanının inyeksiyası və müvafiq olaraq avtomatik TLS Bilet açarının fırlanması risklərini əhatə edir. ### S25 — F5: CVE-2026-97205 Satıcının Elanı - Təsvir SSI/AIO tetikleme şərtləri və potensial yaddaş pozğunluğu riskləri. [NGINX təhlükəsizlik yeniləməsi: konfiqurasiya yoxlamaları, təkmilləşdirmələr və doğrulama](https://keendigit.com/az/news/nginx-security-update) ## Təhlükəsizliklə bağlı məsləhətləşmə Sertifikat güvən dəyişikliklərinin sistemlərinizə necə təsir etdiyindən əmin deyilsiniz? Biz təsirə məruz qalan müştəriləri qiymətləndirməyə və təhlükəsizlik yeniləmələrini planlaşdırmağa kömək edə bilərik. [Təhlükəsizlik yeniləmələrini müzakirə edin]() [Orijinal səhifə]() · [Məzmun indeksi]() KeenDigit LLC · Vayominq Sənədi ID: 2026-002106155 [Vayominq Dövlət Katibi ilə yoxlayın]() © 2026 KeenDigit LLC · Sheridan, Vayominq, Amerika Birləşmiş Ştatları · Bütün hüquqlar qorunur.