သမိုင်းဝင်ဆောင်းပါးရက်စွဲ- 2026-10-14 (ထုတ်ဖော်မှုနှင့် လုံခြုံရေးထုတ်ပြန်သည့်ရက်စွဲ)။ အရင်းအမြစ်များကို စစ်ဆေးပြီး 2026-10-27 မှတဆင့် အချက်အလက်များကို ဖြည့်စွက်ထားသည်။

ဤဆောင်းပါးကို ပွဲရက်စွဲဖြင့် သိမ်းဆည်းထားသည်။ အောက်တိုဘာလ 14 ရက်နေ့ နောက်ပိုင်းတွင် ထွက်ရှိသည့် ဗားရှင်းနှင့် အပ်ဒိတ်များကို အောက်တွင် ထည့်သွင်းထားသည်။ ပရိသတ်- NGINX Open Source / NGINX Plus ဝဘ်ဆိုက်နှင့် ပြောင်းပြန် proxy လည်ပတ်မှုနှင့် ပြုပြင်ထိန်းသိမ်းမှုဆိုင်ရာ ပုဂ္ဂိုလ်များ၊ လုံခြုံရေး တုံ့ပြန်ရေးဝန်ထမ်းများ၊ ဖြန့်ဖြူးရေးထိန်းသိမ်းသူများ၊ NGINX တို့ကို ကိုယ်တိုင်စုစည်းပြီး ပြင်ပမှ module များကို ထိန်းသိမ်းသည့် အင်ဂျင်နီယာများ။

ဤဆောင်းပါးသည် 2026 ခုနှစ် မေလမှ စက်တင်ဘာလအထိ 2026 ခုနှစ် မေလမှ စက်တင်ဘာလအထိ ကိုယ်စားလှယ်မှတ်ဉာဏ်ဘေးကင်းရေးနှင့် တောင်းဆိုသည့် ခိုင်မာမှုဆိုင်ရာ အားနည်းချက်များကို ထုတ်ဖော်ပြီး အပြင်းအထန်ပြင်ဆင်ထားသော NGINX ပင်မအားနည်းချက်ငါးခုကို အလေးပေးဖော်ပြထားပါသည်။ အကြောင်းအရာတွင် အစပျိုးအခြေအနေများ၊ ကုဒ်အဆင့်အကြောင်းရင်းများ၊ အကောင်အထည်ဖော်မှုအတိုင်းအတာ၊ အကျိုးသက်ရောက်မှုအတိုင်းအတာ၊ ပြုပြင်မှုအတိုင်းအတာ၊ အချိန်တိုအတွင်း ဖြည့်ဆည်းပေးသည့်အတိုင်းအတာ၊ ဘဏ်ခွဲအဟောင်းများနှင့် ထုတ်လုပ်မှုစစ်ဆေးခြင်းသို့ ပြန်လည်ပေးပို့ခြင်း။ S1 ကဲ့သို့သော ကိုးကားချက်များသည် ရင်းမြစ်နောက်ဆက်တွဲသို့ လင့်ခ်များဖြစ်သည်။ နမူနာဖွဲ့စည်းပုံများသည် ဖြန့်ကျက်ခြင်းနှင့် စာရင်းစစ်ဆေးခြင်းဆိုင်ရာ စိတ်ကူးများကို သရုပ်ဖော်ရန်အတွက်သာ အသုံးပြုထားပြီး လက်တွေ့မလုပ်ဆောင်မီ ဗားရှင်း၊ ဖွဲ့စည်းမှုပုံစံ အမွေဆက်ခံမှု၊ မှီခိုမှုနှင့် လုပ်ငန်းစွမ်းဆောင်ရည်တို့ကို အခြေခံ၍ စစ်ဆေးသင့်သည်။

TL;DR- ဦးစားပေး လုပ်ဆောင်ချက်များ

  1. လုံခြုံရေးအဆင့်မြှင့်တင်မှုများကို ဦးစားပေးလုပ်ဆောင်ပါ။ အဘို့ nginx.org Open Source ပက်ကေ့ဂျ်များကို အပ်ဒိတ်လုပ်ပါ။ Stable 1.30 အနည်းဆုံးအကိုင်းအခက် 1.30.6 နှင့် Mainline 1.31 အနည်းဆုံးအကိုင်းအခက် 1.31.7. စိစစ်မည့်ရက်၊ 1.31.8 နောက်ဆုံးပေါ်ပါ။ Mainline လွှတ်ပေးရန်။ ၎င်းတို့သည် သီးခြားအကိုင်းအခက်အခြေခံများဖြစ်သည်။ အကိုင်းအခက်များတစ်လျှောက် ၎င်းတို့၏နံပါတ်များကို မနှိုင်းယှဉ်ပါနှင့်။ S1 S2
  2. ပက်ကေ့ဂျ်ဗားရှင်းအပြည့်အစုံဖြင့် ဖြန့်ဖြူးတပ်ဆင်မှုများကို အတည်ပြုပါ။ Ubuntu 22.04 / 24.04 / 26.04 / 26.10 တွင် ရောင်းချသူ ကျောထောက်နောက်ခံများ ရှိသည်။ Debian 13 (trixie) အနည်းဆုံး 1.26.3-3+deb13u10 လိုအပ်သည်။ အတည်ပြုမှုတွင်၊ Debian 12 (bookworm) ပက်ကေ့ဂျ် 1.22.1-9+deb12u10 သည် သက်ရောက်မှုရှိနေဆဲဖြစ်ကြောင်း မှတ်သားထားသည်။ CVE တစ်ခုစီကို စစ်ဆေးပါ။ Debian 13 အကြံပေးချက်သည် Debian 12 ကို ပုံသေသတ်မှတ်ထားခြင်းမရှိပေ။ S13S14S15
  3. ပေါင်းစပ်ဖွဲ့စည်းမှုငါးခုကို စစ်ဆေးပါ- alias + rewrite + $request_filename , map + regex + ပြောင်းလဲနိုင်သော အကဲဖြတ်ခြင်း၊ aio + ssi + include virtual , HTTP/3 အတူ proxy_request_buffering on , နှင့် ssl_session_cache shared:... အလိုအလျောက်နှင့်အတူ TLS Session Ticket သော့လည်ပတ်မှု။ ညွှန်ကြားချက်တစ်ခု၏ တည်ရှိနေခြင်းသည် အမြတ်ထုတ်ခြင်းကို မတည်ဆောက်နိုင်ပေ။ တောင်းဆိုမှုလမ်းကြောင်းနှင့် ဖွဲ့စည်းမှုနယ်ပယ်ကို အကဲဖြတ်ပါ။ S1 S3 S4
  4. လုပ်ငန်းစဉ်ဟောင်းများနှင့် ကွန်တိန်နာအားလုံးကို အစားထိုးပါ။ nginx -t ကိုဖွင့်ပါ၊ ထို့နောက် ဝန်ဆောင်မှုကို ပြန်လည်စတင်ပါ သို့မဟုတ် ရရှိနိုင်မှု မြင့်မားသော အလှည့်အပြောင်းကို လုပ်ဆောင်ပါ။ ယခင် master/worker လုပ်ငန်းစဉ်များ ထွက်သွားကြောင်း အတည်ပြုပါ။ nginx -s reload တစ်ခုတည်းက လည်ပတ်နေသော binary ပြောင်းလဲသွားကြောင်း သက်သေမပြနိုင်ပါ။
  5. အမှန်တကယ် အဆုံးမှတ်များကို အတည်ပြုပါ- HTTP/1.1၊ HTTP/2၊ HTTP/3 ဖွင့်ထားပါက၊ proxied အပ်လုဒ်များနှင့် API တောင်းဆိုချက်ကောင်များ၊ mTLS သက်သေခံလက်မှတ် အထောက်အထားစိစစ်ခြင်း၊ SSI မှတ်တမ်းများ စာမျက်နှာများနှင့် ဝင်ရောက်ကြည့်ရှုပါ။ ပက်ကေ့ဂျ် သက်သေပြချက်၊ ဗားရှင်း၊ ပုံအညွှန်း၊ အဆုံးမှတ်တစ်ခုစီအတွက် လုပ်ဆောင်နေသော လုပ်ငန်းစဉ်များနှင့် ရလဒ်များကို မှတ်တမ်းတင်ပါ။
  6. ချက်ခြင်းအဆင့်မြှင့်တင်ရန် မဖြစ်နိုင်ပါက၊ သက်ဆိုင်ရာ အစပျိုးအခြေအနေများကို ဖယ်ရှားပါ- မလိုအပ်ဘဲ ပိတ်ပါ။ SSI / AIO သို့မဟုတ် HTTP/3 အားနည်းချက်ကို သုံးသပ်ပါ။ alias / rewrite / map ပြောင်းလဲနိုင်သော အကိုးအကားများနှင့် ယာယီအကဲဖြတ်ပါ။ ssl_session_tickets off; ထိခိုက်မှုအတွက် mTLS ဝန်ဆောင်မှုများ။ WAF , ASLR ၊ နှုန်းကန့်သတ်ချက်များနှင့် ဖွဲ့စည်းမှုပုံစံပြောင်းလဲမှုများသည် အချို့သောအခြေအနေများကိုသာ အကျုံးဝင်ပြီး တရားဝင်ဖာထေးမှုများကို အစားထိုး၍မရပါ။ S3 S4 S8 S12

1. Vulnerability Overview နှင့် Risk Judgement

NGINX သည် 1.30.6 (Stable) နှင့် 1.31.7 (Mainline) ကို 2026 ခုနှစ် အောက်တိုဘာလ 14 ရက်နေ့တွင် ထုတ်ပြန်ခဲ့ပြီး လုံခြုံရေးပြဿနာငါးခုကို ဖြေရှင်းပေးခဲ့ပါသည်။ သုံးမျိုးတွင် အမှိုက်ပုံများ ပြည့်လျှံနေသည် သို့မဟုတ် အသုံးပြုပြီးနောက် အခမဲ့ပါဝင်ပြီး F5 CVSS v4.0 ရမှတ်များ 9.2 / Critical ၏ ရမှတ်များ။ အခြားနှစ်ခုမှာ HTTP/3 တောင်းဆိုမှုခိုင်မာမှုနှင့် TLS ဖောက်သည် သက်သေခံလက်မှတ် စစ်မှန်ကြောင်းကို သက်ရောက်မှုရှိသည်။ S1S2S3

အဆင့်သတ်မှတ်ခြင်းစနစ်များကို ပိုင်းခြားပါ- nginx.org သည် ပြဿနာငါးခုလုံးကို medium အဖြစ် စာရင်းပြုစုထားပြီး F5 CVSS v4.0 နှင့် အချို့သော အမျိုးသားလုံခြုံရေးအေဂျင်စီများနှင့် အချို့သော အမျိုးသားလုံခြုံရေးအေဂျင်စီများသည် မှတ်ဉာဏ်ပြဿနာသုံးခုကို အရေးပါသည့်အဖြစ် အမျိုးအစားခွဲခြားထားသည်။ ဤသည်မှာ ငါးခုလုံးသည် ခြွင်းချက်မရှိ အဝေးကုဒ်ကို လုပ်ဆောင်ခြင်းကို ခွင့်ပြုသည်ဟု မဆိုလိုပါ။ ဖွဲ့စည်းမှုပုံစံ၊ လမ်းကြောင်းရောက်ရှိနိုင်မှုနှင့် တိုက်ခိုက်သူ၏ထိန်းချုပ်မှုပြင်ပရှိ အခြေအနေများ။ Memory ဖောက်ပြန်ခြင်းနှင့် ယုံကြည်စိတ်ချရသော RCE တို့သည် မတူညီသော အထောက်အထားများဖြစ်သည်။ S1S3S4

CVEနည်းပညာဆိုင်ရာ ပြဿနာများနှင့် ပုံမှန်အခြေအနေများcore သက်ရောက်မှုအကဲဖြတ်ခြင်းနှင့် စွန့်ပစ်ခြင်း။
CVE-2026-15176alias လမ်းကြောင်းမြေပုံဆွဲခြင်း + rewrite ပြောင်းလဲခြင်း URI + အကဲဖြတ်ခြင်း $request_filenameအမှိုက်ပုံကြားခံ ပြည့်လျှံမှု၊ Worker ပျက်စီးမှု၊ အချို့သောအခြေအနေများအောက်တွင်အလားအလာ RCEF5 CVSS v4.0 9.2; ပြဿနာဖြေရှင်းခြင်းကို ဦးစားပေးပါ။
CVE-2026-93479HTTP/Stream ဇာတ်ညွှန်းအကဲဖြတ်ခြင်း၊ အထူးသဖြင့် map regex ဖမ်းယူခြင်းနှင့် root လမ်းညွှန်၊ မှတ်တမ်းပြောင်းနိုင်သော အပြန်အလှန်အကိုးအကားသီးသန့်ကြားခံကို ထပ်ရေးပြီး အမှိုက်ပုံမှာ ပြည့်လျှံနေပါသည်။ အချို့သောအခြေအနေများအောက်တွင်အလားအလာ RCEF5 CVSS v4.0 9.2; ယခင်ပြုပြင်ပြီးနောက် ဆုတ်ယုတ်မှုအန္တရာယ်ဖြစ်သည်။
CVE-2026-97205SSI virtual နှင့် AIO/asynchronous လုပ်ဆောင်မှုတို့ ပါဝင်ပါသည်။ ထူးထူးခြားခြား လည်ပတ်မှု အရေအတွက် ပြည့်လျှံနေသည်။အခမဲ့သုံးပါ၊ Worker ပျက်စီးမှု၊ မှတ်ဉာဏ်ယိုယွင်းမှု၊ အလားအလာ RCEF5 CVSS v4.0 9.2; ပုံသေမဟုတ်သော ဖွဲ့စည်းမှုလိုအပ်သည်။
CVE-2026-95101HTTP/3 အမည်မသိဘောင်သည် ကြားခံများကြားတွင် အပိုင်းပိုင်းခွဲထားသည်၊ ပရောက်စီတောင်းဆိုမှုကိုယ်ထည်ကြားခံစနစ်ကို ဖွင့်ထားသည်DATA မဟုတ်သော ဘိုက်များကို အထက်ရေစီးကြောင်း တောင်းဆိုချက်ကိုယ်ထည်ထဲသို့ မှားယွင်းစွာ ထိုးသွင်းခြင်းဖြင့် တောင်းဆိုချက်ကိုယ်ထည်အရွယ်အစား ကန့်သတ်ချက်ကို ကျော်ဖြတ်နိုင်သည်ဤအားနည်းချက်သည် တောင်းဆိုမှုခိုင်မာမှုကို ထိခိုက်စေပါသည်။ ၎င်းကိုယ်တိုင်က အဝေးကုဒ် အကောင်အထည်ဖော်မှု (RCE) ကို ပေးစွမ်းခြင်းမရှိပါ။
CVE-2026-97629မျှဝေထားသော TLS Session Cache၊ အလိုအလျောက်သော့လှည့်ခြင်းနှင့် Worker သော့ပုံတူခြင်းSession Ticket အတုအပ; သက်ရောက်မှုရှိသော mTLS ဝန်ဆောင်မှုအတွက် ကလိုင်းယင့်သက်သေခံလက်မှတ် စစ်မှန်ကြောင်းကို ရှောင်ကွင်းသွားနိုင်သည်။လက်မှတ်အထောက်အထားစိစစ်ခြင်းအမျိုးအစား API ၏ လုပ်ငန်းအကျိုးသက်ရောက်မှုအတွက် အထူးအာရုံစိုက်ရန် လိုအပ်ပါသည်။

အထက်ဖော်ပြပါ CVSS ရမှတ်ကို v4.0 ကို အသုံးပြု၍ F5 မှပေးပါသည်။ တူညီသောအားနည်းချက်သည် CVSS 3.1၊ nginx.org ကိုယ်ပိုင်အဆင့်များနှင့် ဖြန့်ဖြူးမှုပြင်းထန်မှုအဆင့်သတ်မှတ်ချက်များတွင် မတူညီသောပြင်းထန်မှုကိုပြသနိုင်သည်။ S1S3S4

1.1 CVE ရမှတ်များ တစ်ခုတည်းထက် ဖြန့်ကျက်ခြင်း ထိတွေ့မှုကို ဦးစားပေးပါ

ဖြန့်ကျက်ပုံစံအဓိကစုံစမ်းစစ်ဆေးသည့်အချက်များစွန့်ပစ်ရန် ဦးစားပေးအကြံပြုချက်များ
စိတ်ကြိုက် rewrite၊ alias နှင့် ရှုပ်ထွေးသော map အပါအဝင် အများသူငှာ ကွန်ရက်ပြောင်းပြန် proxyCVE-2026-15176၊ CVE-2026-93479 နှင့် မေလမှ ဇူလိုင်လအထိ အားနည်းချက်များကို ပြန်လည်ရေးသားခြင်း/မြေပုံP0- စာရင်းစစ်ပြီး ချက်ချင်းအပ်ဒိတ်လုပ်ပါ။
API / Management plane သည် client လက်မှတ်ကို တစ်ခုတည်းသော သို့မဟုတ် ပင်မဝင်ပေါက် စစ်မှန်ကြောင်းအထောက်အထားအဖြစ် အသုံးပြုနေသည်Session Ticket နှင့် CVE-2026-97629 ၏ မျှဝေထားသော cache configurationP0- အထောက်အထားစိစစ်ခြင်းနယ်နိမိတ်ကို ချက်ချင်းအတည်ပြုပြီး အပ်ဒိတ်လုပ်ပါ။
ပြင်ပ HTTP/3 အပ်လုဒ်လုပ်ခြင်း၊ အခြေအနေပြောင်းလဲခြင်း အင်တာဖေ့စ်၊ ငွေပေးငွေယူအဆင့် API တို့ကို ပံ့ပိုးပေးသည်CVE-2026-95101၊ အထူးသဖြင့် တောင်းဆိုချက်ကိုယ်ထည်သည် နောက်ခံဘက်သို့ ပို့ထားသည်။P0/P1- လုပ်ငန်းအရေးပါမှုအလိုက် စီစဉ်ပါ။
SSI ဒိုင်းနမစ်စာမျက်နှာ သို့မဟုတ် အပြိုင်အဆိုင်လုပ်ထားသော I/O ဖိုင်CVE-2026-97205P1- ပေါင်းစပ်အခြေအနေများကို အတည်ပြုပြီး အမြန်ဆုံးပြုပြင်ပါ။
အငြိမ်စာမျက်နှာများ + ရိုးရိုး HTTP/1.1/2 ပြောင်းပြန် proxy များသာဖွဲ့စည်းမှုပုံစံနှင့် ဗားရှင်းကို စစ်ဆေးရန် လိုအပ်နေသေးသော်လည်း အချို့သော CVE အခြေအနေများ ပျောက်ဆုံးနေနိုင်ပါသည်။P1- အရေးပေါ် လုံခြုံရေး အဆင့်မြှင့်တင်မှု ဝင်းဒိုးတွင် ပါဝင်သည်။
အငြိမ်းစား Kubernetes Community ingress-nginx ကို သုံးပါ။ပရောဂျက်သည် လုံခြုံရေးထိန်းသိမ်းမှုကို ရပ်တန့်စေပြီး အန္တရာယ်များသည် ဤ CVE ငါးခုအတွက် အကန့်အသတ်မရှိပါ။တစ်ဦးချင်း ထိန်းချုပ်ကိရိယာ ရွှေ့ပြောင်းခြင်း အစီအစဉ်ကို ပြုလုပ်ပါ။

P0/P1 သည် အများသူငှာ ကွန်ရက်ထိတွေ့မှုနှင့် အသိအမှတ်ပြု အာရုံခံနိုင်စွမ်းအတွက် ဤဆောင်းပါးတွင် ပေးထားသည့် လည်ပတ်မှုနှင့် ပြုပြင်ထိန်းသိမ်းမှုဆိုင်ရာ အကြံပြုချက်များဖြစ်သည်။ ၎င်းသည် တရားဝင် CVSS အမျိုးအစားခွဲခြားခြင်းမဟုတ်သလို၊ ၎င်းသည် လုပ်ငန်း၏အတွင်းပိုင်းပိုင်ဆိုင်မှုကို အစားထိုးပြီး စွန့်စားရမှုအကဲဖြတ်ခြင်းကို ပြောင်းလဲသင့်သည်။

1.2 သက်ရောက်မှုနယ်နိမိတ်နှင့် တိုက်ခိုက်မှုခွင့်ပြုချက်များ

ဤအသုတ်ရှိ core vulnerabilities များသည် NGINX Data Plane တွင် အဓိကအားဖြင့် တည်ရှိသည်- တိုက်ခိုက်မှု entry point သည် client connection နှင့် request ဖြစ်ပြီး၊ အမှန်တကယ်အကျိုးသက်ရောက်မှုသည် Worker process တွင် ဖြစ်ပေါ်လေ့ရှိပါသည်။ မမ်မိုရီယိုယွင်းမှုအတွက် အမြတ်ထုတ်နိုင်သော အခြေအနေများနှင့် ကိုက်ညီပါက၊ အသုံးပြုသူ အသုံးပြုသူ၊ ကွန်တိန်နာကန့်သတ်ချက်များ၊ Worker ၏ တပ်ဆင်ခြင်းနှင့် ကွန်ရက်ခွင့်ပြုချက်တို့က ယေဘုယျအားဖြင့် ကန့်သတ်ထားသည်။ အလားအလာ RCE သည် root အထူးအခွင့်အရေးများ သို့မဟုတ် အိမ်ရှင်အပေးအယူလုပ်ခြင်းကို အလိုအလျောက် ရည်ညွှန်းခြင်းမဟုတ်ပါ။ S4

သို့သော် လုပ်ငန်းစဉ်သည် အခွင့်ထူးခံမဟုတ်သည့်တိုင်၊ ၎င်းသည် ပရောက်စီအထောက်အထားများ၊ လက်မှတ်ကိုယ်ရေးကိုယ်တာသော့များ၊ အထက်စီးကြောင်းဝန်ဆောင်မှုတိုကင်များ၊ ယာယီဖိုင်များ၊ အတွင်းပိုင်း API နှင့် လက်လှမ်းမီနိုင်သော ကွန်ရက်များပါရှိသော ဖတ်နိုင်သောဖိုင်များကို ဆက်လက်အသုံးပြုနိုင်ပါသည်။ mTLS အတွက်၊ စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းကို ရှောင်ကွင်းခြင်းသည် ကြီးလေးသောစီးပွားရေးအကျိုးဆက်တစ်ခုဖြစ်နိုင်ပြီး ကုဒ်လုပ်ဆောင်မှုဖြင့် တွဲလုပ်ရန်မလိုအပ်ပါ။

2. အကြောင်းရင်းခွဲခြမ်းစိတ်ဖြာ

2.1 NGINX ရှိ အမှားအယွင်းများသော နယ်နိမိတ်သုံးခုကို နားလည်ပါ

NGINX worker သည် တောင်းဆိုမှုအခြေအနေ၊ အပြိုင်အဆိုင်လုပ်ဆောင်မှုများနှင့် ပရိုတိုကောခွဲခြမ်းစိတ်ဖြာမှုများကို ထိန်းသိမ်းထားသည့် ကာလရှည်ကြာ၊ ဖြစ်ရပ်များမောင်းနှင်သည့် လုပ်ငန်းစဉ်တစ်ခုဖြစ်သည်။ ဤအားနည်းချက်သည် အင်ဂျင်နီယာအဆင့်သုံးဆင့်တွင် ကန့်သတ်ချက်များပါဝင်သည်-

  1. ပြောင်းလဲနိုင်သော အကဲဖြတ်ခြင်းနှင့် မှတ်ဉာဏ်အရွယ်အစားသည် တသမတ်တည်းဖြစ်ရမည်- rewrite တောင်းဆိုချက် URI ကိုပြောင်းလဲပြီးနောက်၊ လမ်းကြောင်းမြေပုံဆွဲခြင်းသည် လက်ရှိထိရောက်သော location နှင့် ကိုက်ညီရပါမည်။ script interpreter သည် variable length ကို တွက်ချက်သောအခါ၊ write space သည် အမှန်တကယ် output နှင့် reserved area များကို ဖုံးအုပ်ထားရပါမည်။
  2. Asynchronous လုပ်ဆောင်ချက်များသည် တောင်းဆိုထားသည့် မမ်မိုရီ၏ သက်တမ်းသံသရာကို သက်တမ်းတိုးစေရမည်- မပြီးဆုံးသေးသော ဖိုင်ကိုဖတ်ရှုခြင်းနှင့် စာရေးခြင်း၊ ကက်ရှ်စောင့်ဆိုင်းခြင်း သို့မဟုတ် စာတွဲလုပ်ဆောင်စရာများ ရှိနေသည့်အခါ သက်ဆိုင်ရာ တောင်းဆိုချက် မမ်မိုရီပေါင်းကို ကြိုတင်ထုတ်လွှတ်၍မရပါ။
  3. ပရိုတိုကောအခြေအနေနှင့် လုံခြုံရေးအခြေအနေတို့ကို ရောနှောခြင်း သို့မဟုတ် ချန်လှပ်ခြင်းမပြုရ- HTTP/3 အမည်မသိဘောင်ကျော်ခြင်း၏အရှည်ကို DATA တောင်းဆိုမှုကိုယ်ထည်အရှည်အဖြစ် မှတ်ယူမရနိုင်ပါ။ TLS လက်မှတ်အတည်ပြုခြင်းတွင် ပါ၀င်သည့် သော့ပေါက်များအားလုံးကို စက်ရှင်လက်မှတ်လည်ပတ်မှုအတွင်း မှန်ကန်စွာ ကနဦးစတင်ပြီး ထပ်တူပြုရပါမည်။

အောက်ပါအကြောင်းအရာသည် NGINX အပေါ်ရေစီးကြောင်းပြင်ဆင်ချက် ကတိကဝတ်နှင့် ရောင်းချသူကြေငြာချက်အပေါ် အခြေခံ၍ အစပျိုးနိုင်သည့် ပျက်ကွက်မှုယန္တရားကို ရှင်းပြရန်၊ ဥပမာအပိုင်းအစသည် ခွဲခြမ်းစိတ်ဖြာရန်အတွက်ဖြစ်ပြီး၊ ထုတ်လုပ်မှုပတ်ဝန်းကျင်ကို ပြုပြင်ရန် တိုက်ရိုက်အသုံးပြုနိုင်သည့် ပြီးပြည့်စုံသောကုဒ်မဟုတ်ပါ။ S5S6S7S8S9

2.2 CVE-2026-15176- alias နှင့် ပြန်လည်ရေးထားသော URI အကြား လမ်းကြောင်းမြေပုံသည် မမှန်ကန်ပါ။

NGINX တွင်၊ လိုက်ဖက်သော location နှင့် ၎င်း၏ alias တို့သည် ဖိုင်လမ်းကြောင်းကို ဆုံးဖြတ်သည်။ rewrite လက်ရှိတောင်းဆိုချက် URI ကို ပြောင်းလဲနိုင်သည်။ ပြန်လည်ရေးသားပြီးနောက်၊ မူရင်း location မြေပုံရေးဆွဲခြင်းမှ အသုံးပြုထားသော ယူဆချက်များသည် ကြာရှည်မခံတော့ပါ။

သက်ရောက်မှုရှိသော လုပ်ဆောင်ခြင်းလမ်းကြောင်းသည် တောင်းဆိုချက်အား စစ်ဆေးသည့်အခါ ပြန်လည်ရေးသားထားခြင်းရှိမရှိ လုံလောက်စွာ မစစ်ဆေးခဲ့ပါ။ alias အနေအထား ngx_http_map_uri_to_path() . configuration ကိုဆက်လက်အကဲဖြတ်သည့်အခါ $request_filename ပြန်လည်ရေးသားပြီးနောက်၊ လမ်းကြောင်းကို လက်ရှိနှင့် မကိုက်ညီသော ယူဆချက်များဖြင့် တည်ဆောက်နိုင်ပါသည်။ URI အခြေအနေ၊ နောက်ဆုံးတွင် အစုအဝေးမှတ်ဉာဏ်သို့ စာရေးခြင်းမှ အစပျိုးလာသည်။ S5

ပုံမှန်ပေါင်းစပ်မှု (ဖွဲ့စည်းပုံစစ်ဆေးခြင်းအတွက် တန်ပြန်နမူနာအဖြစ်သာ အသုံးပြုသည်၊ အသုံးချခြင်းကို မထောက်ခံပါ)

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

အန္တရာယ်သည် return တွင် အကန့်အသတ်မရှိပါ- set၊ if၊ add_header၊ log_format စသည်ဖြင့် $request_filename အကဲဖြတ်မှုကို တူညီစွာတောင်းဆိုပါက စစ်ဆေးရန် လိုအပ်ပါသည်။ ဥပမာတွင် return သည် ဤပြည်နယ်လမ်းကြောင်းကို မြင်ရန်လွယ်ကူစေသည်၊ ထုတ်လုပ်မှုဖွဲ့စည်းပုံများအားလုံးကို ပြည့်လျှံစေမည်ဟု တွက်ဆရန် ၎င်းကို အသုံးမပြုနိုင်ပါ။ S5S10

တိုက်ခိုက်မှု၏အကျိုးဆက်များ- တောင်းဆိုမှုတစ်ခုတည်ဆောက်ခြင်းသည် Worker ကို ပြန်လည်စတင်ရန် သို့မဟုတ် ဝန်ဆောင်မှုကို အနှောင့်အယှက်ဖြစ်စေနိုင်သည်။ ASLR ပိတ်ထားခြင်း သို့မဟုတ် ကျော်ဖြတ်နိုင်သော အခြေအနေများအောက်တွင် RCE ဖြစ်နိုင်ချေရှိပါသည်။ အထက်ပိုင်း patch ၏ အဓိကအချက်မှာ အချို့သောကြားခံတစ်ခုကို ချဲ့ထွင်ခြင်းထက် တရားဝင်မဟုတ်တော့သော alias ဆက်စပ်မှုတွင် ပြန်လည်ရေးထားသော URI လမ်းကြောင်းမြေပုံကို အပြီးသတ်ရန် ငြင်းဆိုရန်ဖြစ်သည်။ S5S10

2.3 CVE-2026-93479- “သီးသန့်နေရာ” နှင့် ဇာတ်ညွှန်းအကဲဖြတ်မှုတွင် စစ်မှန်သော ပြောင်းလဲနိုင်သော အရှည်ကြား မကိုက်ညီပါ။

NGINX ၏ HTTP နှင့် Stream မော်ဂျူးများတွင် ပကတိစာကြောင်းများနှင့် ပြောင်းလဲနိုင်သောတန်ဖိုးများကို ရလဒ်စာကြောင်းသို့ ပေါင်းစပ်ပေးသည့် script evaluators များရှိသည်။ အပလီကေးရှင်းနမူနာများတွင် HTTP စာရွက်စာတမ်း root လမ်းကြောင်းများ၊ ဝင်ရောက်ခွင့် မှတ်တမ်းလမ်းကြောင်းများနှင့် Stream တွင် ပြောင်းလဲနိုင်သော စကားရပ်များ ပါဝင်သည်။

map + ပုံမှန်အသုံးအနှုန်းများ၏ အချို့သောဖွဲ့စည်းပုံများသည် map ရလဒ် variable ကို အကဲဖြတ်ခြင်းမပြုမီ အခြားအသုံးအနှုန်းများမှ ဖမ်းယူထားသောတန်ဖိုးများကို ဖတ်နိုင်စေပါသည်။ သီးသန့်အရှည်ဖြင့် script execution method နှင့် ပေါင်းစပ်ထားသော၊ အဟောင်းအကောင်အထည်ဖော်မှုသည် len သီးသန့်နေရာအား အကဲဖြတ်ထားသော length accumulator အတွင်းသို့ ကြိုတင်ရေတွက်မည်ဖြစ်သောကြောင့်၊ နောက်ဆက်တွဲရေးသားထားသော pointer တွက်ချက်မှုများသည် ကြားခံနယ်နိမိတ်နှင့် မကိုက်ညီတော့ပါ။ သတ်သတ်မှတ်မှတ် ပြောင်းလဲနိုင်သော အကဲဖြတ်မှု အစီအစဉ်တစ်ခုတွင်၊ နောက်ဆက်တွဲ စာတန်းရေးသားမှုများသည် သီးသန့်ဧရိယာကို ထပ်ရေးနိုင်ပြီး အစုအဝေးကို လွှမ်းမိုးသွားနိုင်သည်။ S6

ပါဝင်မှုဒြပ်စင်များအဘယ်ကြောင့် သတိပြုသင့်သနည်း။
map တွင် regexမပြောင်းလဲနိုင်သော အကဲဖြတ်မှုကို ဖမ်းယူခြင်းသည် လွတ်လပ်သောဘဝစက်ဝန်းနှင့် သိမ်းဆည်းခြင်းအပြုအမူများ ရှိနိုင်ပါသည်။
$1၊ $2 စသည်ဖြင့် အမည်မသိ ရိုက်ကူးမှုများ။အခြားပုံမှန်အသုံးအနှုန်းများ သို့မဟုတ် အသုံးအနှုန်းများဖြင့် အလွယ်တကူ အစားထိုးရေးသောကြောင့် ပိုင်ဆိုင်မှုကို ခြေရာခံရန် ခက်ခဲစေသည်။
root ရှိ ကိန်းရှင်များလမ်းကြောင်းတည်ဆောက်ခြင်းကို အစပျိုးသောအခါတွင် ဇာတ်ညွှန်းလုပ်ဆောင်ခြင်းနှင့် ကြားခံကြိုတင်မှာယူခြင်း။
log_format/Dynamic မှတ်တမ်းလမ်းကြောင်းတောင်းဆိုချက်တွင် တူညီသောအကဲဖြတ်မှုအမျိုးအစားကို နောက်ပိုင်းတွင် အစပျိုးနိုင်ပါသည်။
stream ရှိ ဇာတ်ညွှန်းအသုံးအနှုန်းများအထက်ပိုင်းပြင်ဆင်မှုသည် ngx_stream_script_run() ကိုလည်း မွမ်းမံပေးသည်။ သင်သည် HTTP module ကိုသာ ပြန်လည်သုံးသပ်၍မရပါ။

အရေးကြီးသော ဆုတ်ယုတ်မှု ဆက်စပ်မှု- ဤအားနည်းချက်နှင့် ဆက်စပ်သော ကုဒ်သည် CVE-2026-42533 ကို ပြင်ဆင်ခဲ့သည့် ယခင်ပြောင်းလဲမှုများနှင့် ဆက်စပ်နေသည်။ Debian 13 အတွက်တရားဝင် DSA တွင် ထိခိုက်မှုကုဒ်ကို အစောပိုင်းလုံခြုံရေး backport မှတစ်ဆင့် trixie ပက်ကေ့ဂျ်ထဲသို့ ထည့်သွင်းခဲ့ကြောင်း ရှင်းလင်းစွာဖော်ပြထားသည်။ ထို့ကြောင့်၊ “ဇူလိုင် map အားနည်းချက် patch ကို ထည့်သွင်းထားသည်” သည် အောက်တိုဘာလ၏ CVE-2026-93479 ကို ဖုံးအုပ်ထားသည်ဟု မဆိုလိုပါ။ လုံခြုံရေးပြင်ဆင်ချက်ကွင်းဆက် အပြည့်အစုံကို စစ်ဆေးသင့်သည်။ S6S14S17

ဤနေရာတွင် ဖြစ်နိုင်ချေရှိသော RCE အန္တရာယ်သည် မှတ်ဉာဏ်ကာကွယ်မှုပတ်ဝန်းကျင်နှင့် ဆက်စပ်နေပြီး map regex တစ်ခုတည်းကို အမည်မသိတိုက်ခိုက်သူများမှ အသုံးချနိုင်မည်ဟု မစွပ်စွဲသင့်ပါ။ S11

2.4 CVE-2026-97205- AIO မပြီးဆုံးသေးသော လည်ပတ်မှုရေတွက် ပတ်၀န်းကျင်ကြောင့် အသုံးပြုခြင်း-အခမဲ့ပြီးနောက်

ဤအားနည်းချက်သည် “SSI ကိုဖွင့်ပြီး UAF” ကိုရလိမ့်မည်မဟုတ်ပါ။ သော့ချက်သည် ပင်မတောင်းဆိုမှုမှ ကိုင်ဆောင်ထားသော အပြိုင်အဆိုင်လုပ်ဆောင်မှု အကိုးအကားရေတွက်မှုတွင် ပါဝင်သည်။

NGINX ကို အသုံးပြု၍ r->main->blocked ကို အသုံးပြု၍ မပြီးပြတ်သေးသော အပြိုင်အဆိုင် လုပ်ဆောင်ခြင်းကို ခြေရာခံရန်၊ အဟောင်း အကောင်အထည်ဖော်မှုတွင် ၎င်းသည် 8-bit အရေအတွက်ဖြစ်သည်။ အချို့သောလမ်းကြောင်းများသည် အရေအတွက်ကို မတိုးမီ အထက်ကန့်သတ်စစ်ဆေးမှုကို မလုပ်ခဲ့ပါ။ တူညီသော အဓိကတောင်းဆိုချက်သည် ထူးထူးခြားခြားလုပ်ဆောင်မှု 256 ခုကို စုဆောင်းသောအခါ၊ အရေအတွက်သည် 255 မှ 0 ပတ်၀န်းကျင်ရှိနိုင်သည်။ နောက်ဆက်တွဲလုပ်ဆောင်မှုများသည် တောင်းဆိုချက်အား ထုတ်လွှတ်ခြင်းမှကာကွယ်ပေးမည့် အပြိုင်အဆိုင်လုပ်ဆောင်မှုမရှိကြောင်း လွဲမှားစွာယုံကြည်သွားမည်ဖြစ်ပြီး၊ ထို့ကြောင့် လုပ်ဆောင်စရာမှ ကိုးကားထားသည့် တောင်းဆိုချက်မမ်မိုရီအစုကို လွှတ်ပေးလိုက်ပါ။ S7

ကျရှုံးခြင်းလုပ်ငန်းစဉ်ကို အောက်ပါအတိုင်း ခွဲခြားနိုင်သည်။

  1. ဆက်စပ်အညီအမျှ I/O/thread လမ်းကြောင်းကို ဖွင့်ထားခြင်းဖြင့်၊ SSI စာမျက်နှာသည် include virtual မှတစ်ဆင့် တောင်းဆိုချက်အများအပြား သို့မဟုတ် လုပ်ဆောင်ချက်များကို ဖတ်ပြပေးပါသည်။
  2. ပင်မတောင်းဆိုချက်တစ်ခု၏ ထူးခြားသောလုပ်ဆောင်မှုများကို ရေတွက်သည့်အကွက်မှ ကိုယ်စားပြုသည့် အထက်ကန့်သတ်ချက်အထိ စုဆောင်းထားသည်။
  3. 8-bit count သည် “ဆိုင်းငံ့ထားသောလုပ်ဆောင်ချက်များမရှိ” ဟု မှားယွင်းစွာဖော်ပြသည်။
  4. တောင်းဆိုချက် မမ်မိုရီအစုအဝေးကို ထုတ်ဝေလိုက်သည်၊ ဖိုင်ဖတ်ခြင်း၊ ကက်ရှ်စောင့်နေချိန် သို့မဟုတ် စာတွဲလုပ်ဆောင်စရာများကို ပြန်ခေါ်ခြင်းများက ၎င်းကို ရည်ညွှန်းချက်များကို ဆက်လက်ထိန်းသိမ်းထားဆဲဖြစ်သည်။
  5. နောက်ဆက်တွဲ asynchronous ပြီးစီးမှုခေါ်ဆိုမှုများသည် လွှတ်တင်ထားသောမမ်မိုရီကို ဝင်ရောက်ကြည့်ရှုနိုင်ပြီး UAF၊ Worker ပျက်ကျခြင်း သို့မဟုတ် ဖြစ်နိုင်ချေရှိသော memory ယိုယွင်းမှုဖြစ်စေသည်။

တရားဝင်ပြင်ဆင်ချက်သည် တောင်းဆိုချက်ခေါင်းစီးဖိုင်တွင် NGX_HTTP_MAX_BLOCKED 250 ကို ပေါင်းထည့်ကာ အထွက်စစ်ထုတ်ခြင်း၊ ကက်ရှ်ဖတ်ခြင်းနှင့် ရေစီးကြောင်းလိုင်းလမ်းကြောင်းတွင် ကန့်သတ်ချက်များကို ပေါင်းထည့်သည်။ သတ်မှတ်ချက်သို့ရောက်ရှိသောအခါ၊ ထပ်တူပြုထားသည့်လမ်းကြောင်းများနှင့် လုပ်ဆောင်ချက်များသည် တစ်ပြိုင်နက်တည်း ပြီးမြောက်ပြီး ၎င်းတို့ကို ဘေးကင်းစွာ မလုပ်ဆောင်နိုင်ပါက၊ ဆိုင်းငံ့ထားသည့် နောက်ထပ်လုပ်ဆောင်စရာများ ထပ်တိုးခြင်းကို ငြင်းပယ်ပါမည်။ S7

အသုံးချနိုင်မှု စီရင်ချက်- SSI၊ AIO၊ အတုအယောင် ပါဝင်မှု၊ တောင်းဆိုချက်ခွဲများနှင့် ဆက်စပ်နေသည့် တူညီသော တောင်းဆိုချက်ကွင်းဆက်တွင် ပေါင်းစပ်လုပ်ဆောင်နိုင်မှု ရှိမရှိ အကဲဖြတ်ရပါမည်။ ၎င်းတို့သည် ပုံမှန်အားဖြင့် ပုံမှန် တည်ငြိမ်သော ပရောက်စီ ဖွဲ့စည်းမှုပုံစံများ မဟုတ်ပေ။ aio off; သို့မဟုတ် ssi off; သည် သတ်မှတ်ထားသော အစပျိုးဒြပ်စင်များကို ဖယ်ရှားနိုင်သော်လည်း လုပ်ငန်းလုပ်ဆောင်မှုအပေါ် မူတည်နေမှုများကို ဦးစွာအတည်ပြုသင့်သည်။ S4S7S25

2.5 CVE-2026-95101- HTTP/3 အမည်မသိဘောင်သည် DATA တောင်းဆိုချက်ကိုယ်ထည်၏ အခြေအနေနှင့် ရောထွေးနေသည်

HTTP/3 frame parser သည် DATA frames ( HTTP request body processing သို့ပေးပို့ရန်လိုအပ်သော) နှင့် ကျော်သွားသင့်သော အမည်မသိဘောင်များအကြား ပိုင်းခြားရပါမည်။ ကွန်ရက်ကြားခံများကို အပိုင်းပိုင်းခွဲသည့်အခါ အမည်မသိဘောင်များ၏ အရှည်ကိုလည်း တိကျစွာထိန်းသိမ်းထားရပါမည်။

ngx_http_v3_parse_data() ၏ ဟောင်းနွမ်းသော အကောင်အထည်ဖော်မှုသည် အမည်မသိဘောင်များကို ကျော်သွားသည့်အခါ “လက်ကျန်ဘိုက်အရေအတွက်ကို ကျော်သွားရမည်” ကို သိမ်းဆည်းရန် st->length အကွက်ကို အသုံးပြုကာ တောင်းဆိုချက်ကိုယ်ထည်မှ စစ်ထုတ်မှုမှ “ကျန်ရှိသော DATA payload length” နှင့် တူညီသောအကွက်ကို ဘာသာပြန်ပေးပါသည်။ အမည်မသိဘောင်သည် ခွဲခြမ်းစိပ်ဖြာခေါ်ဆိုမှုများ အများအပြားကို ချဲ့ထွင်လာပါက၊ ခွဲခြမ်းစိတ်ဖြာမှု ပြတ်တောက်ပြီးနောက် နောက်အသုတ်ကို တောင်းဆိုချက်ကိုယ်ထည်၏ အစိတ်အပိုင်းအဖြစ် မှားယွင်းသွားနိုင်သည်။ S8

အန္တရာယ် နှစ်မျိုး ဖြစ်ပေါ်လာသည်-

  • ကိုယ်ထည်ထိုးသွင်းရန် တောင်းဆိုခြင်း- client မှတင်ပြသော DATA frame မဟုတ်သော payload ကို upstream အပလီကေးရှင်းသို့ပို့နိုင်ပြီး backend မှအမှန်တကယ်လက်ခံရရှိသောဒေတာကိုပြောင်းလဲနိုင်သည်။
  • အရွယ်အစားကန့်သတ်ချက်များကို ကျော်ဖြတ်ခြင်းများ- client_max_body_size နှင့် အခြားကန့်သတ်ချက်များ။ မျှော်လင့်ထားသည့် စစ်ဆေးမှုများသည် DATA လမ်းကြောင်းပေါ်တွင် အာရုံစိုက်ထားပြီး မှားယွင်းစွာ ပြောင်းလဲထားသော အကြောင်းအရာသည် သက်ဆိုင်ရာ အတည်ပြုချက်ကို ကျော်သွားနိုင်သည်။

တရားဝင်ဖော်ပြထားသော သာမာန်အစပျိုးဇာတ်လမ်းမှာ ngx_http_v3_module HTTP/3 တောင်းဆိုချက်ကို လက်ခံရရှိပြီး proxy_request_buffering on ပေးပို့သည့်အခါ ဖြစ်သည်။ ပရောက်စီတောင်းဆိုမှုကိုယ်ထည်ကြားခံအား ngx_http_proxy_module တွင် မူရင်းအတိုင်း ဖွင့်ထားသည်။ ထို့ကြောင့် HTTP/3 ကိုဖွင့်သည့် ပြောင်းပြန် proxy ကို ဦးစွာစစ်ဆေးသင့်သည်။ proxy_request_buffering on; ကို အတိအလင်း မရေးထားသောကြောင့် အစပျိုးအခြေအနေမရှိဟု ယူဆရန် မသင့်လျော်ပါ။ S8S18

ဤအားနည်းချက်၏တိုက်ရိုက်အကျိုးဆက်သည် NGINX core တွင် တိုက်ရိုက်ပြီးပြည့်စုံသော RCE ၏ တူညီသောဖော်ပြချက်မဟုတ်သည့် နောက်ခံတောင်းဆိုမှုခိုင်မာမှုနှင့် လုံခြုံရေးနယ်နိမိတ်ပြောင်းလဲမှုတို့နှင့် သက်ဆိုင်ပါသည်။ အဆုံးစွန်သောစီးပွားရေးအကျိုးသက်ရောက်မှုသည် ဤဘိုက်များကိုမည်ကဲ့သို့ခွဲခြမ်းစိတ်ဖြာပြီး ယုံကြည်စိတ်ချရသောရေစီးကြောင်းအပေါ်တွင်မူတည်သည်။ S24

2.6 CVE-2026-97629- TLS လက်မှတ်လည်ပတ်မှုသည် တတိယသော့အပေါက်ကို လွတ်သွားသည်

ထိခိုက်မှုပုံစံများ၊ NGINX အလိုအလျောက်ထုတ်လုပ်ပြီး လှည့်နိုင်ပါတယ်။ TLS Session Ticket သော့များကို မျှဝေထားသော မမ်မိုရီကက်ရှ်မှတဆင့် အများအပြားကို ခွင့်ပြုသည်။ Worker တူညီသော လက်မှတ်များကို လုပ်ဆောင်ရန်။

သက်ဆိုင်ရာ synchronization logic သည် Worker တစ်ခုစီအတွက် key slot 3 ခုကို ခွဲဝေပေးမည်ဖြစ်ပြီး၊ decryption callback သည် အဆိုပါ slot များကို ဖြတ်သွားမည်ဖြစ်သည်။ သို့သော် အကောင်အထည်ဖော်မှု အဟောင်းသည် တစ်ကြိမ်လျှင် မျှဝေထားသော မမ်မိုရီမှ သော့အပေါက် ၂ ခုကိုသာ မိတ္တူပွားကာ သော့အမည်၊ HMAC သော့နှင့် တတိယအပေါက်၏ AES ကို ဖြစ်ပေါ်စေသည်။ သော့ကို အစပျိုးမရသေးပါ။ လက်မှတ်တစ်ခု၏ သော့အမှတ်အသားကို ဤအခြေအနေဖြင့် ကိုက်ညီပါက၊ လက်မှတ်အတည်ပြုခြင်းနှင့် ကုဒ်ဝှက်ခြင်းအတွက် အသုံးမပြုရသေးသော သော့ပစ္စည်းကို အသုံးပြုနိုင်ပြီး၊ ထို့ကြောင့် TLS စက်ရှင်ကို အတုလုပ်ရန် လမ်းကြောင်းတစ်ခုအဖြစ် ဖန်တီးထားသည်။ S9

အန္တရာယ်များသော အသုံးချမှု ပေါင်းစပ်မှုများသည် ပုံမှန်အားဖြင့်-

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

ဤအားနည်းချက်၏ အဆိုးရွားဆုံးသော လုပ်ငန်းအကျိုးဆက်မှာ ssl_verify_client on; နှင့် အခြားနည်းလမ်းများတွင် အသုံးပြုသူ သက်သေခံလက်မှတ် အထောက်အထားစိစစ်ခြင်း (mTLS) ကို အသုံးပြုသည့် ဝန်ဆောင်မှုများတွင် အတုလုပ်ထားသော ပြန်လည်ရယူရေး ဆက်ရှင်များသည် ဖောက်သည် သက်သေခံလက်မှတ် အတည်ပြုခြင်းကို ကျော်ဖြတ်နိုင်ခြင်းကြောင့် ဖြစ်သည်။ တိုက်ခိုက်မှု၏အောင်မြင်မှုသည် ထိန်းချုပ်၍မရသော အခြေအနေများနှင့်လည်း သက်ဆိုင်ပါသည်။ ပုံမှန် server-side HTTPS လက်မှတ်ကိုသာ အသုံးပြုပြီး “တိုက်ခိုက်သူသည် ဝဘ်ဆိုဒ်အကောင့်ဝင်ခြင်းအားလုံးကို ကျော်လွှားနိုင်သည်” ဖြစ်သောကြောင့် ဖောက်သည်လက်မှတ်စစ်မှန်ကြောင်းကို အထောက်အထားမပြသင့်ပါ။ S9S12

၎င်းသည် TLS စက်ရှင် အထောက်အထားစိစစ်ခြင်း အခြေအနေ ပြဿနာဖြစ်ပြီး ဆာဗာ၏ TLS သီးသန့်သော့ အက်ကွဲသွားခြင်း ရှိမရှိ သို့မဟုတ် အများသူငှာ CA root လက်မှတ်ကို ထိခိုက်ခြင်းရှိမရှိနှင့် ဘာမှမဆိုင်ပါ။ S24

2.7 DoS၊ RCE၊ စစ်မှန်ကြောင်း ရှောင်ကွင်းခြင်းနှင့် သိထားသော exploits များကို နားလည်ပုံ

  • DoS- မမ်မိုရီအမှားက Worker ပျက်စီးသွားခြင်း သို့မဟုတ် အကြီးအကျယ် ပြန်လည်စတင်ခြင်းကို ဖြစ်စေသည်။ အလုံးစုံ မရရှိနိုင်မှုဖြစ်စေသည်ဖြစ်စေ ယာဉ်ကြောအသွားအလာဖိအား၊ လုပ်ငန်းစဉ်ပြန်လည်စတင်နိုင်မှု၊ ချိတ်ဆက်မှုထိန်းသိမ်းချိန်နှင့် ရရှိနိုင်မှုမြင့်မားသော ဗိသုကာနှင့် သက်ဆိုင်သည်။
  • အလားအလာ RCE- ASLR ကို ပိတ်သည့်အခါ သို့မဟုတ် ကျော်ဖြတ်သည့်အခါ အချို့သော ကြေငြာချက်များသည် ကုဒ်လုပ်ဆောင်မှု ဖြစ်နိုင်ခြေရှိကြောင်း ဖော်ပြသည်။ ၎င်းသည် တည်ငြိမ်ပြီး တစ်ကမ္ဘာလုံးအတိုင်းအတာဖြင့် အမိန့်ပေးချက်များကို လုပ်ဆောင်နိုင်သည့် အများသူငှာ တိုက်ခိုက်ရေးကွင်းဆက်ကို ထုတ်ဖော်ခဲ့သည်ဟု မဆိုလိုပါ။ S4
  • ဆေးထိုးခြင်း/အထောက်အထားစိစစ်ခြင်း ရှောင်ကွင်းရန် တောင်းဆိုခြင်း- ၎င်းသည် ကာကွယ်ထားသော လုပ်ငန်းအခြေအနေ သို့မဟုတ် တောင်းဆိုသည့်အကြောင်းအရာကို တိုက်ရိုက်ပြောင်းလဲနိုင်ပြီး ၎င်းသည် shell ကို တိုက်ရိုက်မရရှိသောကြောင့် လျစ်လျူရှု၍မရပါ။
  • တိုက်ခိုက်ရန် ကြိုးပမ်းမှုများကို ရှာဖွေတွေ့ရှိခဲ့သည်- CVE-2026-42945 တွင် 2026 ခုနှစ် မေလတွင် တောရိုင်းအတွင်း အမြတ်ထုတ်ခြင်းဆိုင်ရာ အစီရင်ခံစာများ ပါရှိသည်။ အောက်တိုဘာလတွင် CVEs ငါးခုစလုံးကို ကြီးမားသောအတိုင်းအတာဖြင့် အောင်မြင်စွာ အသုံးချခဲ့သည်ဟု ဆိုလိုရန် ဤသမိုင်းဆိုင်ရာ အချက်အလက်ကို တိုက်ရိုက် ကောက်မချသင့်ပါ။ S23

3. ပြုပြင်ဗားရှင်းနှင့် patch ရွေးချယ်မှု

3.1 NGINX Open Source တရားဝင် patch အခြေခံလိုင်း

ရေဆန်ကိုင်း၊အောက်တိုဘာလတွင် အားနည်းချက်ငါးခုကို အကျုံးဝင်သော ပထမဆုံးတရားဝင်ဗားရှင်းဖြစ်သည်။2026-10-27 ၏ အကြံပြုချက်များ
Stable 1.30.x1.30.6（2026-10-14）အနည်းဆုံး 1.30.6 ကို ထည့်သွင်းပြီး နောက်ဆက်တွဲ လုံခြုံရေး ဗားရှင်းများဖြင့် ဆက်လက်လုပ်ဆောင်ပါ။
Mainline 1.31.x1.31.7（2026-10-14）1.31.8（2026-10-21）
အစောပိုင်း NGINX Open Source ဌာနခွဲ”အားနည်းချက်ဟောင်း ဖာထေးမှုများကို အသုံးပြုထားသည်” ပေါ်အခြေခံ၍ ၎င်းကို အကဲဖြတ်၍မရပါ။ထိန်းသိမ်းထားသောဌာနခွဲသို့ ဦးစွာပြောင်းရွှေ့ပါ။ မဟုတ်ပါက၊ ရောင်းချသူသည် CVE-by-CVE အခြေခံပေါ်တွင် ကျောထောက်နောက်ခံပြုခြင်းဆိုင်ရာ တရားဝင်အထောက်အထားများပေးရန် လိုအပ်ပါသည်။

ဤအရာများသည် nginx.org အထက်ရေစီးကြောင်း အရင်းအမြစ်ကုဒ်/တရားဝင်ဌာနခွဲ၏ ဗားရှင်းနိဂုံးများဖြစ်ပြီး ဖြန့်ဖြူးရောင်းချသူမှ ပံ့ပိုးထားသော backported ပြင်ဆင်မှုများဖြင့် လုံခြုံရေးအထုပ်ကို တိုက်ရိုက်ငြင်းဆိုရန်အတွက် အသုံးမပြုသင့်ပါ။ 1.31.6 ၏တန်ဖိုးသည် 1.30.6 ထက်ကြီးသော်လည်း၊ ၎င်းသည် ပင်မလိုင်းဌာနခွဲ၏ patch အခြေခံလိုင်းထက် နိမ့်နေသေးသည်။ S1S2

3.2 CVE ငါးခု၏ အထက်ပိုင်းသက်ရောက်မှု နယ်ပယ်

အောက်ဖော်ပြပါ အပိုင်းများကို nginx.org လုံခြုံရေးစာစောင်၏ မူရင်းစာသားအတိုင်း ဖော်ပြထားပြီး “လက်ရှိ လုပ်ဆောင်နေသည့် ဌာနခွဲ” နှင့် “အမှန်တကယ် ဖွဲ့စည်းမှုလမ်းကြောင်း” တို့နှင့် တွဲဖက်နားလည်ရန် လိုအပ်သည်-

CVEရေစီးကြောင်းတက်ဂ်များ သက်ရောက်မှုရှိသော ဗားရှင်းများတရားဝင်အမည်တပ်ထားသော ပုံသေဗားရှင်း
CVE-2026-151760.1.29–1.31.6၎င်းတို့၏ သက်ဆိုင်ရာဌာနခွဲများတွင် 1.30.6+ သို့မဟုတ် 1.31.7+၊
CVE-2026-934791.30.0–1.30.5，1.31.2–1.31.6အထက်ပါအတိုင်းပါပဲ။
CVE-2026-972050.8.11–1.31.6အထက်ပါအတိုင်းပါပဲ။
CVE-2026-951011.25.0–1.31.6အထက်ပါအတိုင်းပါပဲ။
CVE-2026-976291.23.2–1.31.6အထက်ပါအတိုင်းပါပဲ။

CVE-2026-93479 တွင် သီးခြားမိတ်ဆက်ဗားရှင်း ကန့်သတ်ချက်များ ရှိသည်။ NGINX ဗားရှင်းဟောင်းတိုင်းသည် ဤဆုတ်ယုတ်မှုအပေါ် သက်ရောက်မှုမရှိပါ။ အစောပိုင်း map regex အားနည်းချက် CVE-2026-42533 ၏ အပြင်ဘက်ရှိ ဗားရှင်းအဟောင်းများကို သက်ရောက်မှုရှိနိုင်သေးသည်။ S1

3.3 Ubuntu- ဖြန့်ဖြူးရေး ကျောထောက်နောက်ခံများ (USN-8955-1)

Canonical USN-8955-1 သည် အောက်တိုဘာလ 26 ရက်၊ 2026 တွင် Ubuntu တည်ဆောက်မှုလေးခုအတွက် လုံခြုံရေးအပ်ဒိတ်ကို ပေးသည်- S13

Ubuntu ဗားရှင်းnginx နှင့် တူညီသော အရင်းအမြစ် ပက်ကေ့ချ် ပုံသေဗားရှင်းဖော်ပြချက်
22.04 LTS1.18.0-6ubuntu14.22၎င်းသည် ရောင်းချသူ၏ ကျောထောက်နောက်ခံဖြစ်သည်။ အထက်ပိုင်းဗားရှင်းနံပါတ်သည် 1.18.0 ကိုပြသနေဆဲဖြစ်သည်။
24.04 LTS1.24.0-2ubuntu7.19အထက်ပါအတိုင်းပါပဲ။
26.04 LTS1.28.3-2ubuntu1.12အထက်ပါအတိုင်းပါပဲ။
26.101.30.4-7ubuntu1.1အထက်ပါအတိုင်းပါပဲ။

ကြေညာချက်တွင် nginx-core၊ nginx-extras၊ nginx-full နှင့် nginx-light ကဲ့သို့ တူညီသော တူညီသော ပက်ကေ့ဂျ်များ၏ သက်ဆိုင်သော ပုံသေဗားရှင်းများ ပါရှိသည်။ nginx -v မှပြသထားသည့် အထက်ပိုင်းအပိုင်းမှ ပြုပြင်ရန်ရှိမရှိ ကောက်ချက်မဆွဲပါနှင့်။ Ubuntu 24.04 နှင့် 1.24.0-2ubuntu7.19 တို့ကို ဤရောင်းချသူမှ ဖာထေးထားသော်လည်း မည်သည့်အရင်းအမြစ်မှ 1.24.0 သည် မွေးရာပါမလုံခြုံပါ။

Ubuntu ဒါကိုလည်း တရားဝင် ရှင်းရှင်းလင်းလင်း မှတ်သားထားပါတယ်။ CVE-2026-95101 သက်ရောက်မှုသာရှိသည်။ Ubuntu 26.04 / 26.10 , နှင့် CVE-2026-97629 သက်ရောက်မှုသာရှိသည်။ Ubuntu 24.04 / 26.04 / 26.10. ဤတွင် Ubuntu အခြားဖြန့်ဖြူးမှုများသို့ တိုက်ရိုက်မမြှင့်တင်နိုင်သော ထုပ်ပိုးမှုနှင့် လုပ်ဆောင်မှုဆိုင်ရာ နယ်ပယ်။ S13

3.4 Debian- ဗားရှင်းများအကြား ကွဲပြားမှုများကို သီးခြားစီ စစ်ဆေးရပါမည်။

Debian အကြံပေး DSA-6575-1 (2026-10-21) သည် ဤ CVE ငါးခုကို အကျုံးဝင်ပြီး Debian 13 / trixie အတွက် ပုံသေ nginx ပက်ကေ့ဂျ်ကို ခွဲခြားသတ်မှတ်သည်-

1.26.3-3+deb13u10

သို့သော်လည်း ဤအစီရင်ခံစာကို အတည်ပြုသည့်အချိန်မှစ၍ Debian 12 / bookworm အတွက် 1.22.1-9+deb12u10 ကို Debian Security Tracker မှ အားနည်းချက်အဖြစ် အလံပြနေဆဲဖြစ်သည်။ ထို့ကြောင့်-

  • Debian 13 DSA-6575-1 အရ အပ်ဒိတ်လုပ်ပြီး လက်ခံလိုက်ပါ။
  • Debian 12 သည် လက်ရှိ Security Tracker သို့မဟုတ် ELTS ရောင်းချသူမှ ပံ့ပိုးပေးသော လုံခြုံရေး ပြင်ဆင်ချက်များကို စစ်ဆေးရပါမည်။ ကြေညာချက်တွင် ပြင်ဆင်ချက်ကို အတည်ပြုခြင်းမပြုမီ၊ apt upgrade ၏အောင်မြင်မှုအပေါ်အခြေခံ၍ အချက်ငါးချက်လုံးကို ပြင်ဆင်ပြီးဖြစ်ကြောင်း မကြေငြာပါနှင့်။
  • Debian ရင်းမြစ်ပက်ကေ့ဂျ်သည် nginx.org ဗားရှင်းနံပါတ်နှင့် ကင်းသော patch set တစ်ခုကို သယ်ဆောင်နိုင်သည်။ စိတ်ကြိုက်တည်ဆောက်မှုများအတွက်၊ ပြီးပြည့်စုံသော အရင်းအမြစ်ကုဒ် ပက်ကေ့ချ်ပြင်ဆင်ချက်အစုံကို စစ်ဆေးရန် လိုအပ်ပြီး အထက်စီးကြောင်း ကွန်မန့်တစ်ခုအား ကူးယူရုံဖြင့် ပြီးမြောက်သည်ဟု ယူဆ၍မရပါ။

အထက်ပါထူးခြားချက်သည် DSA နှင့် CVE ခြေရာခံမှတ်တမ်းများပေါ်တွင် အခြေခံထားသည်။ S14S15S16

3.5 NGINX Plus၊ njs နှင့် Ingress Controller

ထုတ်ကုန်/အစိတ်အပိုင်းများလုံခြုံရေးရွေးချယ်မှုနှင့် အတည်ပြုခြင်း အဓိကအချက်များ
NGINX Plus (လုပ်ငန်းသုံးဗားရှင်း)F5 နှင့်သက်ဆိုင်သည့် Plus ဌာနခွဲ၏ ကြေညာချက်ကို ကိုးကားပြီး အဆင့်မြှင့်ရန် ညွှန်ကြားချက်များကို ကျေးဇူးပြု၍ ကြည့်ပါ။ အတည်ပြုချိန်တွင် နောက်ဆုံး CR သည် PLS.37.2.0.1 ဖြစ်ပြီး LTS ၏ လုံခြုံရေးတည်ဆောက်မှုသည် PLS.37.0.7.1 ဖြစ်သည်။ Plus ဗားရှင်းနှင့် ပါဝင်သော backport ကို Open Source ၏ 1.30/1.31 သတ်မှတ်ချက်များဖြင့် တိုက်ရိုက်အစားထိုး၍မရပါ။ S19
njs / ngx_http_js_module2026-10-14 သည် njs 1.0.2 ကို ထုတ်ပြန်ပြီး CVE-2026-101019 နှင့် CVE-2026-101025 ကို ပြင်ဆင်သည်။ အကယ်၍ သင်သည် njs ကိုအသုံးပြုနေပါက၊ သင်သည် NGINX နှင့် module ၏ လိုက်ဖက်မှုကိုလည်း စစ်ဆေးရပါမည်။ S20
F5 NGINX Ingress Controller / Gateway FabricNGINX core သည် ဆက်စပ်သော်လည်း လွတ်လပ်သောဆော့ဖ်ဝဲလ်ဖြန့်ဖြူးရေးကွင်းဆက်တစ်ခုဖြစ်သည်။ သက်ဆိုင်ရာ ထိန်းချုပ်ကိရိယာများ၊ ရုပ်ပုံများနှင့် ထုတ်ပြန်ချက်မှတ်စုများဖြင့် သက်ဆိုင်ရာ အားနည်းချက်များကို ပြင်ဆင်ပါ။ Pod တွင် NGINX binary တစ်ခုကို အစားထိုး၍မရပါ။
Kubernetes အသိုင်းအဝိုင်း kubernetes/ingress-nginxပရောဂျက်ကို 2026 ခုနှစ် မတ်လတွင် ရပ်ဆိုင်းလိုက်ပြီး လုံခြုံရေး ပြုပြင်ထိန်းသိမ်းမှု အသစ်များကို ဆောင်ရွက်ပေးတော့မည် မဟုတ်ပါ။ F5 NGINX Ingress Controller အတွက် ၎င်း၏ထုတ်လွှတ်မှုနံပါတ်ကို လွဲမှားစေမည့်အစား ထိန်းသိမ်းထားသော ထိန်းချုပ်ကိရိယာ သို့မဟုတ် Gateway API သို့ ပြောင်းရွှေ့ရန် စီစဉ်သင့်သည်။ S21

3.6 မည်သည့် Patch ကို သင် အမှန်တကယ် ရွေးချယ်သင့်သနည်း။

ဖြန့်ကျက်ပုံစံအလေ့အကျင့်များကို အကြံပြုထားသည်။ပြုပြင်ကြောင်းအထောက်အထား
nginx.org တရားဝင် DEB/RPM ပက်ကေ့ဂျ်အထက်ပိုင်းဌာနခွဲ၏ ပုံသေဗားရှင်းသို့ အဆင့်မြှင့်ပါ။nginx -v/-V၊ ပက်ကေ့ဂျ်ရင်းမြစ်၊ တရားဝင်လုံခြုံရေးကြေညာချက်
Ubuntu/Debian တရားဝင်သိုလှောင်မှုရောင်းချသူ လုံခြုံရေးပက်ကေ့ဂျ်များကို ထည့်သွင်းပါ။ပက်ကေ့ဂျ်ဗားရှင်းအပြည့်အစုံ + ရောင်းချသူ USN/DSA + CVE အခြေအနေ
RHEL/Alma/Rocky/SUSE/အခြားဖြန့်ဖြူးမှုများသီးခြားဖြန့်ချီရေး လုံခြုံရေးစာစောင်များနှင့် ပက်ကေ့ဂျ်ဗားရှင်းများအလိုက် အဆင့်မြှင့်ပါ။သက်ဆိုင်ရာ ရောင်းချသူ CSAF/ကြေငြာချက်၊ Ubuntu/Debian ဗားရှင်းကို အသုံးပြု၍မရပါ။
တရားဝင် သို့မဟုတ် စိတ်ကြိုက်ပုံများအတည်ပြုထားသော ပြုပြင်ထားသောပုံအား ပြန်လည်တည်ဆောက်ပါ သို့မဟုတ် ဆွဲထုတ်ကာ ၎င်းကို လှိမ့်ကာ အစားထိုးပါ။ရုပ်ပုံအကျဉ်းချုပ်၊ SBOM တည်ဆောက်မှု၊ ပေါ့ဒ်/ပုံးပုံအိုင်ဒီကို လုပ်ဆောင်နေသည်။
ကိုယ်တိုင်စုစည်းထားသော NGINX၊ OpenResty၊ Tengine သို့မဟုတ် ပြင်ပကုမ္ပဏီ module များဖြင့် ဖာထေးထားသော ဗားရှင်းများထိန်းသိမ်းသူ၏ လုံခြုံရေးဗားရှင်းကို ဦးစားပေးအသုံးပြုရန်၊ လိုအပ်သည့်အခါ ပစ်မှတ်ရင်းမြစ်သစ်ပင်အတွက် ပြန်လည်သုံးသပ်ထားသော patch backports များကို လုပ်ဆောင်ပါ။အားနည်းချက်ပြင်ဆင်ချက်ငါးခု၊ ABI/module လိုက်ဖက်ညီမှု၊ ယူနစ်နှင့် လုပ်ငန်းဆုတ်ယုတ်မှု

OpenResty နှင့် Tengine တို့သည် မတူညီသော ဖြန့်ချိရေးစနစ်များဖြစ်သည်။ ဤဇယားသည် အတည်ပြုခြင်းနည်းလမ်းကိုသာ ဖော်ပြပါသည်။ စံ NGINX နှင့် တစ်ချိန်တည်းတွင် ၎င်း၏ဗားရှင်းများအားလုံးကို ထိခိုက်သည်ဟု မဆိုလိုပါ၊ အထက်စီးကြောင်းကုဒ် patch ကို ခြွင်းချက်မရှိ အသုံးချနိုင်မည်မဟုတ်ပေ။

4. တရားဝင် ပြုပြင်ခြင်း လုပ်ငန်းစဉ်

4.1 ပြင်ပအသွားအလာ လက်ခံရရှိသည့် အမှန်တကယ်ဖြစ်ရပ်များစာရင်း

ဝင်ရောက်မှုတစ်ခုစီအတွက် အနည်းဆုံး စုစည်းပါ-

  • ဒိုမိန်းအမည်၊ load balancing/CDN/ edge proxy link၊ origin site exposure method နှင့် network protocol ကို အသုံးပြုထားသည်။
  • NGINX ထုတ်ကုန်များ (Open Source၊ Plus၊ Ingress စသည်ဖြင့်)၊ ဗားရှင်းအပြည့်အစုံ၊ ပက်ကေ့ဂျ်သိုလှောင်မှုအရင်းအမြစ်၊ ပုံအညွှန်း။
  • nginx -V သည် တည်ဆောက်မှု modules များနှင့် compilation parameters များကိုပြသသည်၊ njs၊ Lua၊ OpenResty နှင့် third-party dynamic modules များ ရှိမရှိ။
  • master/worker PID၊ Service Unit/Container/Pod၊ Replica နှင့် Worker Node ကို အမှန်တကယ် လုပ်ဆောင်နေသည်။
  • အမှန်တကယ်ထိရောက်သော http/stream, server, location, include ဖွဲ့စည်းမှုပုံစံများ။
  • HTTP/3၊ mTLS၊ SSI/AIO၊ ပြောင်းလဲနေသောမှတ်တမ်းလမ်းကြောင်း၊ ရှုပ်ထွေးသော map နှင့် regex ဖမ်းယူမှုကို ဖွင့်ရန်ရှိမရှိ

မူရင်း /etc/nginx/nginx.conf ကို မစစ်ဆေးပါနှင့်။ ထုတ်လုပ်မှုပတ်ဝန်းကျင်သည် ဆိုက်များစွာ၊ TLS နှင့် include မှတဆင့် module configurations များကို တင်လေ့ရှိသည်။ NGINX တပ်ဆင်မှုလမ်းကြောင်းများစွာ သို့မဟုတ် ပရောက်စီအလွှာများစွာလည်း ရှိနိုင်သည်။

4.2 ဗားရှင်းနှင့် စုစည်းအချက်အလက်ကို စစ်ဆေးပါ။

# 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 သည် command-line လမ်းကြောင်းတွင်တွေ့ရှိရသော binary တည်ဆောက်မှုကို အစီရင်ခံသည်; အသုံးပြုနေသည့် worker သည် ၎င်းကို တင်ထားကြောင်း သက်သေမပြနိုင်ပါ။ nginx -v သည် ဖြန့်ဖြူးမှု၏ ပက်ကေ့ဂျ်နောက်ဆက်တွဲကို ချန်လှပ်ထားနိုင်သည်၊ ထို့ကြောင့် ပက်ကေ့ဂျ်မန်နေဂျာ သို့မဟုတ် ထောက်ပံ့ရေးကွင်းဆက်မှတ်တမ်းများကို စစ်ဆေးကြည့်ပါ။

4.3 ထိရောက်သောဖွဲ့စည်းမှုပုံစံကို ထုတ်ယူပြီး တည်ငြိမ်စစ်ဆေးခြင်း ပထမအကျော့ကို လုပ်ဆောင်ပါ

nginx -T သည် ဖွဲ့စည်းမှုပုံစံကို စမ်းသပ်ပြီး ပေါင်းစပ်ဖွဲ့စည်းပုံကို စွန့်ပစ်ပါမည်။ အထွက်တွင် အထောက်အထားစိစစ်ခြင်းဆိုင်ရာ အထောက်အထားများ၊ သော့လမ်းကြောင်းများ၊ စက်တွင်းရှိ လက်ခံဆောင်ရွက်ပေးသူအမည်များ စသည်တို့ကဲ့သို့ အရေးကြီးသောအချက်အလက်များ ပါဝင်နိုင်ပါသည်။ root ခွင့်ပြုချက်များနှင့် သီးသန့်ဖိုင်ခွင့်ပြုချက်များဖြင့် ထိန်းချုပ်ထားသော terminal ကို သိမ်းဆည်းရန် အကြံပြုထားပြီး မူရင်းဖိုင်များကို အများသူငှာ အလုပ်အမိန့်များတွင် မတင်ပါနှင့်။

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

၎င်းသည် ယုံကြည်စိတ်ချရသော CVE အလိုအလျောက်သတ်မှတ်ခြင်းကိရိယာတစ်ခုမဟုတ်ဘဲ ကိုယ်စားလှယ်လောင်းလမ်းကြောင်းရှာဖွေသူသာဖြစ်သည်။

  1. grep သည် တူညီသော location သို့မဟုတ် တူညီသော တောင်းဆိုမှု အကဲဖြတ်ကွင်းဆက်တွင် ကိန်းရှင်များ တည်ရှိခြင်း ရှိမရှိကို မဆုံးဖြတ်နိုင်သလို ဖွဲ့စည်းမှုဆိုင်ရာ အမွေဆက်နွယ်မှုကိုလည်း ဖြတ်တောက်၍မရပါ။
  2. proxy_request_buffering on၊ အချို့သော ကက်ရှ်နှင့် လက်မှတ်ဖွဲ့စည်းပုံများသည် ပုံသေတန်ဖိုးများ ရှိပြီး သက်ဆိုင်ရာ ညွှန်ကြားချက်များကို မရေးသားခြင်းသည် အန္တရာယ် ပျောက်ကွယ်သွားသည်ဟု မဆိုလိုပါ။
  3. ပြောင်းပြန်ပရောက်စီများ၊ CDN၊ ကွန်တိန်နာဆိုက်ကားများ၊ သို့မဟုတ် ထိန်းချုပ်ကိရိယာများမှ ထုတ်လုပ်ထားသော စည်းမျဉ်းများသည် ကိုယ်တိုင်စစ်ဆေးထားသောဖိုင်များနှင့် ကွဲပြားနိုင်သည်။
  4. NGINX Plus ၏ဝိသေသလက္ခဏာများနှင့်ပြောင်းလဲနေသော module များကို ၎င်းတို့၏သက်ဆိုင်ရာတရားဝင်စီမံခန့်ခွဲမှုကိရိယာများကို အသုံးပြု၍ အတည်ပြုရန် လိုအပ်ပါသည်။

4.4 ယုံကြည်စိတ်ချရသော ချန်နယ်များမှတစ်ဆင့် ပြင်ဆင်မှုကို အသုံးချပါ။

Debian/Ubuntu (တရားဝင် ဖြန့်ဖြူးရေး သိုလှောင်ခန်း)-

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

ဤအမိန့်တော်အစုံသည် မရရှိနိုင်သေးသော လေဖိအားနည်းရပ်ဝန်းမှ လုံခြုံရေးပြင်ဆင်ချက်များကို မထုတ်ပေးနိုင်ပါ။ အထူးသဖြင့် Debian 12 အတွက်၊ အဆင့်မြှင့်ထားသော ပက်ကေ့ချ်သည် လုံခြုံရေးခြေရာခံစနစ်ဖြင့် အားနည်းနေသေးသည်ဟု ယူဆပါက၊ အပိုရောင်းချသူ ပြုပြင်မှု၊ သီးခြားခွဲထုတ်ခြင်း သို့မဟုတ် ရွှေ့ပြောင်းခြင်းအစီအမံများ လိုအပ်ပါသည်။ S13S14S15

nginx.org တရားဝင်ပက်ကေ့ဂျ်-

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

ကိုယ်တိုင်စုစည်းထားသော၊ OpenResty၊ Tengine သို့မဟုတ် NGINX Plus ကိုအသုံးပြုပါက၊ သက်ဆိုင်ရာထိန်းသိမ်းသူမှပံ့ပိုးပေးထားသော ပြင်ဆင်သည့်ဗားရှင်းကိုအသုံးပြုပြီး nginx.org၊ ဖြန့်ဖြူးမှုနှင့် ပြင်ပအဖွဲ့အစည်း သိုလှောင်မှုပက်ကေ့ဂျ်များကို မရောနှောပါနှင့်။ မူရင်း binaries/ပုံများ၊ စီစဉ်သတ်မှတ်မှုများ၊ လက်မှတ်များနှင့် rollback ဖြန့်ကျက်ခြင်းဖော်ပြချက်များကို ထိန်းသိမ်းထားသင့်သည်။

ကွန်တိန်နာများ/Kubernetes- မပြောင်းလဲနိုင်သော ရုပ်ပုံအား အပ်ဒိတ်လုပ်ပါ၊ ၎င်း၏ အချေအတင်ကို မှတ်တမ်းတင်ပြီး ပုံတူဟောင်းအားလုံးကို အဆင့်လိုက် ဖြန့်ချိခြင်းဖြင့် အစားထိုးပါ။ kubectl rollout status သည် ဖြန့်ကျက်ထိန်းချုပ်ကိရိယာ ပြီးဆုံးကြောင်းကိုသာ အတည်ပြုပါသည်။ ပုံအညွှန်းများ၊ အဝင်လမ်းကြောင်းနှင့် ကျန်းမာရေးနှင့်မညီညွတ်သော ပုံတူများကိုလည်း စစ်ဆေးပါ။

4.5 ဖွဲ့စည်းမှုပုံစံကို အတည်ပြုပြီး 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'

binary အသစ်တစ်ခု လုပ်ဆောင်နေကြောင်း သက်သေအဖြစ် nginx -s reload အား မဆက်ဆံပါနှင့်။ သာမန်ဖွဲ့စည်းမှုပုံစံ ပြန်လည်စတင်ခြင်းသည် master အဟောင်းအား ၎င်း၏လုပ်ဆောင်နိုင်မှုကို အစားထိုးခြင်းမရှိဘဲ အလုပ်သမားအသစ်များ စတင်စေပါသည်။ NGINX သည် သီးခြားအွန်လိုင်း binary အဆင့်မြှင့်တင်မှုလုပ်ငန်းစဉ်ကို ပံ့ပိုးပေးသည်၊ သို့သော် ၎င်းသည် ထပ်ဆင့်အဆင့်များနှင့် အတည်ပြုချက် လိုအပ်သည်။ သတ်မှတ်ထားသော လုပ်ထုံးလုပ်နည်းမရှိဘဲ၊ ဝန်ဆောင်မှုပြန်လည်စတင်ခြင်းဖြင့် နောက်တွင် ရရှိနိုင်မှုမြင့်မားသော အသွားအလာခလုတ်ကို အသုံးပြုပါ သို့မဟုတ် အစားထိုးကွန်တိန်နာများကို ထုတ်ပစ်ပါ။ S22

အကယ်၍ သင်သည် NGINX ကို systemd socket၊ container entry script မှတဆင့် စီမံခန့်ခွဲပါက၊ systemctl restart nginx သည် instance အားလုံးကို အကျုံးဝင်သည်ဟု တိုက်ရိုက်ယူဆမည့်အစား အမှန်တကယ် launch target နှင့် process path ကို စစ်ဆေးသင့်ပါသည်။

4.6 စစ်မှန်သောပြင်ပဝင်ပေါက်မှ စီးပွားရေးဆုတ်ယုတ်မှုကို လက်ခံပြီး လုပ်ဆောင်ပါ။

အနည်းဆုံးလုပ်ဆောင်ရန် အကြံပြုထားသည်-

  • ပုံမှန် HTTPS၊ ပြန်လည်ရေးသားထားသော လမ်းကြောင်းများ၊ တည်ငြိမ်သောအရင်းအမြစ်များနှင့် alias မြေပုံညွှန်းစာမျက်နှာများ မှန်ကန်ပါသလား။
  • ပုံမှန် map ဖြန့်ဖြူးမှု၊ ပြောင်းလဲနိုင်သော root လမ်းကြောင်း၊ ဝင်ရောက်ခွင့် မှတ်တမ်းလမ်းကြောင်း၊ SNI/certificate လမ်းကြောင်းနှင့် Stream ပရောက်စီ မှန်ကန်ပါသလား။
  • ပုံမှန် အပ်လုဒ်များ၊ အတုံးလိုက် အပ်လုဒ်များ၊ API တောင်းဆိုမှုများ နှင့် HTTP/3 (ဖွင့်ထားသောအခါ) အတွက် ရေစီးကြောင်း ပမာဏ ကန့်သတ်ချက်များသည် မျှော်လင့်ထားသည့်အတိုင်း ရှိနေသေးသည်။
  • mTLS- တရားဝင် လက်မှတ် တောင်းဆိုချက်များ အောင်မြင်သင့်သည်။ ပျောက်ဆုံးနေသော၊ သက်တမ်းကုန်သွားသော သို့မဟုတ် ခွင့်ပြုချက်မရှိဘဲ လက်မှတ်များကို ပယ်ချသင့်ပြီး TLS ပြန်လည်စတင်ခြင်း/ပြန်လည်ချိတ်ဆက်ခြင်းသည် ခွင့်ပြုချက်များကို မတော်တဆ မပြောင်းလဲသင့်ပါ။
  • SSI စာမျက်နှာနှင့် asynchronous ဖိုင်ဝင်ရောက်ခွင့်သည် ပုံမှန်ဟုတ်မဟုတ်၊ အမှားမှတ်တမ်းသည် မှတ်ဉာဏ်ရည်ညွှန်းချက်များ သို့မဟုတ် Worker ထပ်ခါတလဲလဲ ပျက်ကျမှုများအတွက် ပုံမှန်မဟုတ်သော တောင်းဆိုချက်များကို မပြပါ။
  • အသွားအလာ ခလုတ်ပြီးနောက်၊ ဗားရှင်းဟောင်း လုပ်ငန်းစဉ်နှင့် ပုံဟောင်းပုံတူသည် ထွက်သင့်သည်။

စမ်းသပ်ခြင်းကို ကိုယ်ပိုင် သို့မဟုတ် ခွင့်ပြုထားသော ပတ်ဝန်းကျင်တွင် ပြုလုပ်ရမည်။ ပုံမှန်တောင်းဆိုမှု မီးခိုးစစ်ဆေးမှုသည် မှတ်ဉာဏ်ချို့ယွင်းချက်ကို ပြင်ဆင်ထားကြောင်း သက်သေမပြနိုင်ပါ။ နောက်ဆုံးတွင်၊ ပေးသွင်းသူ၏ ပုံသေဗားရှင်း၊ အရင်းအမြစ်ကုဒ် patch နှင့် runtime စမ်းသပ်မှုကို လက်ခံရန်အတွက် ပူးတွဲလက်ခံရပါမည်။

5. ချက်ခြင်းအဆင့်မြှင့်ခြင်းမဖြစ်နိုင်သည့်အခါ လျော့ပါးရေးအစီအမံများ

ဤကဏ္ဍသည် ဖာထေးအစားထိုးမှုမဟုတ်ဘဲ အန္တရာယ်လျှော့ချရေးရွေးချယ်မှုတစ်ခုဖြစ်သည်။ ယာယီဖွဲ့စည်းပုံပြင်ဆင်မှုပြောင်းလဲမှုအားလုံးကို အရန်သိမ်းဆည်းထားသင့်ပြီး၊ nginx -t ကို လုပ်ဆောင်ပြီး အစုလိုက်အစီအရီထုတ်ကာ လိုအပ်ပါက အမြန်ပြန်လှန်ရပါမည်။ S3S4

5.1 ပြင်ပထိတွေ့မှုအပေါ်အခြေခံ၍ အသွားအလာဦးစားပေးကို ထိန်းချုပ်ပါ။

အချိန်မီ အဆင့်မြှင့်၍မရသော ဝန်ဆောင်မှုများ၏ တိုက်ခိုက်ရေးမျက်နှာပြင်ကို လျှော့ချရန် ဦးစားပေးလုပ်ဆောင်ပါ- စီမံခန့်ခွဲမှုမျက်နှာပြင်နှင့် အတွင်းပိုင်း API ယုံကြည်ရသော ရင်းမြစ်ဝင်ရောက်ခွင့် ထိန်းချုပ်မှု၊ ရေစီးကြောင်း ကွန်ရက်ကို သီးခြားခွဲထားခြင်း သို့မဟုတ် ရေတိုအော့ဖ်လိုင်းကို ထည့်ပါ။ အန္တရာယ်များသော ဝင်ပေါက်များတွင် ချိတ်ဆက်မှု၊ တောင်းဆိုမှုကိုယ်ထည်နှင့် နှုန်းထားကန့်သတ်ချက်များကို ပေါင်းထည့်ပါ။ entry-related တွင် source authentication ဖြစ်ပေါ်ကြောင်း သေချာပါစေ။ NGINX တောင်းဆိုမှု လုပ်ငန်းစဉ် ကွင်းဆက် မတိုင်မီ။ အားနည်းချက်အများစုမှာ ၎င်းတို့ကိုယ်တိုင်တည်ရှိနေကြောင်း သတိပြုသင့်သည်။ NGINX ဒေတာလေယာဉ်အတွင်းပိုင်း၊ ရိုးရာ WAF စည်းမျဉ်းများသည် စိတ်ကြိုက်ဖွဲ့စည်းမှု အစပျိုးမှု အခြေအနေများကို တိကျစွာ မဆုံးဖြတ်နိုင်ပါ။

5.2 alias / rewrite- ပြန်လည်ရေးသားပြီးနောက် $request_filename အကဲဖြတ်ခြင်းကို ရှောင်ကြဉ်ပါ

စစ်ဆေးပြီး ချိန်ညှိရန် အကြံပြုထားသည်-

  • ဖျော်ဖြေဖို့ မကြိုးစားပါနဲ့။ rewrite ပြောင်းလဲလိမ့်မယ်။ URI တစ်ချိန်တည်းမှာပင် location သုံးပြီး alias .
  • URI ကို ပြန်လည်ရေးသားပြီးသောအခါတွင် $request_filename ကို အသုံးပြုခြင်း ရှောင်ကြဉ်ပါ သို့သော် မှန်ကန်သော အနေအထားကိုက်ညီမှု မပြီးမြောက်သေးပါ။
  • return၊ set၊ if၊ add_header၊ အသုံးပြုခွင့် မှတ်တမ်းဖော်မတ်နှင့် ဖိုင်များ ပါဝင်သည့် သွယ်ဝိုက်ပြောင်းနိုင်သော ကိုးကားမှုများကို စစ်ဆေးပါ။
  • လုပ်ငန်းခွင့်ပြုသည့်အခါ root/try_files/independent location ကိုသုံးပါ၊ သို့သော် alias ကို root ကိုသာပြောင်းပါ။ တစ်ခုပြီးတစ်ခုစစ်ဆေးရမည်ဖြစ်ပြီး၊ ၎င်းသည် ဖိုင်လမ်းကြောင်း၏ အဓိပ္ပါယ်သတ်မှတ်ချက်ကိုလည်း ပြောင်းလဲနိုင်သည်။

ရှိပြီးသား ဖွဲ့စည်းမှုပုံစံကို ထပ်ရေးရန် အင်တာနက်ပေါ်ရှိ ဘုံ “ဘေးကင်းသော ပြန်လည်ရေးစနစ်ပုံစံ” ကို တိုက်ရိုက် ကူးယူခြင်း မပြုပါနှင့်။ မတူညီသော location ၏ရှေ့ဆက်များနှင့် ပစ်မှတ်များကို ပြန်လည်ရေးသားခြင်းသည် လုံးဝကွဲပြားခြားနားသော အဓိပ္ပါယ်များဖြင့် လမ်းကြောင်းကို ပေါင်းစည်းခြင်းကို ဖြစ်ပေါ်စေပါသည်။ S5

5.3 map/Regex- ဖမ်းယူနိုင်သော ပြောင်းလဲနိုင်သော အခြေအနေ ရောစပ်မှုကို လျှော့ချပါ

$1 ကဲ့သို့သော အမည်မသိ ဖမ်းယူမှုများကို အချိန်ကြာလာသည်နှင့်အမျှ မတူညီသော regex အကဲဖြတ်မှုလမ်းကြောင်းများတွင် ပြန်လည်အသုံးပြုရန် ခွင့်ပြုမည့်အစား အမည်ပေးထားသော ဖမ်းယူမှုများကို ဦးစားပေးပြီး ၎င်းတို့၏ ပြန့်ပွားမှုနယ်ပယ်ကို ကန့်သတ်ရန် အကြံပြုထားသည်။ ဥပမာ-

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

ဤအတိုအထွာသည် ပြောင်းလဲနိုင်သော ပိုင်ဆိုင်ခွင့်၏ ပိုမိုလွယ်ကူသော စာရင်းစစ်ဖွဲ့စည်းပုံကိုသာ သရုပ်ပြသည်၊ CVE-2026-93479 မှ အစပျိုးလမ်းကြောင်းများအားလုံးကို လွတ်လပ်စွာ ဖယ်ထုတ်ရန် သက်သေပြခဲ့ပြီးဖြစ်သည်ဟု မဆိုလိုပါ။ အထူးသဖြင့်၊ အခြား root သို့မဟုတ် log_format မှ ရိုက်ကူးထားသော variable များကို အချိန်မတိုင်မီ ရည်ညွှန်းခြင်းရှိမရှိနှင့် volatile၊ dynamic paths နှင့် interdependent evaluation chains ရှိမရှိ ပြန်လည်သုံးသပ်ပါ။ F5/CERT သည် ရေတိုသက်သာမှုအဖြစ် သက်ဆိုင်ရာ ပုံမှန်ကိုက်ညီမှုဖွဲ့စည်းမှုတွင် အသုံးပြုမှုနယ်ပယ်ကို ကန့်သတ်ခြင်းဟု အမည်ပေးထားသည့် ဖမ်းယူခြင်းကို အသုံးပြုရန် အကြံပြုထားသည်။ S3S6

5.4 AIO + SSI- မလိုအပ်သော လုပ်ဆောင်ချက်ပေါင်းစပ်မှုများကို ပိတ်ပါ

SSI သို့မဟုတ် asynchronous ဖိုင် I/O မလိုအပ်သော ဆာဗာ/လမ်းကြောင်းများအတွက်၊ အသုံးပြုပါ-

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

အားနည်းချက်ဖြစ်ပေါ်နေသောအခြေအနေများ၏ရှုထောင့်မှကြည့်လျှင် နှစ်ခုအနက်မှတစ်ခုကိုပိတ်ခြင်းသည် ဖော်ပြထားသော သီးခြားကွင်းဆက်ကိုဖယ်ရှားရန် လုံလောက်ပါသည်။ တစ်ချိန်တည်းတွင် ပိတ်ခြင်းသည် လုပ်ငန်းသည် ဤစွမ်းရည်ကို အားမကိုးသော အခြေအနေများတွင်သာ သက်ဆိုင်ပါသည်။ include virtual၊ တောင်းဆိုချက်ခွဲများ၊ cache နှင့် thread pool အပြုအမူတို့ကို စစ်ဆေးပါ။ reverse proxy load များလာသောအခါ၊ AIO ကို ပိတ်ခြင်းသည် latency နှင့် I/O စွမ်းဆောင်ရည်ကို ပြောင်းလဲနိုင်သည်။ S7

5.5 HTTP/3 ခန္ဓာကိုယ်ဆေးထိုးရန် တောင်းဆိုခြင်း- လိုအပ်ပါက ဝင်ပေါက်ကို ယာယီပိတ်ပါ

ပိတ်ပါ။ quic ပါဝင်နားထောင်သူ HTTP/3 ၊ ပယ်ဖျက်ပါ။ Alt-Svc ကြေငြာထားသော တုံ့ပြန်မှု ခေါင်းစီး HTTP/3 နှင့် edge layer/load balancer သည် ပေးပို့ဆဲရှိမရှိ စစ်ဆေးပါ။ QUIC မပြုပြင်ရသေးသူများထံ တိုက်ရိုက်တောင်းဆိုပါသည်။ 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 等配置保持不变
}

အထက်ဖော်ပြပါများသည် တစ်ဦးချင်းဖွင့်နိုင်သည့် ပြီးပြည့်စုံသော ဆာဗာဖွဲ့စည်းပုံမဟုတ်ဘဲ ပြောင်းလဲမှုကွာခြားချက်၏ ဖော်ပြချက်တစ်ခုမျှသာဖြစ်သည်။ HTTP/2 ၏ ဆက်တင် syntax သည် NGINX ဗားရှင်းနှင့် ဆက်စပ်နေသည်။ အကယ်၍ သင်သည် HTTP/2 ကို ဆက်လက်ထိန်းသိမ်းထားရန် လိုအပ်ပါက၊ သင်သည် http2 on; သို့မဟုတ် သက်ဆိုင်ရာဗားရှင်းအလိုက် လက်ရှိတရားဝင်အထားအသိုကို အသုံးပြုကာ nginx -t ဖြင့် စစ်ဆေးသင့်သည်။ ကဏ္ဍတစ်ခုလုံးကို ဤကဏ္ဍဖြင့် အစားထိုးမည့်အစား ဖြန့်ကျက်ခြင်းမပြုမီ လက်ရှိရှိဆဲဆာဗာဖွဲ့စည်းမှုပုံစံနှင့် ပေါင်းစပ်ရမည်ဖြစ်သည်။ UDP 443 firewall၊ HTTP/3 ရပ်စဲတည်နေရာနှင့် CDN/front proxy ၏ client ဆုတ်ခွာလမ်းကြောင်းကိုလည်း စစ်ဆေးသည်။

ရေတိုလျော့ပါးစေမည့် အခြားအမျိုးအစားမှာ ထိခိုက်မှုရှိသော ပရောက်စီလမ်းကြောင်းတွင် proxy_request_buffering off; ကို အသုံးပြုရန်ဖြစ်သည်၊ သို့သော် ၎င်းသည် အထက်စီးကြောင်းတောင်းဆိုမှုကိုယ်ထည်ကို ထုတ်လွှင့်ခြင်း၊ ပြန်လည်စမ်းစစ်ခြင်း မအောင်မြင်ခြင်းနှင့် အချို့သော အပ်လုဒ်လုပ်ငန်းအသွားအလာများကို ပြောင်းလဲစေမည်ဖြစ်သည်။ ညွှန်ကြားချက်သည် သက်ရောက်မှုရှိသော HTTP/3 ပရောက်စီလမ်းကြောင်းကို ထိမှန်ကြောင်း လုံလောက်သောစမ်းသပ်မှုနှင့် အတည်ပြုပြီးနောက်မှသာ အသုံးပြုမည်ဖြစ်သည်။ S8S18

5.6 TLS Session Ticket- ဦးစားပေးကာကွယ်မှု mTLS အထောက်အထားစိစစ်ခြင်း နယ်နိမိတ်

အဆင့်မြှင့်တင်ခြင်း မဖြစ်နိုင်ပါက၊ ဥပမာသည် မျှဝေထားသော session cache + အလိုအလျောက် လက်မှတ်သော့လှည့်ခြင်းအပေါ် မှီခိုနေပါက၊ အကဲဖြတ်ပါ။

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

၎င်းသည် TLS Session Ticket ယန္တရားကို ပိတ်နိုင်ပြီး ဤအားနည်းချက်တွင်ဖော်ပြထားသော လက်မှတ်အတုပြုလုပ်သည့်လမ်းကြောင်းကို ဖယ်ရှားနိုင်သည်၊ သို့သော်၊ ၎င်းသည် ဆက်ရှင်ပြန်လည်စတင်ခြင်း စွမ်းဆောင်ရည်ကို ထိခိုက်စေနိုင်သည်။ မူရင်းအထောက်အထားစိစစ်ခြင်းနယ်နိမိတ်ကိုတိုက်ရိုက်ဖျက်ပစ်မည်ဖြစ်သောကြောင့် “အားနည်းချက်များကိုရှောင်ရှားရန်” mTLS ဖောက်သည်လက်မှတ်စစ်ခြင်းအား သင်ပိတ်လိုက်ရုံဖြင့်မရနိုင်ပါ။ S9S12

တိကျသေချာသော ssl_session_ticket_key ဖိုင်များနှင့် လုံခြုံသောလည်ပတ်ခြင်းတို့ကို အလိုအလျောက်ထုတ်ပေးသည့်အခြေအနေများကိုကျော်လွှားရန် ပရော်ဖက်ရှင်နယ် TLS စီမံခန့်ခွဲမှုလုပ်ငန်းစဉ်များမှလည်း အသုံးပြုနိုင်သော်လည်း သော့ထိန်းသိမ်းမှု၊ အပြည့်အဝ node ဖြန့်ဖြူးမှု၊ လည်ပတ်မှုနှင့် လက်မှတ်ဟောင်းများ၏ အသက်ကယ်စက်များကို ဂရုတစိုက်စစ်ဆေးရန် လိုအပ်ပါသည်။ သာမန်ဝဘ်ဖွဲ့စည်းမှုပုံစံ သို့မဟုတ် ယာယီအရေးပေါ်အခြေအနေများအတွက် သာမန်ဝဘ်ဖွဲ့စည်းပုံ သို့မဟုတ် scripts များတွင် ရေရှည်ပြန်သုံးနိုင်သောသော့ကို hardcode လုပ်ဖို့ မထောက်ခံပါ။ mTLS ကိုအသုံးပြုသည့် အရေးပါသောဝန်ဆောင်မှုများသည် TLS ဆက်ရှင်ပြန်လည်စတင်ခြင်းအပြုအမူနှင့် တရားဝင်အသုံးပြုသူလက်မှတ်မပါဘဲ တောင်းဆိုချက်များကို ငြင်းပယ်ခြင်းအတွက် ထပ်လောင်းစောင့်ကြည့်သင့်သည်။ S12

5.7 လည်ပတ်မှုစနစ်နှင့် နယ်စပ်ကာကွယ်ရေးအခန်းကဏ္ဍ

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

ASLR၊ root မဟုတ်သော အလုပ်သမားများ၊ ဖတ်ရန်သီးသန့် ကွန်တိန်နာ ဖိုင်စနစ်များ၊ အနည်းဆုံး ဖိုင်ခွင့်ပြုချက်များနှင့် ကွန်ရက်ကို သီးခြားခွဲထားခြင်းဖြင့် ဖြစ်နိုင်ခြေ RCE ၏ သက်ရောက်မှုကို လျှော့ချနိုင်သည်။ ASLR သည် အမှိုက်ပုံများ ပြည့်လျှံမှုများ သို့မဟုတ် UAF ကို မပြုပြင်ဘဲ အလုပ်သမားများ ပျက်ကျမည်မဟုတ်ကြောင်း အာမမခံနိုင်ပါ။ WAF၊ နှုန်းကန့်သတ်ချက်နှင့် တောင်းဆိုချက် ကိုယ်ထည်အရွယ်အစား ကန့်သတ်ချက်များသည် TLS လက်မှတ်သော့ကို ထပ်တူပြုခြင်းကို မပြင်ပါ။ S4

5.8 အဖြစ်များသော နားလည်မှုလွဲခြင်း- ဤလုပ်ဆောင်ချက်များသည် ပြုပြင်မှုကို အပြီးသတ်ရန် မလုံလောက်ပါ။

ဘုံလုပ်ငန်းများဘာကြောင့် မလုံလောက်တာလဲ။
“nginx -v က အတော်လေး အသစ်ပါ”၎င်းပိုင်ဆိုင်သည့်ဌာနခွဲ၊ ထုတ်ဝေမှုဗားရှင်း၏ ကျောထောက်နောက်ခံပြုထားသော ပက်ကေ့ခ်ျဗားရှင်း အပြည့်အစုံနှင့် အွန်လိုင်းလုပ်ငန်းစဉ်ကို စစ်ဆေးမထားပါ။
“အင်ထရာနက်တစ်ခုသာ အဆင့်မြှင့်တင်ထားသည်”Worker အဟောင်း/ ကွန်တိန်နာဟောင်း/ CDN မူရင်းဥပမာသည် တောင်းဆိုချက်များကို လက်ခံရရှိဆဲဖြစ်သည်
”ဆိုက်သည် PHP/dynamic tags များကို အသုံးမပြုပါ”ချို့ယွင်းချက်သည် NGINX ပင်မလမ်းကြောင်း သို့မဟုတ် ပရိုတိုကောခွဲခြမ်းစိတ်ဖြာမှုတွင် ဖြစ်ပေါ်ပြီး PHP လုပ်ဆောင်မှုအပေါ် အားမကိုးပါ။
“WAF/Cloudflare ကိုဖွင့်ရင် လုံလောက်ပြီ”WAF အားလုံးကို NGINX ဖွဲ့စည်းမှု-မှီခိုမှတ်ဉာဏ်ချို့ယွင်းချက်များ သို့မဟုတ် TLS ပြန်လည်စတင်ခြင်း ချို့ယွင်းချက်များကို ပိတ်ဆို့ရန် သက်သေမပြနိုင်ပါ။
“ASLR ဖွင့်ပြီးပြီ”အခက်အခဲ လျော့ပါးရေးကို အခွင့်ကောင်းယူပြီး၊ တောင်းဆိုမှုနှင့်အတူ DoS သည် ဆေးထိုးနိုင်သေးသည်။
“HTTP/3 သည် အများသူငှာ ကွန်ရက်နှင့် ထိတွေ့ခြင်း မရှိပါ၊ ထို့ကြောင့် အဆင့်မြှင့်ရန် လုံးဝ မလိုအပ်ပါ။“အခြား CVE လေးခုသည် သီးခြားအကဲဖြတ်ရန် လိုအပ်နေသေးသည်။ လျှို့ဝှက်ဇာစ်မြစ်များနှင့် တိုက်ရိုက်ချိတ်ဆက်မှုများ ရှိနိုင်သည်။
“ဇူလိုင်၏ map အားနည်းချက်ကို ပြင်ဆင်ပြီးပါပြီ”အောက်တိုဘာလ CVE-2026-93479 တွင် နောက်ဆက်တွဲ script အကဲဖြတ်မှု ဆုတ်ယုတ်မှု ပြဿနာများ ပါဝင်သည်
”Caching ကိုပိတ်ထားခြင်းသည် ပြဿနာအားလုံးကို ဖြေရှင်းပေးသည်”အချို့သော TLS ကက်ရှ် သို့မဟုတ် AIO အခြေအနေများကိုသာ သက်ရောက်မှုရှိပြီး alias၊ script၊ HTTP/3 တို့ကို အကျုံးမဝင်ပါ။

6. တရားဝင် Patch အကောင်အထည်ဖော်မှု စိတ်ကူးများနှင့် သုံးသပ်ချက် အမှတ်များ

ဤကဏ္ဍသည် အောက်တိုဘာလ 2026 အထက်ရေစီးကြောင်း NGINX ပြင်ဆင်မှုများကို လိုက်နာသည်။ အတိုအထွာများသည် ဖာထေးစစ်ဆေးခြင်းအတွက် ကိုယ်စားလှယ်အပြောင်းအလဲများကို သရုပ်ဖော်သည်။ ၎င်းတို့သည် ပြီးပြည့်စုံသော၊ အမှီအခိုကင်းစွာ စုစည်းနိုင်သော ပြင်ဆင်မှုများဖြစ်သည်။ စိတ်ကြိုက်တည်ဆောက်မှုများအတွက်၊ ကုဒ်အပြည့်အစုံ၊ ပတ်ဝန်းကျင်ကုဒ်များနှင့် စမ်းသပ်မှုများကို ပြန်လည်သုံးသပ်ပြီး ပြီးပြည့်စုံသော ပံ့ပိုးပေးထားသည့် ထုတ်ဝေမှုကို နှစ်သက်သည်။ S5S6S7S8S9

6.1 CVE-2026-15176- URI ကို alias လမ်းကြောင်းမြေပုံဆွဲခြင်း ငြင်းပယ်ခြင်းဆိုင်ရာ အခြေအနေများ ပါဝင်ရန် ပြန်လည်ရေးသားထားသည်

src/http/ngx_http_core_module.c တွင် မွမ်းမံထားသော ngx_http_map_uri_to_path()-

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

ပြန်လည်သုံးသပ်ခြင်း- URI ပြောင်းလဲသွားသောအခါတွင် ဖိုင်စနစ်လမ်းကြောင်းကို ဆက်လက်တွက်ချက်၍မရသော်လည်း alias ၏ သက်ဆိုင်ရာတည်နေရာဆိုင်ရာ အယူအဆများသည် ယုံကြည်စိတ်ချရခြင်းမရှိတော့ပါ။ ဤသည်မှာ ကြိုတင်နိုင်ငံတော်၏ ကန့်သတ်ချက်ကို မြှင့်တင်ခြင်းပင်ဖြစ်သည်။ တောင်းဆိုချက် URI တွင် တရားမဝင်သော စာလုံးများ ပါဝင်ခြင်း ရှိ၊ မရှိ စစ်ဆေးခြင်းသည် ရိုးရှင်းသော စစ်ဆေးမှုမဟုတ်ပါ။ S5

6.2 CVE-2026-93479- အထွက်ဒေတာအရှည်နှင့် သီးသန့်အရှည်ကြား မှန်ကန်စွာ ပိုင်းခြားပါ။

ရေစီးကြောင်းတွင် src/http/ngx_http_script.c နှင့် src/stream/ngx_stream_script.c တို့ကို တစ်ချိန်တည်းတွင် အပ်ဒိတ်လုပ်ထားသည်။ အဓိကရည်ရွယ်ချက်ကို အောက်ပါအတိုင်း အကျဉ်းချုံးနိုင်သည်။

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

ဤတွင်၊ pool သည် ပုံဥပမာပါရာမီတာအမည်ဖြစ်သည်- အမှန်တကယ် HTTP နှင့် Stream ခွဲဝေမှုအသုံးအနှုန်းများသည် ကွဲပြားသည်။ ပြောင်းလဲမှုသည် script output length ကို ဦးစွာတွက်ချက်ပြီး နောက်ဆုံးခွဲဝေချထားမှုသို့ သီးသန့်အရှည်ကို ပေါင်းထည့်သောကြောင့် output သည် reserved space ကို ထပ်မရေးပါ။ S6

စာရင်းစစ်ခြင်းနှင့် နောက်ကြောင်းပြန်ပို့သည့်အခါ၊ HTTP/Stream ၏ သက်ဆိုင်ရာ အကဲဖြတ်သူကိုလည်း အကျုံးဝင်ရပါမည်။ map ၏ဖွဲ့စည်းပုံစနစ်ဆိုင်ရာ အထားအသိုဖိုင်ကိုစစ်ဆေးခြင်းကသာ ချို့ယွင်းချက်ကို ပြုပြင်ပြီးဖြစ်ကြောင်း သက်သေမပြနိုင်ပါ။

6.3 CVE-2026-97205- 8-bit asynchronous operation count အတွက် ဘေးကင်းရေး သတ်မှတ်ချက်ကို သတ်မှတ်ပါ

အထက်ပိုင်း src/http/ngx_http_request.h တွင် ထည့်သွင်းထားသည်-

#define NGX_HTTP_MAX_BLOCKED 250

တူညီသောထည့်သွင်းမှုများကို ချိန်ကိုက်သည့်ဖိုင်ဖတ်ရှုခြင်း၊ ကက်ရှ်စောင့်နေခြင်း၊ အထွက်စစ်ထုတ်ခြင်းနှင့် thread လည်ပတ်ခြင်းတွင် အလားတူထည့်သွင်းမှုများကို ပေါင်းထည့်ပါ-

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

သုံးသပ်ချက်- r->main->blocked ပေါင်းထည့်မည့် တကယ့်ကုဒ်လမ်းကြောင်းများအားလုံးကို ဖုံးအုပ်ထားရပါမည်။ header file တွင် threshold constant ကို ရေးရုံဖြင့် မရပါ။ Backport သည် လုပ်ဆောင်စရာများကို တိုက်ရိုက်ပယ်ချခြင်းကြောင့် ရပ်တန့်ခြင်း သို့မဟုတ် ရည်ညွှန်းချက် ယိုစိမ့်ခြင်းတို့ကို ဖြစ်ပေါ်စေမည် မဟုတ်ကြောင်း သေချာစေရန် တစ်ပြိုင်နက်တည်း ပြန်ခေါ်ခြင်း၊ အညီအမျှ ပြန်ခေါ်ခြင်းနှင့် အမှားအယွင်း ပြန်ခြင်း၏ ပြီးပြည့်စုံသော ညှိနှိုင်းမှုကို စစ်ဆေးရန် လိုအပ်ပါသည်။ S7

6.4 CVE-2026-95101- အမည်မသိဘောင်များအတွက် သီးခြား skip အခြေအနေကို ထိန်းသိမ်းပါ

အထက်ပိုင်းသည် skip အကွက်ကို HTTP/3 ခွဲခြမ်းစိတ်ဖြာမှုအခြေအနေတည်ဆောက်ပုံတွင် ထည့်သွင်းပြီး အခြေအနေခွဲခြားမှုကို လုပ်ဆောင်သည်-

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

သော့ချက်မှာ “အမည်မသိ HTTP/3 ဘောင်များကို ပိတ်ရန်” မဟုတ်ဘဲ အကြိမ်ရေအများအပြားဖတ်ခြင်းကို သေချာစေရန်အတွက်၊ ကျော်သွားသော byte အရေအတွက်နှင့် DATA payload length ကို သီးခြားပြည်နယ်များမှ အမြဲတမ်းစီမံခန့်ခွဲပါသည်။ သုံးသပ်ချက်များသည် အမည်မသိဘောင်ဖြတ်ကျော်မှုကြားခံခွဲထုတ်ခြင်းနှင့် client_max_body_size ၏ နောက်ဆုံးထွက်ရှိမှုအပေါ် အာရုံစိုက်သင့်သည်။ S8

6.5 CVE-2026-97629- ပြီးပြည့်စုံသော TLS သော့အထိုင်အခင်းကို စင့်ခ်လုပ်ပါ

အထက်ပိုင်းပြောင်းလဲမှုများသည် 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));

မူရင်းပုံတွင် သော့အပေါက်သုံးပေါက်ပါရှိသော်လည်း ပထမနှစ်ခုကိုသာ ကူးယူထားသည်။ ယင်းအစား၊ Worker ၏ မဲပေးခြင်းသော့အတွဲသည် မျှဝေထားသော မမ်မိုရီနှင့် ကိုက်ညီကြောင်း သေချာစေရန်အတွက် အမှန်တကယ် array အစိတ်အပိုင်းများ၏ အရေအတွက်ပေါ်မူတည်၍ တစ်ပြိုင်တည်းလုပ်ဆောင်ပါ။ ပြန်လည်သုံးသပ်သည့်အခါ memcpy အရှည်ပြုပြင်မွမ်းမံမှုကို တစ်ကြိမ်စစ်ဆေးခြင်းထက် array ခွဲဝေမှု၊ အစပျိုးမှု၊ မျှဝေထားသောသော့နှင့် လည်ပတ်မှုယုတ္တိတို့သည် တစ်သမတ်တည်းဖြစ်ကြောင်းကိုလည်း အတည်ပြုပါ။ S9

6.6 ပြန့်ကျဲနေသော patch အပိုင်းအစများကိုသာ အသုံးပြုရန် အဘယ်ကြောင့် မထောက်ခံသနည်း။

ဤမွမ်းမံမှုငါးခုသည် src/http၊ src/stream၊ src/http/v3 နှင့် src/event အသီးသီးပါဝင်ပြီး ဗားရှင်းအဟောင်းများတွင် လုံခြုံရေးအထောက်အပံများနှင့် တရားဝင်မဟုတ်သော နောက်ဆက်တွဲများ ပါဝင်နိုင်သည်။ Backporting သည် အောက်ပါ check matrix ကို ဖွဲ့စည်းသင့်သည်-

အရာဝတ္ထုကို စစ်ဆေးပါ။ဘာအတည်ပြုရမည်နည်း။
patch အရင်းအမြစ်တရားဝင်တင်သွင်းမှု၊ ကိုက်ညီသောပစ်မှတ်ဗားရှင်း၊ ပြီးပြည့်စုံသော patch နှင့် လက်မှတ်အတည်ပြုခြင်း။
Original patch အစုံပါ။CVE-2026-42533၊ ဖြန့်ဖြူးရေး နောက်ခံပို့စ၊ စသည်တို့ကဲ့သို့သော သမိုင်းဆိုင်ရာ ပြုပြင်မွမ်းမံမှုများနှင့် မဆန့်ကျင်ပါ။
ကုဒ်လမ်းကြောင်းHTTP + Stream script၊ AIO/thread၊ HTTP/3၊ OpenSSL လက်မှတ်အားလုံးကို အကျုံးဝင်သည်
သဟဇာတဖြစ်အောင် ပြုစုတယ်။OpenSSL၊ PCRE၊ module ABI၊ dynamic module နှင့် link dependencies များသည် တသမတ်တည်းဖြစ်သည်
အလုပ်လုပ်တဲ့ဆုတ်ယုတ်မှုalias ပြန်လည်ရေးသားခြင်း၊ ပြောင်းလဲနေသောမှတ်တမ်း၊ SSI/AIO၊ HTTP/3 အပ်လုဒ်လုပ်ခြင်း၊ mTLS စက်ရှင် ပြန်လည်စတင်ခြင်း
runtimeWorker/Pods များအားလုံးသည် အတည်ပြုထားသော တည်ဆောက်မှုအသစ်များကို လုပ်ဆောင်ပြီး အမွေအနှစ်ပုံများ မကျန်တော့ပါ။

၎င်းတို့၏ကိုယ်ပိုင်ထုတ်ဝေမှုများကိုထိန်းသိမ်းထားသည့်အသင်းများအတွက်၊ CVE တစ်ခုစီအတွက် စစ်ဆေးနိုင်သော patch IDs၊ package versions၊ build logs နှင့် regression အစီရင်ခံစာများကို ဆက်လက်ထားရှိရန် အကြံပြုထားပါသည်။ သာမန်လည်ပတ်မှုနှင့် ပြုပြင်ထိန်းသိမ်းမှုများအတွက်၊ အလုံခြုံဆုံးဖြေရှင်းချက်မှာ ရောင်းချသူ၏ ပြီးပြည့်စုံသော လုံခြုံရေးအပ်ဒိတ်များကို ထည့်သွင်းရန်ဖြစ်သည်။

7. သမိုင်းဆိုင်ရာ အားနည်းချက်ကို နောက်ကြောင်းပြန်လိုက်ခြင်း၊ အကိုင်းအခက်ဟောင်းများနှင့် အခြားထုတ်ကုန်များ

7.1 NGINX core vulnerability သည် 2026 မေလမှ စက်တင်ဘာလအထိ တပြိုင်နက်တည်း အတည်ပြုချက်ရထိုက်သည်

အချိန်အကြာကြီး မွမ်းမံမွမ်းမံထားသည့် NGINX အများအပြားသည် အောက်တိုဘာလတွင် ထုတ်ဝေမှုအသစ်ကြောင့်သာ သက်ရောက်မှုရှိသည်။ မဝေးတော့သောအနာဂတ်တွင် အောက်ပါတို့သည် ကိုယ်စားလှယ် ပြုပြင်ခြင်း ဆုံမှတ်များဖြစ်သည်- S1S2

CVEပထမဦးစွာ ပြင်ဆင်ချက်ထုတ်ပြန်ခြင်း။စာရင်းစစ်ရန်လိုအပ်သော အဓိကအန္တရာယ်များနှင့် အခြေအနေများ
CVE-2026-42945Stable 1.30.1 / Mainline 1.31.0 မေ ၁၃၊rewrite အမည်မသိ regex ဖမ်းယူခြင်းနှင့် အစားထိုးခြင်း ယုတ္တိဗေဒသည် အမှိုက်ပုံ ပြည့်လျှံမှုကို အစပျိုးစေသည်၊ အလားအလာ RCE၊ တောရိုင်းအတွင်း တိုက်ခိုက်ရန် ကြိုးပမ်းမှုများနှင့် ပတ်သက်၍ လူသိရှင်ကြား အစီရင်ခံစာများ ရှိသည်။
CVE-2026-9256Stable 1.30.2 / Mainline 1.31.1 မေ ၂၂၊rewrite တွင် ထပ်နေသော regex ဖမ်းယူမှုနှင့် အရှည်ခန့်မှန်းချက်သည် လျှံတက်လာသည်
CVE-2026-42055Stable 1.30.3 / Mainline 1.31.2 ဇွန် ၁၇၊HTTP/2 ရေစီးကြောင်း သို့မဟုတ် gRPC အတွက် သီးသန့်ဖွဲ့စည်းမှုပုံစံ၊ ကြီးမားသော တောင်းဆိုချက်ခေါင်းစီးအခြေအနေသည် ကြားခံပြည့်လျှံမှုကို အစပျိုးပေးသည်
CVE-2026-42530Mainline 1.31.2၊ ဇွန်လ ၁၇HTTP/3 အသုံးပြုမှု-ပြီးနောက်-အခမဲ့; တရားဝင်အမှတ်အသားထိခိုက်သည့်အကွာအဝေး 1.31.0–1.31.1
CVE-2026-42533Stable 1.30.4 / Mainline 1.31.3 ဇူလိုင် ၁၅၊map + regex ဖမ်းယူမှု မပြောင်းလဲနိုင်သော အကဲဖြတ်ခြင်းသည် အစုအပုံ ပြည့်လျှံမှုကို ဖြစ်စေပြီး နောက်ဆက်တွဲ ဖာထေးမှုများသည် အောက်တိုဘာလတွင် CVE-2026-93479 နှင့် ဆုတ်ယုတ်မှု ဆက်စပ်မှုရှိသည်
CVE-2026-60005Stable 1.30.4 / Mainline 1.31.3 ဇူလိုင် ၁၅၊ngx_http_slice_module သတ်မှတ်ထားသော ကိန်းရှင်နှင့် ကက်ရှ်အပ်ဒိတ်အခြေအနေများအောက်တွင် ပေါက်ကြားနေသည့် မမ်မိုရီအကြောင်းအရာ
CVE-2026-56434Stable 1.30.4 / Mainline 1.31.3 ဇူလိုင် ၁၅၊SSI သည် UAF နှင့် သက်ဆိုင်ပါသည်။ အောက်တိုဘာလ၏ AIO ရေတွက်မှုအားနည်းချက်ကြောင့် root အကြောင်းရင်းတစ်ခုတည်းမဟုတ်ပါ
CVE-2026-90439Stable 1.30.5 / Mainline 1.31.6 စက်တင်ဘာ ၁၅၊HTTP/3 + သီးခြား OpenSSL ဗားရှင်းပေါင်းစပ်မှု ကန့်သတ်ချက်ပြည့်လျှံခြင်း၊ အဓိကအားဖြင့် ပျက်စီးမှု/ကန့်သတ်မှတ်ဉာဏ် ပျက်စီးမှုအဖြစ် ထင်ရှားသည်

NGINX Core၊ HTTP/2၊ Charset နှင့် SMTP 2026 တွင် ထုတ်ပြန်ခဲ့သည့် တရားဝင် လုံခြုံရေး စာစောင်များ အရ စုံစမ်း စစ်ဆေးသင့်သည် ။ ဤဇယားသည် လက်ရှိ NGINX အများသူငှာ မျက်နှာစာ ပြောင်းပြန် ပရောက်စီ ဖြန့်ကျက်မှုများနှင့် မမ်မိုရီဘေးကင်းရေး သို့မဟုတ် ခိုင်မာမှုဆိုင်ရာ သက်ရောက်မှုများ တောင်းဆိုမှုတို့နှင့် အကိုက်ညီဆုံး ပုံမှန်ဖြစ်ရပ်များကို ရည်ရွယ်ချက်ရှိရှိ အာရုံစိုက်ထားသည်။ 2026 တွင် CVE များအားလုံးမဟုတ်ပါ။ စာရင်း။ S1

အဘယ်ကြောင့် CVE-2026-42945 ကို အထူးသတိထားပါ။

မေလတွင် ဤ rewrite အားနည်းချက်အတွက် လူသုံးအမြတ်ထုတ်သည့် လှုပ်ရှားမှုများနှင့် အများသူငှာ အမြတ်ထုတ်သည့် ကုဒ်အချက်အလက်များကို မှတ်တမ်းတင်သည့် အစိုးရအေဂျင်စီများမှ လုံခြုံရေးစာစောင်များ ရှိပါသည်။ ထို့ကြောင့်၊ မေလမှယနေ့အထိ အချိန်အကြာကြီး ဖာထေးခြင်းမပြုရသေးသော ရှုပ်ထွေးသော ပုံမှန်အသုံးအနှုန်းများကို အများသူငှာကွန်ရက်တွင် ပြန်လည်ရေးသားခြင်းရှိ၊ ပြုပြင်မှုပြီးမြောက်ခြင်းအပြင် ပုံမှန်မဟုတ်သော Worker ပျက်ကျမှု၊ ဝင်ရောက်သုံးစွဲမှုမှတ်တမ်းများနှင့် ထိုအချိန်က သံသယဖြစ်ဖွယ်ပြောင်းလဲမှုများကို ထပ်လောင်းသုံးသပ်သင့်သည်။ S23

“တိုက်ခိုက်မှုတစ်ခု ဖြစ်ပွားခဲ့သည်” သည် တိုက်ခိုက်သူသည် ပစ်မှတ်တိုင်းတွင် စိတ်ချယုံကြည်ရသော အမိန့်များကို လုပ်ဆောင်ခဲ့ကြောင်း အလိုအလျောက် သက်သေမပြနိုင်ပါ။ အဖြစ်အပျက်တုံ့ပြန်မှုတွင် ပါဝင်သည့်အခါ၊ အပေးအယူ အညွှန်းကိန်းများနှင့် လုပ်ငန်းစဉ်ပျက်ကျမှုများကို အခွင့်ထူးတိုးမြင့်လာမှု သို့မဟုတ် တည်မြဲခြင်း၏ စစ်မှန်သောအထောက်အထားများမှ သီးခြားစီ စစ်ဆေးသင့်သည်။

7.2 ဗားရှင်းအဟောင်းများနှင့် ဖြန့်ချီရေး backport များအတွက် ပြန်လည်ပြင်ဆင်ခြင်း။

NGINX မတူညီသောအကိုင်းအခက်များတွင် ၎င်းတို့၏ကိုယ်ပိုင်ပံ့ပိုးကူညီမှုစက်ဝန်းများနှင့် မတူညီသောအားနည်းချက်မိတ်ဆက်အချိန်များရှိသည်။ အသစ်ပြင်ဆင်ဖာထေးမှု (၅) ခုကို ပြန်လည်သုံးသပ်ခြင်းမရှိဘဲ အစောပိုင်းအရင်းအမြစ်သစ်ပင်များအားလုံးသို့ ဖြန့်ကျက်၍မရပါ။

မြင်ကွင်းအကြံပြုထားသောဗျူဟာ
ဖြန့်ချိသည့်ဗားရှင်းသည် ပြီးပြည့်စုံသော လုံခြုံရေးပြင်ဆင်မှုများကို ကြေညာထားသည်။ရောင်းချသူ ပက်ကေ့ဂျ်များကို သုံး၍ ပြီးပြည့်စုံသော အထုပ်ဗားရှင်းများကို မှတ်တမ်းတင်ပါ။ သဟဇာတမဖြစ်သော upstream bare binaries ဖြင့် အစားထိုးခြင်းကို ရှောင်ကြဉ်ပါ။
Debian 12 နှင့် ဤအသုတ်ရှိ CVE များအားလုံးမှ အကျုံးမဝင်သေးသော အခြား သက်ရောက်မှုရှိသော ထုတ်ဝေမှုများအန္တရာယ်ရှိသော အလုပ်အမိန့်စာများကို တင်သွင်းပါ၊ ပြင်ပထိတွေ့မှုကို ကန့်သတ်ပြီး ပေးသွင်းသူ/ELTS အခြေအနေကို စစ်ဆေးပါ။ လိုအပ်သည့်အခါတွင် ရွှေ့ပြောင်းခြင်း သို့မဟုတ် အတည်ပြုနိုင်သော ပြုပြင်ထိန်းသိမ်းမှုဆိုင်ရာ ကွင်းဆက်တစ်ခုကို အသုံးပြုပါ။
ရေဆန် ထောက်ပံ့မှု ပြီးဆုံးသွားသော သမိုင်းအကိုင်းအခက်ပံ့ပိုးထားသောဗားရှင်းများသို့ ရွှေ့ပြောင်းခြင်းကို ဦးစားပေးပါ။ ရေတို backporting လိုအပ်ပါက ထိန်းသိမ်းသူများသည် မှီခိုမှုနှင့် patch လိုက်ဖက်မှုကို အကဲဖြတ်ပြီး ပြီးပြည့်စုံသော စမ်းသပ်မှုများကို ရေးပေးပါမည်။
NGINX လမ်းဆုံလမ်းခွ (OpenResty၊ Tengine၊ စိတ်ကြိုက်တံခါးပေါက်)ဦးစွာ သက်ဆိုင်ရာ ကုဒ်လမ်းကြောင်းတွင် ပါဝင်ခြင်း ရှိ၊ မရှိ ဆုံးဖြတ်ပါ၊ ထို့နောက် လမ်းခွဲထိန်းသိမ်းသူ၏ လုံခြုံရေး ထုတ်ပြန်ချက်ကို အသုံးပြုပါ။ ၎င်းသည် အထက်ရေစီးကြောင်းဗားရှင်းနှင့် တိုက်ရိုက်မညီမျှနိုင်ပါ။
လုံခြုံရေးဖာထေးမှုများသည် လုပ်ငန်းလုပ်ဆောင်နိုင်စွမ်းကို အပြောင်းအလဲဖြစ်စေသည်။အဆင့်လိုက် ဖြန့်ချိမှုများ၊ ဗားရှင်းများအကြား အသွားအလာပြောင်းခြင်း၊ နှင့် ဖွဲ့စည်းမှုအလိုက် လိုက်လျောညီထွေဖြစ်အောင် လုပ်ဆောင်ပါ။ အထီးကျန်ခြင်းမရှိဘဲ အများသူငှာကွန်ရက်၏ ပုံသေဗားရှင်းကို ပြန်ယူရန် မသင့်လျော်ပါ။

7.3 njs၊ Ingress နှင့် NGINX Core အတွက် သီးခြားပြန်လည်ပြင်ဆင်ခြင်း

  • njs- NGINX ပင်မပရိုဂရမ်အပြင်၊ သင်သည် NGINX JavaScript module ၏ဗားရှင်းကိုလည်း စစ်ဆေးရန် လိုအပ်ပါသည်။ njs 1.0.2 သည် အောက်တိုဘာလ 2026 XML ပိုင်းခြားစိတ်ဖြာခြင်း မှတ်ဉာဏ်ကုန်ခန်းမှုနှင့် XML အတည်ပြုခြင်း မကိုက်ညီမှုပြဿနာကို entity ရည်ညွှန်းချက်ရည်ညွှန်းချက်များဖြင့် ဖြေရှင်းသည်။ nginx-saml ကို အသုံးပြု၍ XML လက်မှတ်အတည်ပြုခြင်းနှင့် ဆက်စပ်အသုံးပြုခြင်းအတွက်၊ ပလပ်အင်အခြေအနေများအတွက် တရားဝင် njs ညွှန်ကြားချက်များကို ထပ်မံဖတ်ရှုသင့်သည်။ S20
  • F5 NGINX Plus / NGINX Ingress Controller- ထို့အပြင်၊ ထိန်းချုပ်ကိရိယာနှင့် Gateway Fabric တစ်ခုစီတွင် နောက်ထပ်လုံခြုံရေးစာစောင်များ၊ မတူညီသော ထုပ်ပိုးမှုဗားရှင်းများနှင့် ထူးခြားသောမူဝါဒဆိုင်ရာ အားနည်းချက်များ ရှိနိုင်ပါသည်။ အလွှာတစ်ခုကို အဆင့်မြှင့်တင်ခြင်းသည် အခြားအလွှာကို အလိုအလျောက် အဆင့်မြှင့်တင်ခြင်းကို မဆိုလိုပါ။ S19
  • Kubernetes ကွန်မြူနတီ ingress-nginx- Kubernetes တာဝန်ရှိသူများသည် 2026 ခုနှစ် မတ်လတွင် ထိန်းချုပ်ကိရိယာအား ပြုပြင်ထိန်းသိမ်းမှုရပ်ဆိုင်းကြောင်း ကြေညာခဲ့ပြီး၊ ၎င်း၏သိုလှောင်ရုံသည် F5 ထိန်းချုပ်ကိရိယာနှင့် ရောထွေး၍မရနိုင်ပါ။ သက်ရောက်မှုရှိသော စီးပွားရေးလုပ်ငန်းများသည် လုံခြုံရေးဗားရှင်းအသစ်ကို စောင့်မည့်အစား လုံခြုံရေးဗားရှင်းအသစ်ကို စောင့်ဆိုင်းနေမည့်အစား Ingress မှတ်ချက်များနှင့် Gateway API ဝေါဟာရကွဲလွဲချက်များကို စစ်ဆေးအတည်ပြုသင့်သည်။ S21

8. လက်ခံမှုစံနှုန်းများနှင့် နောက်ဆက်တွဲစစ်ဆေးမှုများ

အလုပ်အမိန့်အပြောင်းအလဲအတွက် အောက်ပါစာရင်းကို လက်ခံမှုအခြေအနေများအဖြစ် အသုံးပြုရန် အကြံပြုအပ်ပါသည်။

ပရောဂျက်အရည်အချင်း အဆင့်အတန်းအထောက်အထားတွေ သိမ်းထားနိုင်တယ်။
ပိုင်ဆိုင်မှုနှင့် ပေါ်တယ်လွှမ်းခြုံမှုCDN ကို ကျော်ဖြတ်နိုင်သော ပြင်ပနှင့် တိုက်ရိုက်ချိတ်ဆက်ထားသော ဖြစ်ရပ်များအားလုံးကို စာရင်းပြုစုပြီးပါပြီ။ဒိုမိန်းအမည်၊ LB၊ IP၊ Pod/container စာရင်း
Package အရင်းအမြစ်နှင့် ပြုပြင်မှုနယ်ပယ်သက်ဆိုင်ရာ CVE များအားလုံးကို အကျုံးဝင်ရန် အတည်ပြုထားသော ဗားရှင်းများကို အသုံးပြုပါ။ရေစီးကြောင်းလုံခြုံရေး အကြံပေးချက်၊ USN/DSA၊ ပက်ကေ့ဂျ်ဗားရှင်း၊ ရုပ်ပုံအညွှန်း
လုပ်ငန်းစဉ်ဟောင်း ထွက်လာတယ်။master/worker/ကွန်တိန်နာများအားလုံးကို အစားထိုးပြီးပါပြီPID/စတင်ချိန်၊ လှိမ့်ချထားမှုအခြေအနေ၊ လုပ်ဆောင်နေသည့်ပုံ
ဖွဲ့စည်းမှုစာရင်းစစ်အန္တရာယ်များသော ပေါင်းစပ်မှုများကို ဖယ်ရှားခြင်း သို့မဟုတ် ဖာထေးမှုများဖြင့် ဖုံးအုပ်ထားပြီး အမွေဆက်နွယ်မှုများကို စစ်ဆေးအတည်ပြုပြီးဖြစ်သည်။nginx -T ၏ အနှစ်ချုပ်နှင့် စာရင်းစစ်မှတ်တမ်းကို ပြန်လည်ပြင်ဆင်ထားသည်။
TLS/mTLSယုံကြည်ရသော လက်မှတ်များ ဖြတ်သွားသည်; မမှန်ကန်သော သို့မဟုတ် ပျောက်ဆုံးနေသော လက်မှတ်များကို ပယ်ချပါသည်။ စက်ရှင်ပြန်လည်စတင်ခြင်းသည် စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းကို ရှောင်လွှဲ၍မရပါ။အနုတ်လက္ခဏာ/အပြုသဘောဆောင်သော ခွင့်ပြုချက်စမ်းသပ်မှု၊ ထိန်းချုပ်ထားသော TLS စမ်းသပ်မှုရလဒ်များ
HTTP/3 တောင်းဆိုချက်ကိုယ်ထည်ပြင်ဆင်ထားသော လမ်းကြောင်းကို ဖွင့်ပါ။ အထက်ပိုင်းတောင်းဆိုမှု ခန္ဓာကိုယ်နှင့် throttling မှန်ကန်စွာ ပြုမူပါ။HTTP/3၊ ပရောက်စီ အပ်လုဒ်လုပ်မှု၊ ပမာဏကန့်သတ် ဆုတ်ယုတ်မှု စမ်းသပ်မှု
SSI/AIOလုပ်ဆောင်ချက်သည် လိုအပ်ချက်များနှင့် ကိုက်ညီသည်၊ Worker တွင် မူမမှန်သောဖျက်ချခြင်း မရှိပါ။စီးပွားရေးဆုတ်ယုတ်မှု၊ ပျက်စီးမှုနှင့် အမှားအယွင်းနှုန်းကို စောင့်ကြည့်ခြင်း။
လည်ပတ်မှုနှင့် ပြုပြင်ထိန်းသိမ်းမှု စောင့်ကြည့်ခြင်း။သိသာထင်ရှားသောခြွင်းချက်မရှိ 5xx၊ SIGSEGV၊ လုပ်ငန်းစဉ်သည် ထပ်ခါတလဲလဲ ထွက်သည်။ဝန်ဆောင်မှု အညွှန်းများနှင့် မှတ်တမ်းများ
ပြန်လှည့်ဗျူဟာလိုအပ်ပါက၊ ထိတွေ့မှုကို ဦးစွာကန့်သတ်ပြီး လုံခြုံရေးစည်းများကို ထိန်းသိမ်းပါ။မှာယူမှုများ၊ အရေးပေါ် စီးဆင်းမှုများနှင့် quarantine အစီအစဉ်များကို ပြောင်းလဲပါ။
နောက်ဆက်တွဲဘဝသံသရာလုံခြုံရေးစာစောင်စာရင်းသွင်းမှုများ၊ ကွန်တိန်နာအပ်ဒိတ်အကြိမ်ရေနှင့် ဌာနခွဲပြောင်းရွှေ့မှုအစီအစဉ်များကို သတ်မှတ်ပါ။လယ်ဂျာ၊ တာဝန်ရှိပုဂ္ဂိုလ်နှင့် လာမည့်စာရင်းစစ်ရက်စွဲကို အဆင့်မြှင့်ပါ။

8.1 မှတ်တမ်းများနှင့် လည်ပတ်နေသည့်အခြေအနေတွင် သင်ဘာကိုအာရုံစိုက်သင့်သနည်း။

worker process exited on signal 、 SIGSEGV ၊ အချိန်အတော်ကြာ ထိတွေ့ခဲ့သော ဆာဗာများတွင် မူမမှန်မှုများကို ပြဿနာဖြေရှင်းခြင်း ၊ မအောင်မြင်သော spikes များ တောင်းဆိုခြင်း၊ ပုံမှန်မဟုတ်သော ရင်းမြစ်ဝင်ရောက်မှုပေါင်းစည်းခြင်း ၊ မမျှော်လင့်ထားသော TLS Session ပြန်လည်စတင်ခြင်း/စစ်မှန်ကြောင်းအထောက်အထား အောင်မြင်ခြင်းနှင့် ကိုယ်ခန္ဓာတောင်းဆိုမှု ပုံမှန်မဟုတ်ခြင်းကို နောက်ပြန်ဆုတ်ခြင်း ဤအညွှန်းကိန်းများသည် စုံစမ်းစစ်ဆေးမှု သဲလွန်စများအဖြစ်သာ အသုံးပြုနိုင်ပြီး အချို့သော CVE ကို အမြတ်ထုတ်ထားကြောင်း တိုက်ရိုက်သက်သေပြရန် လုံလောက်သော အထောက်အထားများ မဟုတ်ပေ။ ;သက်ဆိုင်ရာ မှတ်တမ်းများ မရှိခြင်းသည် တိုက်ခိုက်ခြင်း မရှိသေးကြောင်း သက်သေမပြပေ။

8.2 အကြံပြုထားသော နောက်ဆုံးအန္တရာယ်နိဂုံးစကားရပ်

ထုတ်လုပ်မှုပတ်ဝန်းကျင်အတွက် လက်ခံမှုအစီရင်ခံစာသည် အောက်ပါတိကျသောစကားရပ်ကို အသုံးပြုသင့်သည်-

NGINX ပြင်ပ ဝန်ဆောင်မှု ဝင်ပေါက်နှင့် ဆော့ဖ်ဝဲ ပက်ကေ့ဂျ် အရင်းအမြစ်ကို ဖော်ထုတ်ထားသည်။ သက်ဆိုင်ရာ ဖြစ်ရပ်များအားလုံးကို အထက်စီးကြောင်းတရားဝင် လုံခြုံရေးဗားရှင်းသို့ အဆင့်မြှင့်ထားပြီး၊ သို့မဟုတ် ဖြန့်ချိရောင်းချသူမှ အတည်ပြုထားသော နောက်ကျောပို့ကို အပြီးသတ်ပြီးပါပြီ။ Worker အဟောင်းနှင့် ကွန်တိန်နာဟောင်းများကို အစားထိုးထားသည်။ alias/rewrite/map၊ AIO/SSI၊ HTTP/3 တောင်းဆိုချက်ကိုယ်ထည် နှင့် TLS Session Ticket/mTLS ဆက်စပ်ဖွဲ့စည်းပုံများကို စစ်ဆေးပြီး ပြန်လည်စစ်ဆေးပြီး ပြန်လည်လုပ်ဆောင်မှုတွင် တောင်းဆိုချက်တစ်ခု အောင်မြင်သွားပါသည်။ အဆင့်မြှင့်တင်မှု မပြီးပြတ်သေးသော ကိစ္စရပ်များအတွက်၊ ထိတွေ့မှုဧရိယာများ၊ လျော်ကြေးပေးဆောင်မှုများ၊ တာဝန်ရှိပုဂ္ဂိုလ်များနှင့် ပြီးစီးမည့် နောက်ဆုံးရက်များကို စာရင်းသွင်းပါ။

Debian 12 သို့မဟုတ် အခြားထုတ်ဝေမှုများအတွက် ဖာထေးမှု မပြည့်စုံသေးပါက လက်ခံမှုပုံစံတစ်ခုလုံးကို “ပြီးမြောက်သည်” အဖြစ် အကဲဖြတ်ရန် မသင့်လျော်ပါ။ မဖြေရှင်းရသေးသော CVE သည် သက်ဆိုင်ရာ trigger configuration တစ်ခုရှိမရှိ၊ သီးခြားအခြေအနေနှင့် နောက်ဆုံးအဆင့်မြှင့်တင်မှုလမ်းကြောင်းကို ရှင်းလင်းစွာ မှတ်တမ်းတင်ထားသင့်သည်။

နောက်ဆက်တွဲ- သတင်းရင်းမြစ်များနှင့် လင့်ခ်များကို ကိုးကားထားသည်။

ဖော်ပြချက်- စာသားရှိ [Sx] နံပါတ်များသည် ဤကဏ္ဍနှင့် တစ်ပြေးညီဖြစ်သည်။ အောက်ဖော်ပြပါအရာများသည် အထက်တန်းပြပရောဂျက်လုံခြုံရေးကြေငြာချက်များ၊ ကုဒ်ကုဒ်များ၊ ပေးသွင်းသူထုတ်ပြန်ကြေငြာချက်များနှင့် အမျိုးသားလုံခြုံရေးအေဂျင်စီအချက်အလက်များကို ဦးစားပေးပါသည်။ ကိုးကားထားသော အားနည်းချက်များ၏ ပြင်းထန်မှုကို ထုတ်ပေးသည့်အဖွဲ့အစည်းတစ်ခုစီ၏ အဆင့်သတ်မှတ်ချက်သတ်မှတ်ချက်များနှင့်အညီ ဖော်ပြထားပါသည်။ ဒေတာအတည်ပြုရက်စွဲသည် ၂၀၂၆ ခုနှစ်၊ အောက်တိုဘာလ ၂၇ ရက်ဖြစ်သည်။

S1 — NGINX Open Source တရားဝင် လုံခြုံရေး ထုတ်ပြန်ချက်

ရေစီးကြောင်းဘေးဒဏ်ခံဗားရှင်းများ၊ အကိုင်းအခက်များကို ပြုပြင်ခြင်းနှင့် အောက်တိုဘာလ CVE ငါးခု၏ တရားဝင်ပြင်းထန်မှုအဆင့်များပါ၀င်ပြီး 2026 ခုနှစ်အထိ သမိုင်းဆိုင်ရာ အားနည်းချက်များကိုလည်း အကျုံးဝင်ပါသည်။

S2 — NGINX တရားဝင်ဗားရှင်း ထွက်ရှိမှုမှတ်တမ်း

အတည်ပြုပါ။ 1.30.6 / 1.31.7 ၏ 2026-10-14 , 1.31.8 ၏ 2026-10-21 မေလမှ စက်တင်ဘာလအထိ အရေးကြီးသော လုံခြုံရေးထုတ်ပြန်မှု မှတ်တိုင်များ။

S3 - စင်ကာပူ၏ ဆိုက်ဘာလုံခြုံရေးအေဂျင်စီ- F5 NGINX အရေးကြီးသော အားနည်းချက်သုံးခု

CVSS v4.0 9.2 ရမှတ်များ၊ လိုအပ်သော ဖွဲ့စည်းမှုအခြေအနေများနှင့် CVE-2026-15176၊ CVE-2026-93479 နှင့် CVE-2026-97205 အတွက် ကြားဖြတ်လျော့ပါးသက်သာစေရေး အကြံပြုချက်များ။

S4 - NHS အင်္ဂလန်- F5 NGINX အန္တရာယ်များသော အကြံပေးချက်

မမ်မိုရီဘေးကင်းရေးပြဿနာများ၏ DoS / ဖြစ်နိုင်ချေ RCE သက်ရောက်မှုနှင့် ASLR ပိတ်ထားခြင်း သို့မဟုတ် ကျော်သွားခြင်းကဲ့သို့သော ကန့်သတ်ချက်များကို ဖော်ပြသည်။

S5 — တရားဝင်အရင်းအမြစ် ကတိကဝတ်- CVE-2026-15176

၏အခြေအနေစစ်ဆေးချက်နှင့်ကိုက်ညီသည်။ alias နှင့် r->uri_changed ၌ ngx_http_map_uri_to_path() .

S6 — တရားဝင်အရင်းအမြစ် ကတိကဝတ်- CVE-2026-93479

HTTP/Stream ဇာတ်ညွှန်းအရှည်နှင့် သီးသန့်ကြားခံခွဲဝေမှု ယုတ္တိဗေဒတို့နှင့် သက်ဆိုင်သည်။

S7 - တရားဝင်အရင်းအမြစ် commit- CVE-2026-97205

r->main->blocked count threshold NGX_HTTP_MAX_BLOCKED 250 နှင့် asynchronous path fallback တို့နှင့် ကိုက်ညီပါသည်။

S8 — တရားဝင်အရင်းအမြစ် commit- CVE-2026-95101

HTTP/3 အမည်မသိဘောင်လက်ကျန်အရှည်နှင့် DATA တောင်းဆိုမှုကိုယ်ထည်အရှည်နှင့် သက်ဆိုင်သည့် အခြေအနေ ခွဲခြားမှု။

S9 — တရားဝင်အရင်းအမြစ် commit- CVE-2026-97629

TLS Session Ticket လည်ပတ်မှုအတွင်း သော့အပေါက်များအားလုံးနှင့် ကိုက်ညီပါသည်။

S10 — F5- CVE-2026-15176 ရောင်းချသူ၏ ကြေငြာချက်

alias၊ rewrite၊ $request_filename နှင့် access logs ကဲ့သို့သော အစပျိုးအချက်များစာရင်း။

S11 — F5- CVE-2026-93479 ရောင်းချသူ ကြေငြာချက်

စာရင်းမြေပုံ regex ဖမ်းယူမှု၊ root လမ်းကြောင်း နှင့် ပြောင်းလဲနိုင်သော အကဲဖြတ်မှုအခြေအနေများကို စာရင်းသွင်းပါ။

S12 — NGINX တရားဝင် TLS/SSL မော်ဂျူးစာရွက်စာတမ်းများ

ဖော်ပြချက် ssl_session_cache၊ ssl_session_tickets၊ ssl_session_ticket_key နှင့် client လက်မှတ် စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းနှင့် အခြားညွှန်ကြားချက်များ။

S13 — လုံခြုံရေးအကြံပေး: Ubuntu USN-8955-1 (2026-10-26)

Ubuntu 22.04 / 24.04 / 26.04 / 26.10. ၏ ပြီးပြည့်စုံသော ဆော့ဖ်ဝဲလ်ပက်ကေ့ချ်ကို ပုံသေဗားရှင်းနှင့် ဖြန့်ဖြူးမှုနယ်ပယ်ကို ပေးပါ။

S14 — လုံခြုံရေးအကြံပေး: Debian DSA-6575-1 (2026-10-21)

Debian 13 / trixie အတွက် လုံခြုံရေး ပြင်ဆင်မှု ပက်ကေ့ဂျ် 1.26.3-3+deb13u10 ကို အတည်ပြုပြီး CVE-2026-93479 အတွက် backport ချိတ်ဆက်မှုကို မှတ်တမ်းတင်ပါ။

S15 — အားနည်းချက် ခြေရာခံခြင်း။: Debian Security Tracker: CVE-2026-15176

Debian 12 / bookworm နှင့် Debian 13 / trixie ၏ ဖြန့်ဖြူးမှု ပြင်ဆင်မှု အခြေအနေကို အတည်ပြုရန် အသုံးပြုသည်။ အနာဂတ်လုံခြုံရေးအပ်ဒိတ်များနှင့်အတူ ဤအခြေအနေသည် ပြောင်းလဲနိုင်သည်။

S16 — အားနည်းချက် ခြေရာခံခြင်း။: Debian Security Tracker: CVE-2026-95101

မတူညီသော Debian အကိုင်းအခက်များရှိ HTTP/3 အားနည်းချက်၏ လုံခြုံရေးအခြေအနေ၏ နောက်ဆက်တွဲအတည်ပြုချက်။

S17 — လုံခြုံရေးအကြံပေး: Red Hat: CVE-2026-93479

အောက်တိုဘာလဆုတ်ယုတ်ကျဆင်းမှုအားနည်းချက်နှင့်ဇူလိုင် CVE-2026-42533 အတွက်ပြင်ဆင်မှုအကြားဆက်စပ်မှုကိုနောက်ဆက်တွဲနားလည်မှု။

S18 — NGINX တရားဝင် ပြောင်းပြန် proxy မော်ဂျူး စာရွက်စာတမ်း

proxy_request_buffering၊ client_max_body_size၊ alias၊ aio စသည်ဖြင့် စည်းမျဥ်းများ၏ အဓိပ္ပါယ်နှင့် မူရင်းတန်ဖိုးများကို မေးမြန်းပါ။

S19 — NGINX Plus တရားဝင်ဖြန့်ချိရေးမှတ်စုများ

Plus CR/LTS အကိုင်းအခက်များ၊ ဗားရှင်းများ၊ ဖာထေးမှုများနှင့် တွဲဖက်အသုံးပြုနိုင်မှု သတိပေးချက်များကို အဆင့်မြှင့်ပါ။

S20 — NGINX JavaScript / njs တရားဝင် လုံခြုံရေး ထုတ်ပြန်ချက်

အောက်တိုဘာလ 2026 njs 1.0.2 နှင့် ဆက်စပ် XML အတည်ပြုခြင်း၊ မှတ်ဉာဏ်ကုန်ခန်းခြင်း ပြဿနာများ ပါရှိသည်။

S21 — Kubernetes- Community ingress-nginx တရားဝင် အငြိမ်းစား ညွှန်ကြားချက်များ

ပရောဂျက်သည် မတ်လ 2026 တွင် အသစ်ထွက်ရှိမှုများနှင့် လုံခြုံရေးပြင်ဆင်မှုများကို ရပ်တန့်လိုက်ပြီး ထိန်းသိမ်းထားသည့် ထိန်းချုပ်ကိရိယာ သို့မဟုတ် Gateway API ကို ပြောင်းရွှေ့ရန် အကြံပြုထားသည်။

S22 — NGINX တရားဝင်ဝန်ဆောင်မှုထိန်းချုပ်မှုနှင့် အွန်လိုင်း binary အဆင့်မြှင့်တင်မှု ညွှန်ကြားချက်များ

လုပ်ငန်းစဉ်ပြောင်းခြင်းကို လက်ခံခြင်းအတွက် စီစဉ်ဖွဲ့စည်းမှု ပြန်လည်စတင်ခြင်း၊ ပြန်လည်စတင်ခြင်းနှင့် အွန်လိုင်းလုပ်ဆောင်နိုင်သော ဖိုင်အဆင့်မြှင့်တင်ခြင်းနည်းလမ်းများကို ခွဲခြားသတ်မှတ်ပါ။

S23 - အစိုးရလုံခြုံရေးသတိပေးချက်- မေလ 2026 NGINX အားနည်းချက်ကို ပြန်လည်ရေးသားခြင်း

CVE-2026-42945 အတွက် သမိုင်းဆိုင်ရာ အန္တရာယ် နောက်ခံနှင့် လုံခြုံရေး အပ်ဒိတ် အကြံပြုချက်များကို ပေးပါ။ တောရိုင်းအတွင်း အမြတ်ထုတ်ခြင်းဆိုင်ရာ စီရင်ချက်သည် ထိုအချိန်က အေဂျင်စီ၏ ကြေငြာချက်နှင့် နောက်ထပ်အဖြစ်အပျက် အထောက်အထားများအပေါ် အခြေခံသင့်သည်။

S24 — F5- CVE-2026-95101 နှင့် CVE-2026-97629 ရောင်းချသူ ကြေငြာချက်များ

HTTP/3 တောင်းဆိုမှုကိုယ်ထည်ထိုးဆေးနှင့် အလိုအလျောက် TLS လက်မှတ်သော့လှည့်ခြင်းတို့၏ အန္တရာယ်များကို ကာမိပါသည်။

S25 — F5- CVE-2026-97205 ရောင်းချသူ၏ ကြေငြာချက်

ဖော်ပြချက် SSI/AIO အစပျိုးအခြေအနေများနှင့် ဖြစ်နိုင်ခြေရှိသော မှတ်ဉာဏ်ဖောက်ပြန်မှုအန္တရာယ်များ။

NGINX လုံခြုံရေးအပ်ဒိတ်- ဖွဲ့စည်းမှုစစ်ဆေးမှုများ၊ အဆင့်မြှင့်တင်မှုများနှင့် အတည်ပြုခြင်း။