Sources များကို အောက်တိုဘာလ 22 ရက်၊ 2026 ခုနှစ်အထိ စစ်ဆေးခဲ့သည်။ Audience- PHP အပလီကေးရှင်းအော်ပရေတာများ၊ လုံခြုံရေးတုံ့ပြန်သူများနှင့် စိတ်ကြိုက် PHP တည်ဆောက်မှုများကို ထိန်းသိမ်းသည့် အင်ဂျင်နီယာများ။

ဤဆောင်းပါးသည် အကြောင်းရင်း၊ အကျိုးသက်ရောက်မှုအတိုင်းအတာ၊ တရားဝင်ပြုပြင်မှုလုပ်ငန်းစဉ်၊ ယာယီလျော့ပါးရေးအစီအမံများနှင့် PHP2Shell အားနည်းချက်၏တရားဝင် patch အကောင်အထည်ဖော်မှုကို အကျဉ်းချုပ်ဖော်ပြထားသည်။ ပင်မစာသားကို S1 ကဲ့သို့သော နံပါတ်များဖြင့် ကိုးကားထားသည်။ အရင်းအမြစ်လင့်ခ်များအားလုံးကို စာသား၏အဆုံးတွင် နောက်ဆက်တွဲတွင် ဖော်ပြထားပါသည်။ ဖွဲ့စည်းမှုအပိုင်းအပိုင်းသည် အမှန်တကယ်ဗားရှင်း၊ လုပ်ငန်းစွမ်းဆောင်ရည်နှင့် ဖွဲ့စည်းမှုဆိုင်ရာ အမွေဆက်နွယ်မှုအပေါ် အခြေခံ၍ ချိန်ညှိရန်လိုအပ်သည့် အသုံးချမှုပုံစံပုံစံတစ်ခုဖြစ်သည်။

TL;DR- ပြုပြင်ရေး အဆင့်များနှင့် အကြံပြုချက်များ

  1. အဆင့်မြှင့်ပါ။ PHP runtime : သက်ဆိုင်ရာဌာနခွဲကို အနည်းဆုံးအဆင့်မြှင့်ပါ။ 8.2.35 , 8.3.36 , 8.4.27 သို့မဟုတ် 8.5.12 . ဖြန့်ချီရေးပက်ကေ့ဂျ်များအတွက်၊ CVE နှစ်ခုလုံးကို ပြုပြင်ကြောင်း ရောင်းချသူမှ အတည်ပြုသော ပြီးပြည့်စုံသော ပက်ကေ့ဂျ်ဗားရှင်းကို အသုံးပြုပါ။ S1 S10
  2. လုပ်ငန်းစဉ်ဟောင်းအားလုံးကို အစားထိုး- PHP worker တိုင်းကို ပြန်လည်စတင်ပါ သို့မဟုတ် လှည့်ပတ်ပါ၊ ဝန်ဆောင်မှုပေးခြင်း၊ နှင့် ကွန်တိန်နာကို အဆင့်မြှင့်ပြီးနောက် ကွန်တိန်နာကို အဆင့်မြှင့်တင်ပြီး အဟောင်းများ ထွက်သွားပြီဖြစ်ကြောင်း အတည်ပြုပါ။
  3. Verify အားဖြင့် အမှန်တကယ် Web တောင်းဆိုမှုလမ်းကြောင်း- Web SAPI၊ ပက်ကေ့ဂျ်ဗားရှင်းအပြည့်အစုံနှင့် လုပ်ဆောင်နေသည့် ဥပမာကို စစ်ဆေးပါ။ php -v တစ်ခုတည်းကို စစ်ဆေးခြင်းသည် တိုက်ရိုက်ဝန်ဆောင်မှုကို ပုံသေဖြစ်ကြောင်း မသတ်မှတ်ပါ။
  4. Run စီးပွားရေးဆုတ်ယုတ်မှုစစ်ဆေးပြီး ပုံမှန်အရင်းအမြစ်ဘတ်ဂျက်များ- စမ်းသပ်ဝင်ရောက်ခြင်း၊ စက်ရှင်ကိုင်တွယ်ခြင်း၊ အပ်လုဒ်များ၊ တင်သွင်းမှုများနှင့် အမှားအယွင်းများကို ကိုင်တွယ်ခြင်း။ PHP မမ်မိုရီကန့်သတ်ချက်ကို ခေတ္တဖယ်ရှားခဲ့ပါက၊ ဖာထေးပြီးနောက် သင့်လျော်သော ကန့်သတ်ဘတ်ဂျက်ကို ပြန်လည်ရယူပါ။
  5. အကယ်၍ ချက်ချင်းအဆင့်မြှင့်ရန် မဖြစ်နိုင်ပါ- ၎င်းသည် PHP သို့မရောက်ရှိမီ စိတ်မချရသူများကို ကန့်သတ်ပါ။ အပ်လုဒ်တိုးတက်မှုကို ပိတ်ထားခြင်းနှင့် PHP 8.5 အပိုင်း 5 တွင်ဖော်ပြထားသည့်အတိုင်း သေဆုံးစေသော နောက်ကြောင်းပြန်လမ်းကြောင်းများကို အကဲဖြတ်ပါ။ ဖွဲ့စည်းမှုလျှော့ချခြင်းနှင့် WAF စည်းမျဉ်းများသည် အကန့်အသတ်ဖြင့် လွှမ်းခြုံထားပြီး အဆင့်မြှင့်တင်မှုကို အစားထိုး၍မရပါ။ S1S2S3

1. Vulnerability Overview နှင့် Risk Judgement

PHP2Shell သည် အောက်တိုဘာလ 21 ရက်၊ 2026 ရက်နေ့တွင် PHP မှ တရားဝင်ထုတ်ဖော်ခဲ့သည့် Critical အဆင့် အားနည်းချက်နှစ်ခုကို ရည်ညွှန်းပါသည်။ နှစ်ခုစလုံးသည် PHP အင်ဂျင်၏ မန်မိုရီနှင့် တောင်းဆိုမှုဘဝသံသရာစီမံခန့်ခွဲမှုနှင့် ဆက်စပ်နေပြီး၊ remote code လုပ်ထားသော unauth exe ကို အန္တရာယ်ဖြစ်စေပါသည်။ S1S2S3

ပရောဂျက်CVE-2026-109618CVE-2026-109619
တရားဝင်အမည်RCE via OOM corruptionRCE via stale global state
အဓိကပြဿနာများမှတ်ဉာဏ်မလုံလောက်ပါက မူမမှန်ခုန်တက်စေပြီး အစပြုခြင်း မပြီးပြတ်သေးသော အခြေအနေတစ်ခု ကျန်ရစ်စေသည်။အလုပ်သမားများထဲတွင် ကျန်ရှိနေသော ကမ္ဘာ့အခြေအနေသည် ထုတ်ပြန်ထားသော တောင်းဆိုချက်မှတ်ဉာဏ်ကို ညွှန်ပြသည်။
သာမာန်ဖြစ်ပွားချိန်လက်ရှိတောင်းဆိုမှု၏ ကနဦးလုပ်ဆောင်မှု၊ လုပ်ဆောင်မှု သို့မဟုတ် ရှင်းလင်းရေးလုပ်ငန်းစဉ်ယခင်တောင်းဆိုချက်သည် အခြေအနေမှ ထွက်သွားပြီး နောက်ဆက်တွဲတောင်းဆိုမှုများသည် ၎င်းကို ကြိုတင်စားသုံးသည်။
OOM သည် လိုအပ်သောအခြေအနေဖြစ်ပါသလား။အားနည်းချက်၏ အဓိက အစပျိုးသည့် ယန္တရားနှင့် သက်ဆိုင်သည်။မရှိ၊ အခြားသော သေစေလောက်သော အမှားအယွင်းများနှင့် ရောဂါရှာဖွေပြီးနောက် ရှင်းလင်းရေးတွင်လည်း ပါဝင်နိုင်သည်။
အခြေခံ ပြုပြင်ရေး ဦးတည်ချက်ခွဲဝေမှုပျက်ကွက်မှုများနှင့် တောင်းဆိုမှုရပ်စဲမှုများကို လုံခြုံစွာကိုင်တွယ်ပါ။ပြည်နယ်ပိုင်ဆိုင်မှုကို ပြုပြင်ပါ၊ ရှင်းလင်းချိန်နှင့် စောစီးစွာ အစပြုခြင်း
စွန့်ပစ်ခြင်းလိုအပ်ချက်များပြုပြင်ရမည်။တစ်ချိန်တည်းမှာ ပြုပြင်ရမယ်။

အခြေခံ- တရားဝင်လုံခြုံရေး စာစောင်နှစ်ခုနှင့် တင်ပြမှုများကို ပြင်ဆင်ပါ။ S2S3S4

1.1 သက်ရောက်မှုရှိသော ဖြန့်ကျက်မှုများကို နားလည်ခြင်း။

PHP တရားဝင်စဉ်းစားသည်။ အားလုံး PHP ဖြန့်ကျက်ကိုင်တွယ်ခြင်း။ Web တောင်းဆိုချက်များ အပါအဝင်၊ PHP-FPM , Apache mod_php , php-cgi , FrankenPHP , နှင့် LiteSpeed . သရုပ်ပြခဲ့သည်။ mod_php အပလီကေးရှင်းကုဒ်မလည်ပတ်မီ တိုက်ခိုက်မှုသည် ဖြစ်ပေါ်လာနိုင်သည်၊ ထို့ကြောင့် လော့ဂ်အင်စစ်ဆေးမှုများ၊ framework အလယ်တန်းဆော့ဖ်ဝဲနှင့် အပလီကေးရှင်းအပ်လုဒ်အတည်ပြုချက်သည် ထိုလမ်းကြောင်းကို ဖုံးကွယ်ထား၍မရပါ။ S1

“ဖြန့်ကျက်ထားရန် လိုအပ်သည်” နှင့် “အချို့သော တိုက်ခိုက်ရေးကွင်းဆက်တစ်ခုကို လုံးလုံးသက်သေပြပြီးပြီ” အကြား ပိုင်းခြားရန် လိုအပ်ပါသည်။ CVE-2026-109618 ၏ ကြေငြာချက်- FPM သည် တောင်းဆိုမှု စတင်ခြင်း မအောင်မြင်ပြီးနောက်၊ စတင်လုပ်ဆောင်မှု ပျက်ကွက်ပြီးနောက် mod_php ၏ သက်ဆိုင်ရာ ရှင်းလင်းရေးလမ်းကြောင်းကို ပိတ်ဆို့သွားပါမည်။ သို့သော်၊ အောင်မြင်သောစတင်ပြီးနောက် OOM လမ်းကြောင်းသည် အန္တရာယ်ရှိဆဲဖြစ်သည်။ ဤ CVE အတွက် FPM exploit အပြည့်အစုံကို သရုပ်မပြရသေးကြောင်း ကြေညာချက်တွင် ဖော်ပြထားသည်။ FPM သည် ဘေးကင်းကြောင်း ခန့်မှန်းရန် ဤကန့်သတ်ချက်ကို အသုံးပြု၍မရပါ၊ အထူးသဖြင့် CVE-2026-109619 ကို လျစ်လျူရှု၍မရပါ။ S2S3

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

သာမန်တစ်ကြိမ် CLI script များတွင် တူညီသော HTTP ထည့်သွင်းမှု မရှိပါ။ သို့သော် CLI သို့မဟုတ် မြှုပ်သွင်းမုဒ်တွင် အချိန်ကြာမြင့်စွာ ပြင်ပအလုပ်များကို ကိုင်တွယ်သည့် လုပ်ငန်းစဉ်များသည် runtime နှင့် life cycle inventory တွင် ဆက်လက်ပါဝင်နေသင့်သည်။ CMS၊ framework သို့မဟုတ် Composer မှီခိုမှုများကိုသာ အပ်ဒိတ်လုပ်ပြီး အရင်းခံ PHP အင်ဂျင်ကို အလိုအလျောက် အစားထိုးမည်မဟုတ်ပါ။

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

2.1 ပထမဦးစွာ ဘဝသံသရာနှစ်ခုကို နားလည်ပါ။

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

ထို့ကြောင့် အင်ဂျင်သည် ကန့်သတ်ချက်နှစ်ခုကို ထိန်းထားရမည်-

  • Initialization ကန့်သတ်ချက်- အခြားကုဒ်များမြင်နိုင်သည့်ဒေတာသည် လုံခြုံစွာဖတ်နိုင်၊ ဖြတ်ကျော်ကာ ဖျက်ဆီးနိုင်သည့် အခြေအနေတွင် ရှိနေရပါမည်။
  • Lifecycle ကန့်သတ်ချက်- တောင်းဆိုချက် မမ်မိုရီကို ဖယ်ရှားပြီးသည်နှင့်၊ ကြာရှည်သော အကွက်များသည် ထိုမှတ်ဉာဏ်အတွင်းရှိ လိပ်စာများကို တရားဝင်အခြေအနေအဖြစ် ဆက်လက်ကုသခြင်းမပြုရပါ။

ဤကန့်သတ်ချက်နှစ်ခုသည် အားနည်းချက်အုပ်စုနှစ်ခု၏ အဓိကကျရှုံးမှုပုံစံများနှင့် သက်ဆိုင်ပါသည်။ အောက်ပါလုပ်ငန်းစဉ်သည် ကြေငြာချက်များနှင့် patch စုစည်းမှုပေါင်းစပ်ထားသော ယန္တရားဖော်ပြချက်ဖြစ်သည်။ ဖြန့်ကျက်မှုတိုင်းတွင် အတိအကျတူညီသောရောက်ရှိနိုင်သောလမ်းကြောင်းရှိသည်ဟု မဆိုလိုပါ။ S2S3S5

2.2 CVE-2026-109618- OOM မပြီးဆုံးသေးသော အခြေအနေအပ်ဒိတ်ကို နှောင့်ယှက်ခဲ့သည်

အကောင်အထည်ဖော်မှုဟောင်းသည် ဒေသတွင်းမဟုတ်သော ခုန်ခြင်းအမျိုးအစားကို အသုံးပြုသည်။ longjmp() ကိုင်တွယ်ရန် OOM နှင့် ဆက်စပ်လမ်းကြောင်းသည် လက်ရှိလုပ်ဆောင်မှုအကြောင်းအရာမှတဆင့် ထွက်သည်။ zend_bailout() . အန္တရာယ်ကတော့ အပိုင်းအစတစ်ခုပါပဲ။ C ကုဒ်သည် အရာဝတ္ထုအသစ်၊ ခင်းကျင်းမှု သို့မဟုတ် အခြားကုဒ်သို့ တောင်းဆိုမှုအခြေအနေအား ထုတ်ဝေနိုင်သော်လည်း အကွက်အားလုံးကို အစပြုခြင်း မပြီးမြောက်သေးပါ။ ဤအချိန်တွင်၊ သက်ဆိုင်ရာအချိန်၌ ခွဲဝေမှုပျက်ကွက်ပါက ပုံမှန်အပိတ်အဆင့်များကို ကျော်သွားနိုင်သည်။ S2

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

  1. တောင်းဆိုချက်အတွင်းပိုင်း ဖွဲ့စည်းပုံကို ဖန်တီးပါ သို့မဟုတ် အပ်ဒိတ်လုပ်ကာ ၎င်းကို ဝင်ရောက်နိုင်စေရန် ပြုလုပ်ပါ။
  2. နောက်ဆက်တွဲ မှတ်ဉာဏ်ခွဲဝေမှု မအောင်မြင်သဖြင့် OOM ကို အစပျိုးထားသည်။
  3. execution flow သည် လက်ရှိ function မှ ခုန်တက်သွားပြီး အစပြုခြင်း သို့မဟုတ် restore state ကို အပြီးသတ်ရန် မူလအသုံးပြုခဲ့သည့် ကုဒ်ကို လုပ်ဆောင်မည်မဟုတ်ပါ။
  4. ရှင်းလင်းရေးတောင်းဆိုမှုသည် ဤဖွဲ့စည်းပုံများကို ဆက်လက်လုပ်ဆောင်နေပြီး မမှန်ကန်သောအကြောင်းအရာများကို တရားဝင်အကွက်များ သို့မဟုတ် လိပ်စာများအဖြစ် သတ်မှတ်သည်။

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

သေးငယ်သော တောင်းဆိုမှုများ အဘယ်ကြောင့် မှတ်ဉာဏ်ကုန်သွားသနည်း။

တောင်းဆိုချက်ကိုယ်ထည်ရှိ ဘိုက်အရေအတွက်နှင့် ခွဲခြမ်းစိတ်ဖြာပြီးနောက် အစုအသုံးပြုမှုတို့သည် တူညီသည်မဟုတ်ပါ။ A အကွက်သည် PHP အတွင်းရှိ စာကြောင်းများစွာ၊ အခင်းအကျင်းဒြပ်စင်များနှင့် မက်တာဒေတာအရာဝတ္ထုများနှင့် ဆက်စပ်နိုင်သည်; ထည့်သွင်းဖွဲ့စည်းပုံဆိုင်ရာ ရှုပ်ထွေးမှုသည် မှတ်ဉာဏ်ချဲ့ထွင်မှု အတိုင်းအတာကို သက်ရောက်မှုရှိမည်ဖြစ်သည်။

တရားဝင်ကြေငြာချက်တွင်ဖော်ပြထားသော အစိတ်အပိုင်းများစွာပါသော ပြဿနာများပါဝင်သည်- ရရှိနိုင်သောကြေငြာချက်အရှည်ပျောက်ဆုံးနေချိန်တွင် ကနဦးအရွယ်အစားစစ်ဆေးခြင်းကွာဟချက်၊ အစိတ်အပိုင်းတစ်ခုအတွက် ခေါင်းစီးအရေအတွက်ကို လုံလောက်စွာကန့်သတ်မထားဘဲ ဖိုင်အလွတ်ထိန်းချုပ်မှုများသည် မက်တာဒေတာကို ဆက်လက်ထုတ်လုပ်နေဆဲဖြစ်ပြီး အစုအဝေးအမည်များဖြင့် array workload တိုးလာပါသည်။ အပလီကေးရှင်း၏ကိုယ်ပိုင်ဖြည်ဖြည်ခြင်း၊ ကုဒ်ဖော်ခြင်း သို့မဟုတ် ထည့်သွင်းခြင်းအား ပြန်လည်သတ်မှတ်ခြင်းသည် OOM ၏ရင်းမြစ်တစ်ခုလည်း ဖြစ်နိုင်သည်။ S2

အကာအကွယ်ကောက်ချက်နှစ်ခုကို ဤအရာမှ ထုတ်ယူနိုင်သည်။

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

အဘယ်ကြောင့်ဆိုသော် အပလီကေးရှင်းစစ်မှန်ကြောင်းအထောက်အထားပြခြင်းသည် နောက်ကျနေနိုင်သောကြောင့်ဖြစ်သည်။

mod_php တွင်၊ တောင်းဆိုချက်စတင်ခြင်းအဆင့်အတွင်း တောင်းဆိုချက်ကိုယ်ထည်ကို အလိုအလျောက် ပိုင်းခြားနိုင်မည်ဖြစ်သည်။ စတင်ခြင်း မအောင်မြင်သော်လည်း၊ ဆက်စပ်တောင်းဆိုမှု ရှင်းလင်းခြင်းကို ဆက်လက်လုပ်ဆောင်ပါမည်။ ထို့ကြောင့် အပလီကေးရှင်းကုဒ်မတိုင်မီ အတည်ပြုထားသော တိုက်ခိုက်မှုလမ်းကြောင်းများ ဖြစ်ပေါ်နိုင်သည်။ ဤအဆင့်တွင် ထိတွေ့မှုကို လျှော့ချရန်၊ ကန့်သတ်ချက်များကို ပြောင်းပြန်ပရောက်စီ၊ Web ဆာဗာ သို့မဟုတ် PHP တောင်းဆိုမှုလုပ်ဆောင်ခြင်းမတိုင်မီ အခြားနယ်နိမိတ်တွင် ထားရှိရန် လိုအပ်သည်။ S1S2

2.3 CVE-2026-109619- တောင်းဆိုချက် မမ်မိုရီကို ထုတ်ပြီးပြီ၊ ကမ္ဘာလုံးဆိုင်ရာ ရည်ညွှန်းချက်သည် အသက်ရှင်ဆဲဖြစ်သည်

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

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

အခန်းကဏ္ဍ သို့မဟုတ် အခြေအနေအဓိပ္ပါယ်အကာအကွယ်အတွက် သက်ရောက်မှုများ
ပြည်နယ်ထုတ်လုပ်သူဤတောင်းဆိုမှုမှ ပိုင်ဆိုင်သည့်ပြည်နယ်ကို နောက်ပိုင်းတွင် ဝင်ရောက်အသုံးပြုနိုင်ဆဲဖြစ်သော တည်နေရာတစ်ခုတွင် ထည့်သွင်းပါ။ပုံမှန်မဟုတ်သော ထွက်ပေါက်ပြီးနောက် သက်ဆိုင်ရာ ရှင်းလင်းမှု ပြီးမြောက်ခြင်း ရှိမရှိ စစ်ဆေးရန်
အဆင့်အတန်းရှိနေဆဲ၎င်းကို မရှင်းလင်းခဲ့ပါ သို့မဟုတ် ရှင်းလင်းပြီးနောက် နောက်ကျသော လည်ပတ်မှုဖြင့် ပြန်လည်ဖြည့်သွင်းခဲ့သည်။အစောပိုင်းပိတ်စအဆင့်တွင် တစ်ကြိမ်ရှင်းလင်းရုံနှင့် မလုံလောက်ပါ။
အလုပ်သမား ပြန်သုံးတယ်။အလားတူ အလုပ်သမားသည် နောက်ဆက်တွဲ တောင်းဆိုမှုများကို ဆက်လက်လုပ်ဆောင်နေပါသည်။ဝန်ထမ်းအများအပြားသည် မှတ်ဉာဏ်ဘေးကင်းရေးအာမခံချက်မဟုတ်ဘဲ အချိန်ဇယားဆွဲခြင်းကွာခြားချက်မျှသာဖြစ်သည်။
ကြိုတင်စားသုံးသူသက်ဆိုင်ရာပြည်နယ်ကို ပုံမှန်အတိုင်းမစတင်မီ လက်ကျန်တန်ဖိုးကို ဖတ်၊ ထုတ်ပါ သို့မဟုတ် ဆုံးဖြတ်ပါ။စတင်ခြင်းမပြုမီ INI၊ စက်ရှင်နှင့် အခြားလမ်းကြောင်းများကို စစ်ဆေးရပါမည်။

ဤအခြေအနေများကို ပေါင်းစပ်ဖြည့်ဆည်းရန် လိုအပ်ပါသည်။ မည်သည့် error log မဆို ကိုယ်တိုင်က အားနည်းချက်ကို အောင်မြင်စွာ အသုံးချပြီးဖြစ်ကြောင်း သက်သေမပြပါ။ S3

၎င်းသည် လိုအပ်သော ကြိုတင်လိုအပ်ချက်အဖြစ် OOM မလိုအပ်ပါ။

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

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

“မစတင်မီ” သီးခြားစီ ကုသရန် လိုအပ်ပါသည်။

အတည်ပြုထားသော စားသုံးသူ နှစ်မျိုး၏ အချိန်သည် ကွဲပြားသည်-

  • Early INI ရောဂါရှာဖွေခြင်း- ပုံမှန် executor စတင်ခြင်းမပြုမီ တောင်းဆိုမှုပြဿနာသတိပေးချက်၊ သတိပေးချက် သို့မဟုတ် ကန့်ကွက်ခြင်းတွင် အသုံးပြုထားသော အချို့သောဖွဲ့စည်းပုံများသည် အမှားအယွင်းဟောင်းအခြေအနေသို့ ဝင်ရောက်နိုင်သည်။
  • session အပ်လုဒ်တိုးတက်မှု- တောင်းဆိုချက်ကိုယ်ထည်ပိုင်းခြားစိတ်ဖြာမှုလုပ်ငန်းစဉ်အတွင်း စက်ရှင်ကို ကြိုတင်လုပ်ဆောင်နိုင်သော်လည်း ပုံမှန် module RINIT သည် မပြီးမြောက်သေးပါ။ အပလီကေးရှင်းသည် session_start() ကို အထူးတလည်ခေါ်ဆိုခြင်းမရှိသောကြောင့် လမ်းကြောင်းမရှိဟု ယူဆ၍မရပါ။ S3

အားလုံးမဟုတ်ပါ။ INI ဖွဲ့စည်းမှုပုံစံများသည် တူညီသောအန္တရာယ်အချိန်ကိုက်ရှိသည်။ directory-level configuration ၏ mod_php နှင့် PHP_VALUE / PHP_ADMIN_VALUE ဖြတ်သန်းသွားသည်။ FPM ရှေ့ဆုံးက သာမန်လူတွေနဲ့ ခွဲခြားထားဖို့ လိုပါတယ်။ php.ini , FPM pool startup configuration နှင့် FPM .user.ini . နောက်ပိုင်းတွင် ကွဲပြားသောဖွဲ့စည်းပုံအချိန်အခါများ ရှိပြီး တူညီသောအစောပိုင်းစားသုံးသူဟု စုစည်း၍မရနိုင်ပါ။ S3

display_errors၊ log_errors၊ error_reporting ကို လျှော့ချခြင်း သို့မဟုတ် @ ကို အသုံးပြုခြင်းသည် ရောဂါရှာဖွေခြင်း၏ မြင်နိုင်စွမ်းကိုသာ သက်ရောက်မှုရှိပါသည်။ မှတ်တမ်းကို ထုတ်ပေးခြင်းရှိမရှိ မဆုံးဖြတ်မီ သက်ဆိုင်ရာအတွင်းပိုင်းပြည်နယ်အား ဝင်ရောက်ကြည့်ရှုနိုင်မည်ဖြစ်သည်။ S3

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

3.1 တရားဝင် ရေစီးကြောင်းပြင်ဆင်မှု အခြေခံလိုင်း

လက်ရှိ PHP ဌာနခွဲဤတရားဝင်ပြင်ဆင်မှုပါဝင်သည့် ပထမဆုံးဗားရှင်းအကြံပြုချက်များ
8.28.2.35တူညီသောပြင်ဆင်မှုများပါရှိသော ဤဗားရှင်းသို့ အဆင့်မြှင့်ပါ။
8.38.3.36အထက်ပါအတိုင်းပါပဲ။
8.48.4.27အထက်ပါအတိုင်းပါပဲ။
8.58.5.12အထက်ပါအတိုင်းပါပဲ။
8.1 နှင့် အစောပိုင်းဗားရှင်းများရေဆန် အထွေထွေ ထောက်ပံ့မှု ပြီးဆုံးသွားပါပြီ။ပံ့ပိုးထားသော အကိုင်းအခက်များသို့ ရွှေ့ပြောင်းခြင်းကို ဦးစားပေးပါ။ ကာလတို စစ်ဆေးချက်ထုတ်ပြန်ခြင်း သို့မဟုတ် LTS ထုတ်လုပ်သူ ကျောထောက်နောက်ခံ

ဗားရှင်းနှင့် ပံ့ပိုးမှုအခြေအနေသည် PHP ၏တရားဝင်ကြေငြာချက်အပေါ် အခြေခံထားပြီး အချိန်အခြေခံလိုင်းမှာ အောက်တိုဘာလ 22 ရက်၊ 2026 ဖြစ်သည်။ S1

၎င်းတို့သည် Branch-specific fix thresholds ဖြစ်သည်။ 8.5.12 အောက်တွင်ရှိသော ဗားရှင်းတိုင်းသည် အားနည်းချက်ရှိကြောင်း ထုတ်ပြန်ချက်တစ်ခုဖြင့် ၎င်းတို့အား အစားထိုး၍မရနိုင်ပါ- အခြားအကိုင်းအခက်များရှိ 8.2.35 နှင့် 8.4.27 ကဲ့သို့သော ဗားရှင်းများတွင် ပြုပြင်မှုများပါရှိပြီးဖြစ်သည်။

3.2 ဖြန့်ချီရေးပက်ကေ့ဂျ်ဗားရှင်းအပြည့်အစုံကို စစ်ဆေးပါ။

Distro များသည် အထက်ရေစီးကြောင်းဗားရှင်းအဟောင်းများကို အခြေခံ၍ လုံခြုံရေးပြင်ဆင်မှုများကို မကြာခဏ ထည့်သွင်းလေ့ရှိသည်။ လက်ခံမှုသည် ထုတ်ဝေသည့်ဗားရှင်း၊ သိုလှောင်မှုရင်းမြစ်၊ အထုပ်ဗားရှင်းအပြည့်အစုံနှင့် လုံခြုံရေးစာစောင်ကိုလည်း စစ်ဆေးသင့်သည်။

ဥပမာအားဖြင့်၊ Ubuntu 24.04 LTS fix package version အတွက် ဖော်ပြထားပါသည်။ Ubuntu USN-8948-1 သည်-

8.3.6-0ubuntu0.24.04.13

၎င်း၏အထက်ပိုင်းအပိုင်းသည် 8.3.6 ဖြစ်နေဆဲဖြစ်သော်လည်း အဆိုပါဖြန့်ဖြူးမှု၏ ပက်ကေ့ခ်ျဗားရှင်းအပြည့်အစုံကို ဤပြင်ဆင်ချက်ကြေညာချက်တွင် ထည့်သွင်းထားသည်။ ဤကောက်ချက်ချမှုသည် သက်ဆိုင်ရာ ဖြန့်ဖြူးမှုနှင့် ပက်ကေ့ဂျ်ရင်းမြစ်နှင့်သာ သက်ဆိုင်ပြီး 8.3.6 ကိုလည်း ပြသသည့် မည်သည့်တည်ဆောက်မှုများအတွက်မဆို ယေဘုယျအားဖြင့် အဓိပ္ပာယ်ဖော်၍မရပါ။ S10

3.3 မှန်ကန်သော patch ကိုရွေးချယ်ခြင်း။

မြင်ကွင်းဦးစားပေးအစီအစဉ်လက်ခံခြင်းအတွက် အဓိကအချက်များ
ဖြန့်ဖြူးမှု PHP ပက်ကေ့ဂျ်ကို အသုံးပြုခြင်း။ထုတ်လုပ်သူမှ ထုတ်ပြန်သော လုံခြုံရေးအပ်ဒိတ်များကို ထည့်သွင်းပါ။ကြေငြာချက်တွင် CVE နှစ်ခုလုံး ပါဝင်ပါသည်။ ပြီးပြည့်စုံသော ပက်ကေ့ဂျ်ဗားရှင်းသည် မှန်ကန်ပါသည်။
တရားဝင် PHP ကွန်တိန်နာ သို့မဟုတ် ကိုယ်တိုင်တည်ဆောက်ထားသောပုံကို အသုံးပြုပါ။အခြေခံ runtime ကို အပ်ဒိတ်လုပ်ပါ၊ ပြန်လည်တည်ဆောက်ပြီး အသုံးပြုပါ။လုပ်ဆောင်နေသည့် ဥပမာသည် ပုံအသစ်ကို အသုံးပြုသည်။ မိတ္တူအဟောင်းအားလုံး ထွက်သွားပါပြီ။
အကိုင်းအခက်များကို ကိုယ်တိုင်ပြုစု ဆောင်ရွက်ပေးသည်။ဤဌာနခွဲ၏တရားဝင်လုံခြုံရေးဗားရှင်း သို့မဟုတ် တရားဝင် patch အစုံအလင်ကို အသုံးပြုပါ။ဘဏ်ခွဲကိုက်ညီမှု၊ မှီခိုမှုပြီးစီးမှု၊ တိုးချဲ့မှု လိုက်ဖက်ညီမှုနှင့် ဆုတ်ယုတ်မှုဖြတ်သန်းမှု
7.4၊ 8.0၊ 8.1 ဘာသာရပ်ရောင်းချသူ ကျောထောက်နောက်ခံကို ဦးစားပေးပါ။ လိုအပ်ပါက တရားဝင် အရေးပေါ် အရင်းအမြစ်ကုဒ်ဌာနခွဲကို အကဲဖြတ်ပါ။အပြုအမူပြောင်းလဲမှုများကို ခွဲခြားသတ်မှတ်ပြီး ပံ့ပိုးထားသောဗားရှင်းများသို့ ပြောင်းရွှေ့ခြင်းကို အချိန်ဇယားဆွဲပါ။

တရားဝင် ဖာထေးမှုများကို ထုတ်ဝေခဲ့ပြီးဖြစ်ကာ အမှန်တကယ် ပြုပြင်မှုများသည် ဤပြင်ဆင်မှုများမှ စတင်သင့်သည်။ အပိုင်း 6 ရှိ ကုဒ်အတိုအထွာများသည် ဒီဇိုင်းပိုင်းနှင့် ပေါ်လွင်ချက်များကို ပြန်လည်သုံးသပ်ရန် ရည်ရွယ်ပြီး သီးခြားလွတ်လပ်စွာအသုံးချနိုင်သည့် ပြီးပြည့်စုံသော patch ကို မဖွဲ့စည်းထားရန် ရည်ရွယ်ပါသည်။ S1S4S6

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

4.1 တောင်းဆိုချက်များကို အမှန်တကယ် ကိုင်တွယ်သည့် runtime ၏စာရင်း

အနည်းဆုံး မှတ်တမ်းတင်ရန် လယ်ဂျာအကျဉ်းကို ဖွဲ့စည်းရန် အကြံပြုလိုသည်-

  • ဒိုမိန်းအမည် သို့မဟုတ် ဝန်ဆောင်မှု၊ ပြောင်းပြန် proxy နောက်ခံ၊ PHP SAPI။
  • PHP ဌာနခွဲ၊ ပက်ကေ့ဂျ်ဗားရှင်းအပြည့်အစုံ သို့မဟုတ် ရုပ်ပုံအကျဉ်းချုပ်၊ တည်ဆောက်မှုအရင်းအမြစ်။
  • FPM pool၊ အမှန်တကယ်ဝန်ဆောင်မှုယူနစ်၊ ကွန်တိန်နာ သို့မဟုတ် Pod၊ ပုံစံတူအရေအတွက်။
  • တိုးချဲ့မှုများ၊ ပင်မဖွဲ့စည်းပုံနှင့် ထပ်ဆောင်းဖွဲ့စည်းမှုဖိုင်များကို တင်ပြီးပါပြီ။
  • တိုက်ရိုက်ဝင်ရောက်ကြည့်ရှုနိုင်သော အခြား PHP ဗားရှင်းများ၊ ဖြန့်ကျက်မိတ္တူဟောင်းများ သို့မဟုတ် မူရင်းပေါ်တယ်များ ရှိပါသလား။

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

4.2 ကိုရွေးချယ်ပြီး မှန်ကန်သောအပ်ဒိတ်ကို အသုံးပြုပါ။

ပုဒ်မ 3 အရ ပြင်ဆင်သည့်ဗားရှင်းကို အတည်ပြုပါ၊ ရှိပြီးသား ယုံကြည်ရသော ပက်ကေ့ဂျ်ရင်းမြစ် သို့မဟုတ် ထိန်းချုပ်ထားသော တည်ဆောက်ကွင်းဆက်ကို အသုံးပြု၍ ပိုကောင်းပါသည်။ အပ်ဒိတ်နယ်ပယ်တွင် FPM ပက်ကေ့ဂျ်၊ Apache PHP မော်ဂျူး၊ CGI ဒွိစုံ သို့မဟုတ် PHP ထည့်သွင်းထားသည့် ဝန်ဆောင်မှုတည်ဆောက်မှုကဲ့သို့သော အပ်ဒိတ်နယ်ပယ်တွင် ပါဝင်သင့်သည်။

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

4.3 ပြန်လည်စတင်ပါ သို့မဟုတ် လုပ်ဆောင်နေသည့် ဖြစ်ရပ်များကို ကျော်လိုက်ပါ။

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

mod_php အတွက်၊ module ကို လက်ခံဆောင်ရွက်ပေးနေသော Apache လုပ်ငန်းစဉ်ကို ပြန်လည်စတင်ပါ။ PHP ကို ထည့်သွင်းထားသော ဝန်ဆောင်မှုများသည် ၎င်းတို့၏ hosting လုပ်ငန်းစဉ်ကို အစားထိုးရန် လိုအပ်သည်။ FPM အတွက်၊ OPcache ကို ရှင်းလင်းခြင်းသည် runtime ကို အပ်ဒိတ်လုပ်ခြင်းနှင့် အလုပ်သမားဟောင်းများ အနားယူခြင်းကို အစားထိုးခြင်းမဟုတ်ပါ။

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

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

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

အထောက်အထားဘာသက်သေပြနိုင်မလဲ။တစ်ယောက်တည်း သက်သေမပြနိုင်ဘူး။
ပက်ကေ့ဂျ်မန်နေဂျာ သို့မဟုတ် ရုပ်ပုံမက်တာဒေတာတပ်ဆင်မှုရင်းမြစ်များနှင့် တည်ဆောက်မှုများ အပြည့်အစုံယာဉ်အသွားအလာကို ဤဥပမာသို့ ပြောင်းထားသည်။
လုပ်ငန်းစဉ်နှင့် ဖြန့်ကျက်မှုအခြေအနေအလုပ်သမား သို့မဟုတ် ကွန်တိန်နာ အစားထိုး ပြီးမြောက်သည်။ပြင်ပဝင်ပေါက်ကို ၎င်းသို့ ဖြတ်သန်းရမည်ဖြစ်သည်။
စစ်မှန်သောပေါ်တယ်မှတစ်ဆင့် ဝင်ရောက်ကြည့်ရှုသည့် ကန့်သတ်ရောဂါရှာဖွေမှုရလဒ်များအမှန်တကယ် Web SAPI နှင့် လုပ်ဆောင်နေသည့် ဖွဲ့စည်းမှုပုံစံထုတ်ဝေမှု backport သည် CVE နှစ်ခုကို အကျုံးဝင်သည်ဖြစ်စေ
ရောင်းချသူ ကြေညာချက် သို့မဟုတ် ဖာထေးမှုမှတ်တမ်း အပြည့်အစုံဤချွတ်ယွင်းချက်ပြင်ဆင်ခြင်းကို ဤတည်ဆောက်မှုတွင် ထည့်သွင်းထားသည်။ပုံတူများအားလုံးကို အသုံးပြုထားသည်။

PHP_VERSION၊ PHP_SAPI၊ တင်ထားသော ဖွဲ့စည်းမှုပုံစံဖိုင်များနှင့် အရေးပေါ်ဖွဲ့စည်းပုံများကို လက်ရှိအတွင်းပိုင်းရောဂါရှာဖွေရေးစွမ်းရည်များ သို့မဟုတ် ယာယီနှင့် ဝင်ရောက်ထိန်းချုပ်ထားသော ရောဂါရှာဖွေရေးပေါ်တယ်များမှတစ်ဆင့် စစ်ဆေးနိုင်ပါသည်။ တောင်းဆိုချက်ကို CDN သို့မဟုတ် စာမျက်နှာ cache မှ တိုက်ရိုက်ပြန်မပို့ကြောင်း သေချာပါစေ။ ပြီးသွားသောအခါတွင် ယာယီရောဂါရှာဖွေရေးဝင်ရောက်မှုကို ဖယ်ရှားပါ။

php -v သည် အများအားဖြင့် CLI binary ကို လက်ရှိ shell မှ ရွေးချယ်ထားသည်ဟုသာ ညွှန်ပြပါသည်။ php-fpm -i ကဲ့သို့သော ညွှန်ကြားချက်များသည် အသွားအလာလက်ခံသည့် လက်ရှိအလုပ်သမားကို စစ်ဆေးခြင်းနှင့် ညီမျှသည်မဟုတ်ပါ။ ပြီးပြည့်စုံသော phpinfo() စာမျက်နှာကို အများသူငှာ ကွန်ရက်သို့ အချိန်အကြာကြီး မပြပါနှင့်။

4.5 စီးပွားရေး ဆုတ်ယုတ်မှု စစ်ဆေးခြင်းနှင့် အရေးပေါ်ဆက်တင်များကို ဖယ်ရှားခြင်း။

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

memory_limit=-1 ကို ယာယီသတ်မှတ်ထားပါက၊ တရားဝင် ဖာထေးမှု စတင်အကျိုးသက်ရောက်ပြီးနောက် လုပ်ငန်းစွမ်းဆောင်ရည်နှင့် ကိုက်ညီသော အကန့်အသတ်ရှိသော ဘတ်ဂျက်ကို ပြန်လည်ရရှိပါမည်။ pm.max_requests=1 ကို သတ်မှတ်ပါက၊ ပြုပြင်မှုကို အတည်ပြုပြီးနောက် စွမ်းရည်-အကဲဖြတ်သည့် ဘဝပုံစံဖွဲ့စည်းပုံကို ပြန်လည်ရယူပါမည်။ လုပ်ငန်းလိုအပ်ချက်အရ ကန့်သတ်ချက်များနှင့် အရင်းအမြစ်ဝင်ရောက်ခွင့် ထိန်းချုပ်မှုများကို ဆက်လက်ထိန်းသိမ်းထားနိုင်သည်။

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

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

ဤကဏ္ဍသည် ထိတွေ့နိုင်မှုကို ရေတိုလျှော့ချရန် သို့မဟုတ် ရရှိနိုင်မှု တိုးတက်စေရေးအတွက် ရည်ရွယ်ပါသည်။ တိုင်းတာမှုတစ်ခုစီသည် တိကျသောလမ်းကြောင်းတစ်ခုကိုသာ အကျုံးဝင်ပြီး အတိုင်းအတာများစွာကို ပေါင်းစပ်ခြင်းသည် ပြီးပြည့်စုံသော ပြုပြင်ခြင်းနှင့် ညီမျှသည်မဟုတ်ပါ။ S1S2S3

5.1 PHP မတိုင်မီ အသွားအလာ ထိန်းချုပ်မှုများကို ဦးစားပေးလုပ်ပါ

ဝန်ဆောင်မှုက ခွင့်ပြုပါက၊ အထိခိုက်မခံသော အဆုံးအချက်များကို ယုံကြည်စိတ်ချရသော ရင်းမြစ်များသို့ ယာယီကန့်သတ်ပါ သို့မဟုတ် ဝင်ရောက်ထိန်းချုပ်မှုကို PHP မတိုင်မီ တွန်းအားပေးပါ။ အပ်လုဒ်လုပ်သောအလုပ်အတွက်၊ တောင်းဆိုချက်-ကိုယ်ထည်အရွယ်အစား၊ အကွက်အရေအတွက်၊ အစိတ်အပိုင်းအရေအတွက်၊ တစ်စိတ်တစ်ပိုင်းအလိုက် ခေါင်းစီးများနှင့် အသိုက်အတိမ်အနက်ကို ကန့်သတ်ပါ။ Multipart မလိုအပ်သောဝန်ဆောင်မှုများသည် ရှေ့တန်းတွင် ၎င်းကိုငြင်းပယ်နိုင်သည်။ S2

ဤကန့်သတ်ချက်များသည် PHP သို့ဝင်ပေါက်များအားလုံးအကျုံးဝင်မည်ဖြစ်သည်။ “အပ်လုဒ်” ဟု အမည်ပေးထားသည့် URL ကို ကြားဖြတ်မှသာလျှင် တောင်းဆိုချက်ကိုယ်ထည်ရှိ PHP မှ အလိုအလျောက် ခွဲခြမ်းစိတ်ဖြာဆဲဖြစ်သော အခြားအရာများကို လွတ်သွားပါမည်။ အတုံးလိုက်အပြောင်းအရွှေ့များ၊ ကြေငြာထားသော အရှည်မရှိခြင်း အစရှိသည့် ကိစ္စများအတွက်၊ ကန့်သတ်ချက်သည် အမှန်တကယ်ဖတ်သည့်အရွယ်အစားပေါ်တွင် အခြေခံသင့်ပါသည်။ အပလီကေးရှင်းသည် အကြောင်းအရာကို ထပ်ချုံ့ခြင်း သို့မဟုတ် ချဲ့ထွင်သည့်အခါတွင်လည်း ၎င်း၏ကိုယ်ပိုင် output size budget ရှိသင့်သည်။

5.2 FPM pool ဖွဲ့စည်းမှုပုံစံ နမူနာ

အောက်ဖော်ပြပါ setting များကို အဆိုပါနေရာတွင်ထားပါ။ FPM pool တောင်းဆိုချက်များကို အမှန်တကယ်ဆောင်ရွက်ပေးသော ဖွဲ့စည်းမှုအပိုင်း စကားအသုံးအနှုန်း မဟုတ်ပါ။ php.ini . 8M နှင့် 4M တန်ဖိုးများသည် အလုပ်ချိန်အတွက် ချိန်ညှိရန် ဥပမာများဖြစ်သည်။ တစ်ခုလုံးကို ကန့်သတ်လိုက်သောအခါ ဖောင်အကွက်များနှင့် အပိုင်းလိုက်ဘောင်များအတွက် အခန်းချန်ထားပါ။ POST တောင်းဆိုချက်။ S11 S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

PHP 8.5 သာလျှင်၊ အပေါင်း-

php_admin_flag[fatal_error_backtraces] = off

တစ်ခုစီ၏ လုပ်ငန်းဆောင်တာများနှင့် နယ်နိမိတ်များမှာ အောက်ပါအတိုင်းဖြစ်သည်။

ဖွဲ့စည်းမှုမျှော်လင့်ထားသောအကျိုးသက်ရောက်မှုထိန်းသိမ်းထားရမည့် ကန့်သတ်ချက်များ ဖော်ပြချက်
memory_limit=-1ကြိုတင်မှန်းဆနိုင်သော PHP တောင်းဆိုချက် မမ်မိုရီအပေါ်ပိုင်းကန့်သတ်မှုအခြေအနေအား ဖယ်ရှားပါ။အရင်းခံခွဲဝေမှု ပျက်ကွက်မှုကို တားဆီးမထားပေ။ မူလဘတ်ဂျက်ကို ပယ်ဖျက်ခြင်းသည် မှတ်ဉာဏ်ကုန်ခန်းမှုနှင့် ဝန်ဆောင်မှုပြတ်တောက်မှုအန္တရာယ်ကို တိုးစေနိုင်သည်။
ပိုသေး post_max_sizeခွဲခြမ်းစိတ်ဖြာခြင်းလုပ်ငန်းစဉ်တွင် ဝင်ရောက်လာသော ဒေတာအရွယ်အစားကို လျှော့ချပါ။မပြင်ဆင်ထားသော parser သည် ကွာဟမှုကို သိထားသည်။ မှတ်ဉာဏ်ချဲ့ထွင်ခြင်းကို လွတ်လပ်စွာ တားဆီး၍မရပါ။
upload_max_filesize < post_max_sizeဖိုင်အရွယ်အစား တစ်ခုတည်းကို ကန့်သတ်ပြီး overhead တောင်းဆိုမှုနေရာလွတ်အကွက်များ၊ မက်တာဒေတာ သို့မဟုတ် အက်ပ်အတွင်း ခွဲဝေချထားမှုများကို ကန့်သတ်မထားပါ။
အပ်လုဒ်တိုးတက်မှုကို ပိတ်ပါ။အတည်ပြုထားသော စက်ရှင်နှင့်သက်ဆိုင်သည့်လမ်းကြောင်းကို ပိတ်ပါ။အခြားသော ကမ္ဘာလုံးဆိုင်ရာ ပြည်နယ်မူကွဲများကို အကျုံးမဝင်ပါ။
PHP 8.5 အနီးကပ် fatal backtraceအတည်ပြုထားသော ဆက်စပ်အခြေအနေ ထုတ်လုပ်သူများကို ပိတ်ပါ။session ကဲ့သို့သော အခြားလမ်းကြောင်းများကို အကျုံးမဝင်ပါ။

တိုင်းတာရေးနယ်နိမိတ်များသည် တရားဝင်ထုတ်ပြန်ကြေငြာချက်မှ ဆင်းသက်လာသည်။ pool syntax နှင့် management-level configuration semantics အတွက် PHP manual ကို ကြည့်ပါ။ S1S2S3S11

စီမံခန့်ခွဲမှုအဆင့် php_admin_* ဆက်တင်များကို ini_set() မှတစ်ဆင့် အပလီကေးရှင်းများမှ လွှမ်းမိုး၍မရပါ။ အမှန်တကယ်တောင်းဆိုမှုများရှိ တန်ဖိုးများသည် မျှော်လင့်ထားသည့်အတိုင်းဖြစ်ကြောင်း အတည်ပြုရန် ပေါင်းကူး၊ လမ်းညွှန်အဆင့်နှင့် ရှေ့ဆုံးအဝင်ဖွဲ့စည်းပုံများအားလုံးကို ပြန်လည်သုံးသပ်သင့်ပါသည်။ ပြုပြင်မွမ်းမံပြီးနောက်၊ လက်ရှိအခြေအနေဟောင်းကို ဆက်လက်မထိန်းသိမ်းနိုင်စေရန် လုပ်သားအားလုံးကို ပြန်လည်တည်ဆောက်ပါ။

php.ini ကို တိုက်ရိုက်မွမ်းမံရန် သင်ရွေးချယ်ပါက၊ syntax ကို ပြောင်းလဲသင့်သည်-

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

ရေကူးကန်တွင် php_admin_value နှင့်မတူဘဲ၊ memory_limit=-1 တွင် php.ini သတ်မှတ်ရုံမျှဖြင့် အက်ပ်အား ၎င်းအား ထပ်မံမွမ်းမံခြင်းမှ မတားဆီးနိုင်ပါ။ မူဘောင်၊ အပလီကေးရှင်းကုဒ်နှင့် အခြားဖွဲ့စည်းပုံများသည် ၎င်းတို့ကန့်သတ်ထားသောတန်ဖိုးကို ပြန်လည်သတ်မှတ်ထားခြင်းရှိမရှိ စစ်ဆေးသင့်သည်။ ပြဋ္ဌာန်းရန်လိုအပ်သည့်အခါ၊ လက်ရှိ SAPI အတွက် သင့်လျော်သော စီမံခန့်ခွဲမှုအဆင့်ဆက်တင်များကို အသုံးပြုပြီး အမှန်တကယ်ထိရောက်သောတန်ဖိုးကို စစ်ဆေးပါ။ S11S12

fatal_error_backtraces = Off ကို PHP 8.5 အတွက်သာ ထည့်ပါ။ အပလီကေးရှင်းအဆင့် ini_set() ကို ခွဲခြမ်းစိတ်ဖြာခြင်းမတောင်းဆိုမီ ထိရောက်မှုရှိစေရန် FPM .user.ini အား အပ်လုဒ်တိုးတက်မှုကို ပိတ်ရန်အတွက် ဖြေရှင်းချက်အဖြစ် အသုံးမပြုပါနှင့်။ S1S3

5.3 PHP မမ်မိုရီကန့်သတ်ချက်များကို ဖယ်ရှားခြင်းကုန်ကျစရိတ်ကို စီမံခန့်ခွဲပါ

memory_limit=-1 သည် ပြုပြင်မထားသော ပတ်ဝန်းကျင်များအတွက် ယာယီလမ်းကြောင်း လျော့ပါးသက်သာစေခြင်းဖြစ်ပြီး ရေရှည်ပုံသေပုံစံဖွဲ့စည်းမှုအဖြစ် ကူးယူခြင်းမပြုသင့်ပါ။ အပလီကေးရှင်းတစ်ခု သို့မဟုတ် တောင်းဆိုချက်တစ်ခု ထိန်းချုပ်မှုမရှိတော့သည့်အခါ၊ ၎င်းသည် လက်ခံသူ၏မှတ်ဉာဏ်ကို ပိုမိုအသုံးပြုနိုင်သည်။ ထို့ကြောင့်၊ အသုံးမပြုမီ၊ တူညီသောငွေကြေးပမာဏ၊ တစ်ဦးတည်းလုပ်သားအများဆုံးနှင့် စုစုပေါင်းဝန်ဆောင်မှုစွမ်းရည်တို့ကို အကဲဖြတ်ပြီး ရှေ့ဆုံးထည့်သွင်းမှုကန့်သတ်ချက်များကို အသုံးချသင့်သည်။ S2

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

အထက်ဖော်ပြပါ နည်းဗျူဟာများကို RLIMIT_AS၊ RLIMIT_DATA၊ သို့မဟုတ် သက်ဆိုင်ရာ လုပ်ငန်းစဉ်လိပ်စာနေရာ ကန့်သတ်ချက်များဖြင့် အစားထိုးခြင်းမပြုပါနှင့်။ ၎င်းတို့သည် ပြဿနာရှိဆဲ OOM လမ်းကြောင်းသို့ အရင်းခံခွဲဝေမှုကို တိုက်ရိုက်ဖြစ်စေနိုင်သည်။ S2

5.4 Nginx ဖွဲ့စည်းမှုပုံစံ နမူနာ

Nginx မှ တောင်းဆိုချက်များကို PHP-FPM သို့ ထပ်ဆင့်ပေးပို့သည့်နေရာတွင် ဖြန့်ကျက်အသုံးပြုနိုင်ပါသည်။ အမှန်တကယ် hosting ဝန်ဆောင်မှု၏ configuration အဆင့်တွင် ၎င်းကို သတ်မှတ်နိုင်သည်။

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size သည် တောင်းဆိုချက်ကိုယ်ထည်အရွယ်အစားကို ကန့်သတ်ထားသည်။ fastcgi_request_buffering on သည် Nginx အပြည့်အစုံကို တောင်းဆိုချက်ကိုယ်ထည်ကို ဦးစွာဖတ်ပြီး FastCGI နောက်ခံသို့ ပေးပို့နိုင်စေပါသည်။ အချို့သော server သို့မဟုတ် location တွင် အကျိုးသက်ရောက်မှုရှိမရှိ ရှိပြီးသား အမွေဆက်ခံမှုနှင့် အကျုံးဝင်သော ဆက်ဆံရေးများနှင့် တွဲဖက်စစ်ဆေးရန် လိုအပ်သည်။ S13S14

On လုပ်ငန်းသည် multipart မလိုအပ်သည့်အခါတွင်၊ သက်ဆိုင်ရာဝန်ဆောင်မှုဝင်ပေါက်တွင် ငြင်းပယ်ခြင်းစည်းမျဉ်းကို သင်ထည့်သွင်းနိုင်သည်-

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

ဤသည်မှာ if နှင့် return ကိုအသုံးပြုထားသော ရိုးရှင်းသောဝင်ရောက်မှုကန့်သတ်သည့်ပုံစံပလိတ်ဖြစ်ပြီး၊ ခွဲခြမ်းစိတ်ဖြာမှုအားနည်းချက်များအတွက် ယေဘုယျစစ်ထုတ်ခြင်းစည်းမျဉ်းမဟုတ်ပါ။ ဖြန့်ကျက်ခြင်းမပြုမီ ဖွဲ့စည်းမှုစနစ်ဆိုင်ရာ အထားအသိုနှင့် ပုံမှန်တောင်းဆိုချက်များကို စစ်ဆေးအတည်ပြုပြီး စိတ်ကြိုက် error_page သည် 403 တောင်းဆိုမှုများကို PHP သို့ ပြန်ညွှန်းခြင်းရှိမရှိ စစ်ဆေးပါ။ စာကြောင်းတွဲဖက်ခြင်းသည် ခွဲခြမ်းစိတ်ဖြာမှုကွဲပြားမှုအားလုံးအတွက် အာမခံချက်မပြည့်စုံပါ။ S15

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

5.5 ရွေးချယ်နိုင်သော လျော့ပါးရေး- FPM အလုပ်သမားတစ်ဦးအတွက် တောင်းဆိုချက်တစ်ခု

FPM တွင် ငွေကြေးပိုတတ်နိုင်သော ဖြန့်ကျက်မှုများအတွက်၊ ရေတိုထည့်သွင်းမှုများကို အကဲဖြတ်နိုင်သည်-

pm.max_requests = 1

ရှိပြီးသား အလုပ်သမားကို ပြန်လည်တည်ဆောက်ပါ။ ၎င်းသည် အလုပ်သမားပြန်လည်အသုံးပြုသည့်အဆင့်တွင် ဖော်ပြထားသည့် အပြန်အလှန်တောင်းဆိုမှုကွင်းဆက်ကို ပိတ်ဆို့ထားသော်လည်း လုပ်ငန်းစဉ်ဖန်တီးမှုနှင့် ကနဦးအစပြုမှုကို တိုးမြှင့်ပေးမည်ဖြစ်သည်။ တစ်ချိန်တည်းမှာပင် OOM နှင့် CVE-2026-109618 ၏ ရှင်းလင်းရေးပြဿနာများကို ပြုပြင်၍မရပါ။ တန်ဖိုးသည် ငယ်သော်လည်း 1 ထက်ကြီးသောအခါ၊ ပြန်သုံးရန် တောင်းဆိုချက် window တစ်ခုရှိသေးသည်။ S3S11

5.6 WAF နှင့် Cloudflare လွှမ်းခြုံကန့်သတ်ချက်များ

Cloudflare သည် Free အစီအစဉ် အပါအဝင် PHP2Shell ကို ကာကွယ်ရန်အတွက် ဖြန့်ကျက်မှု အစီအစဉ်များကို ကြေညာထားသည်။ ၎င်း၏ဝန်ဆောင်မှုများကိုအသုံးပြုသည့်အခါ၊ အမှန်တကယ်အသွားအလာများသည် proxy မှတဆင့်ဖြတ်သန်းခြင်းရှိ၊ အခပေးအစီအစဥ်များအတွက်၊ သက်ဆိုင်ရာ စီမံခန့်ခွဲထားသော စည်းမျဥ်းများ၏ ဖွဲ့စည်းပုံနှင့် ခြွင်းချက်များကိုလည်း စစ်ဆေးရန် လိုအပ်ပါသည်။ S16

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

5.7 အဘယ်ကြောင့် ဘုံအတိုင်းအတာများ မလုံလောက်သနည်း။

အစီအမံများ သို့မဟုတ် စီရင်ချက်များချို့ယွင်းချက်များ
file_uploads ကိုသာ ပိတ်ပါ။ကဏ္ဍစုံလုပ်ဆောင်ခြင်းအားလုံးကို အကျုံးဝင်ပြီး ၎င်း၏ကိုယ်ပိုင် OOM လမ်းကြောင်းကို အသုံးပြု၍မရပါ။
enable_post_data_reading=Off သတ်မှတ်ခြင်း။POST/FILES အလိုအလျောက်ဖြည့်ခြင်း၏အပြုအမူကိုပြောင်းလဲပါ။ တောင်းဆိုချက်ကိုယ်ထည်ကို အပလီကေးရှင်းမှ ဖတ်ရှုနိုင်ပြီး ပုံမှန်လုပ်ငန်းကို အနှောင့်အယှက်ဖြစ်စေနိုင်သည်။
အမှားအယွင်းပြသမှုကို ပိတ်ပါ၊ မှတ်တမ်း သို့မဟုတ် @ ကို အသုံးပြုပါ။အတွင်းပိုင်းရောဂါရှာဖွေရေးလုပ်ဆောင်ခြင်းသည် dangling အခြေအနေသို့ ဝင်ရောက်နိုင်သေးသည်။
လုပ်သားအရေအတွက်ကို တိုးမြှင့်ပါ။လုံခြုံသောပြည်နယ်ရှင်းလင်းရေးယန္တရားကို မထူထောင်ပါနှင့်၊ အလုပ်သမားတစ်ဦးတည်းကို ပြန်လည်အသုံးပြုခြင်းကို မဖယ်ရှားပါနှင့်
disable_functions သို့မဟုတ် open_basedir ကိုသာ စီစဉ်သတ်မှတ်ပါဤကန့်သတ်ချက်များသည် C အင်ဂျင်အလွှာမှတ်ဉာဏ် ပျက်စီးမှုကို မဖြေရှင်းနိုင်ပါ။
ဗားရှင်းတစ်ခု သို့မဟုတ် ကော်ပီတစ်ခုတည်းကို တစ်ကြိမ်သာ စစ်ဆေးပါ။ဝင်ပေါက်များနှင့် လည်ပတ်နေသည့် ဖြစ်ရပ်များအားလုံးကို အစားထိုးထားကြောင်း သက်သေမပြနိုင်ပါ။
ခြွင်းချက်မှတ်တမ်းများကို မတွေ့ရတော့ပါ။အားနည်းချက်ရှိမရှိ သို့မဟုတ် ၎င်းကို ယခင်က အသုံးချခြင်းမပြုကြောင်း သက်သေမပြနိုင်ပါ။

၎င်းတို့အနက် PHP ၏ဖွဲ့စည်းပုံနှင့် အားနည်းချက်ယန္တရားအခြေခံကို S2S3S12 တွင် တွေ့ရှိနိုင်သည်။ အကျုံးဝင်မှု၊ လက်ခံမှုနှင့် ခွင့်ပြုချက်နယ်နိမိတ်များဆိုင်ရာ စီရင်ဆုံးဖြတ်ချက်များကို ဤယန္တရားများက တင်ပြသည့် အကောင်အထည်ဖော်မှု အကြံပြုချက်များအပေါ် အခြေခံထားသည်။

6. တရားဝင် ဖာထေးမှု၏ အကောင်အထည်ဖော်မှု အတွေးအခေါ်များနှင့် သုံးသပ်ချက် အမှတ်များ

6.1 မှန်ကန်သောဌာနခွဲအတွက် အပြီးသတ်ပြင်ဆင်မှုများကို အသုံးပြုပါ။

PHP 8.5 အတွက် ကိုယ်စားလှယ်တရားဝင်တင်ပြချက်မှာ-

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

ကတိကဝတ်သည် OOM ထွက်ပေါက်ယန္တရားကို ချိန်ညှိရန်နှင့် ကနဦးအဆင့်အတွင်း ဝင်ရောက်နိုင်သည့် ကမ္ဘာလုံးဆိုင်ရာအခြေအနေကို ပြင်ဆင်ရန် နှစ်ခုစလုံး CVEs နှစ်ခုလုံးကို အတိအလင်း ချိတ်ဆက်ထားသည်။ S4S5 တွင် ကွဲပြားမှု အပြည့်အစုံဖြင့် စာမျက်နှာကို တင်ပြပါ။ အခြားဌာနခွဲများသည် ၎င်းတို့၏တရားဝင်လုံခြုံရေးထုတ်ပြန်မှုများ သို့မဟုတ် ကိုက်ညီသည့်ပြင်ဆင်ဖာထေးမှုများကို အသုံးပြုသင့်ပြီး 8.5 သို့ အပြောင်းအလဲများကို မည်သည့်အဟောင်းဗားရှင်းနှင့်မဆို တိုက်ရိုက်အသုံးပြုနိုင်သည်ဟု ယူဆမရနိုင်ပါ။

6.2 OOM ပြုပြင်ခြင်း- စီမံဆောင်ရွက်နိုင်သော အခြေအနေအား ဦးစွာ ပြန်လည်ရယူပါ၊ ထို့နောက် တောင်းဆိုချက်ကို အဆုံးသတ်ပါ

တရားဝင်အကောင်အထည်ဖော်မှုသည် ပျော့ပျောင်းသော OOM လုပ်ဆောင်ခြင်း၏ အဆင့်နှစ်ဆင့်ကို မိတ်ဆက်ပေးသည်- ပျော့ပျောင်းသောကန့်သတ်ချက်သို့ရောက်ရှိသောအခါ၊ ဆိုင်းငံ့ထားသည့်အခြေအနေကို မှတ်တမ်းတင်ပြီး VM ကဲ့သို့သော ဘေးကင်းသောနေရာတွင် ထိန်းချုပ်ထားသော ထွက်ပေါက်ကို လုပ်ဆောင်သည်။ မအောင်မြင်နိုင်သော ခွဲဝေသုံးစွဲမှု အင်တာဖေ့စ်သည် ခေါ်ဆိုသူကို ရှုံးနိမ့်မှုကို ပြတ်သားစွာ ကိုင်တွယ်ရန် ခွင့်ပြုသည်။ တိုက်ရိုက်ပြန်မရနိုင်သော ခွဲဝေမှုများအတွက်၊ ပိုမိုမြင့်မားသော hard threshold ကိုကျော်လွန်ရန်မျှော်လင့်ထားပါက၊ မလုံခြုံသောအလယ်အလတ်အခြေအနေတွင် တောင်းဆိုမှုများကို ဆက်လက်လုပ်ဆောင်ခြင်းမှရှောင်ကြဉ်ရန် လုပ်ငန်းစဉ်ကို တိုက်ရိုက်ရပ်ဆိုင်းမည်ဖြစ်သည်။ S2S5

အောက်ပါတို့သည် ဆိုင်းငံ့ထားသော OOM ကို အမှတ်အသားပြုရန် အသုံးပြုသည့် 8.5 ကွာခြားချက်ရှိ သော့ကုဒ်၏ ကောက်နုတ်ချက်ဖြစ်သည်။

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

VM ကိုင်တွယ်ခြင်းနှင့် အခြားဘေးကင်းသောနေရာများကို အနှောင့်အယှက်ပေးပြီးနောက် zend_handle_delayed_oom() သို့ ဖုန်းခေါ်ဆိုပါ။ ၎င်း၏အသုံးပြုသူကုဒ် အကောင်အထည်ဖော်မှုအကြောင်းအရာသည် ထိန်းချုပ်ထားသော unwind လမ်းကြောင်းကို အသုံးပြုသည်။ ခက်ခဲသော OOM လမ်းကြောင်းသည် _exit(137) ဟုခေါ်သည်။ S5

ဒီဇိုင်းရှုထောင့်မှနေ၍ အရေးကြီးသောပြောင်းလဲမှုများမှာ- avoids သည် တည်ဆောက်ပုံအလယ်အလတ်အခြေအနေတွင်ရှိနေသောအခါ C ခေါ်ဆိုမှု stack ကို မထင်သလိုဖြတ်ကျော်ကာ ပြည်နယ်ကန့်သတ်ချက်များကိုထိန်းထားနိုင်သော တွင် ထွက်ပေါက်ကို နေရာချပေးသည်။ ပျော့ပျောင်းသောကန့်သတ်ချက်ကို အစပျိုးပြီးနောက်၊ လုပ်ငန်းစဉ်ကို အပြီးသတ်ရန် အပိုမှတ်ဉာဏ် လိုအပ်နိုင်သည်၊ ထို့ကြောင့် Soft threshold အသစ်သည် လုပ်ငန်းစဉ်၏ စုစုပေါင်းမှတ်ဉာဏ်အတွက် လုံးဝအထက်ကန့်သတ်ချက်အဖြစ် နားမလည်နိုင်ပါ။

“PHP သည် zend_bailout() အားလုံးကို ဖျက်ထားသည်” ဟုလည်း အကျဉ်းချုံး၍မရပါ။ patch သည် သီးခြားအခြေအနေများတွင် သက်ဆိုင်ရာ ယန္တရားများကို အသုံးပြုဆဲဖြစ်သည်။ သတ်မှတ်ထားသောအချက်မှာ အန္တရာယ်ရှိသော ထွက်ပေါက်အချိန်နှင့် ပူးတွဲပါရှိသော နိုင်ငံတော် စီမံခန့်ခွဲမှုဖြစ်သည်။ S5

6.3 ခွဲဝေခေါ်ဆိုသူများနှင့် အစိတ်အပိုင်းများစွာကို အတူတကွ ခွဲခြမ်းစိတ်ဖြာခြင်းကို အပ်ဒိတ်လုပ်ပါ။

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

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

၎င်းတို့၏ကိုယ်ပိုင်အကိုင်းအခက်များကိုထိန်းသိမ်းထားသည့်အသင်းများအတွက်၊ အောက်ပါပြဿနာများသည် ကုဒ်ပြန်လည်သုံးသပ်ခြင်း၏ အဓိကအချက်ဖြစ်ကြောင်း အကြံပြုအပ်ပါသည်။

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

ဤအရာများသည် ပြင်ဆင်မှုယန္တရားအပေါ် အခြေခံ၍ အကျဉ်းချုံးထားသော သုံးသပ်ချက်မေးခွန်းများဖြစ်ပြီး ပံ့ပိုးမထားသောကုဒ်အခြေခံအတွက် ပြီးမြောက်ခဲ့သော စာရင်းစစ်၏နိဂုံးမဟုတ်ပေ။

6.4 Cross-request fix- အစောပိုင်းတွင် အစပြုခြင်း၊ နောက်ဆုံး ရှင်းလင်းခြင်း နောက်ပိုင်း

CVE-2026-109619 နှင့် သက်ဆိုင်သော patch သည် တစ်ချိန်တည်းတွင် ဘဝသံသရာနယ်နိမိတ်များကို ချိန်ညှိပေးပါသည်။ အောက်တွင်ဖော်ပြထားသော ဖိုင်များနှင့် လုပ်ဆောင်ချက်များသည် PHP 8.5 တရားဝင်ကွဲပြားမှုကို နမူနာအဖြစ် ယူဆောင်သည်။ S5

တည်နေရာဦးတည်ချက်ပြောင်းပါ။ပြဿနာဖြေရှင်းပြီးပြီ။
Zend/zend_execute_API.c စသည်တို့အမှားအယွင်းများ၊ ခြွင်းချက်များ၊ ကိုင်တွယ်သူများ၊ အရာဝတ္ထုများ စသည်တို့ကဲ့သို့သော executor အခြေအနေကို ပြန်လည်သတ်မှတ်ပါ။တောင်းဆိုမှု ပြီးဆုံးပြီးနောက်၊ နောက်တောင်းဆိုမှုဖြင့် ဝင်ရောက်နိုင်သော ရည်ညွှန်းဟောင်းများ ရှိပါသေးသည်။
main/main.c ၏ စတင်ခြင်းလမ်းကြောင်းSAPI မဖွင့်ခင် php_basic_early_rinit() ကို ခေါ်ပါအစောပိုင်းစားသုံးသူ ပေါ်ပေါက်လာသောအခါ သက်ဆိုင်ရာ အရင်းခံအခြေအနေကို အစပျိုးမရသေးပါ။
main/main.c ၏လမ်းကြောင်းပိတ်HTTP globals ကို ဖျက်ဆီးပြီး သတ်မှတ်မထားသော အဖြစ် အမှတ်အသားပြုပါ။ထုတ်လွှတ်သည့်တန်ဖိုးကို မှန်ကန်သည့်အရာတစ်ခုအဖြစ် သတ်မှတ်ဆဲဖြစ်သည်။
တောင်းဆိုမှုအစုကို နောက်ဆုံးမလွတ်မြောက်မီနောက်ဆုံး error message ကို ထပ်မံရှင်းလင်းပါ။နောက်ကျ ရှင်းလင်းခြင်း အဖြေရှာခြင်းများသည် အမှားအယွင်း အခြေအနေကို ပြန်လည်ဖြည့်သွင်းသည်။
ext/session/session.cအပ်လုဒ်တိုးတက်မှု အစောပိုင်း လမ်းကြောင်းကို စတင်လုပ်ဆောင်သည် ပထမဦးဆုံး session globals ဖြစ်သည်။ပုံမှန် module RINIT ယခင်က အခြေအနေဟောင်းကို ဝင်ရောက်ခဲ့သည်။
Serialization ဆက်စပ်ကုဒ်အစောပိုင်းလုပ်ဆောင်ခြင်းတွင် အတန်းခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် အသုံးပြုသူပြန်ခေါ်မှုများကို ကန့်သတ်ပါ။စတင်ခြင်း မပြီးမြောက်သောအခါတွင် နောက်ထပ် အသုံးပြုသူကုဒ်ကို လုပ်ဆောင်ပါ။

ဥပမာအားဖြင့်၊ startup sequence တွင်-

zend_activate();
php_basic_early_rinit();
sapi_activate();

HTTP globals ဖျက်ဆီးပြီးနောက်၊ အခြေအနေပျက်ကွက်အမှတ်အသားကို ထည့်ပါ။

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

ဤကောက်နှုတ်ချက်များသည် အခြေခံသဘောတရားနှစ်ရပ်ကို ဖော်ပြသည်- initialize အစောဆုံးဖြစ်နိုင်ချေရှိသော စားသုံးသူများရှေ့မှောက်တွင် လုပ်ဆောင်ပြီး အခြေအနေအား ပြန်လည်ဖန်တီးနိုင်သည့် နောက်ဆုံးလုပ်ဆောင်မှုအပြီးတွင် နောက်ဆုံးသန့်ရှင်းရေးလုပ်ဆောင်ပါ။ ညွှန်ပြချက်ကို ပြန်လည်သတ်မှတ်ခြင်းသည် ပုံမှန် RINIT သို့မဟုတ် အစောပိုင်းပိတ်သွားသည့်အဆင့်တွင်သာ စောစီးစွာအသုံးပြုခွင့်လွတ်သွားနိုင်သည်။ S5

6.5 သင့်ကိုယ်ပိုင် “လိုင်းပြုပြင်ခြင်း” ပြုလုပ်ရန် အဘယ်ကြောင့် မအကြံပြုသနည်း။

zend_bailout() အားလုံးကို _exit() ဖြင့် အစားထိုးခြင်း သို့မဟုတ် အချို့သော entry တွင် null pointer check ကိုထည့်ခြင်းဖြင့် မတူညီသော execution contexts အများအပြားကို ချဲ့ထွင်နိုင်မည်ဖြစ်ပါသည်။ ၎င်းတို့သည် အခြားအခြေအနေအကွက်များကို ချန်လှပ်ထားနိုင်သည် သို့မဟုတ် ၎င်းတို့သည် ဖျက်ဆီးခြင်း၊ တိုးချဲ့ခေါ်ဆိုမှုများ၊ လက်ခံဆောင်ရွက်ပေးခြင်းနှင့် အဆုံးသတ်ခြင်းဆိုင်ရာ ဝေါဟာရများကို တောင်းဆိုခြင်းများ ပြောင်းလဲနိုင်သည်။

ပံ့ပိုးထားသော ဗားရှင်းများအတွက်၊ ထွက်ရှိပြီးသော ပြင်ဆင်မှုများ အပြည့်အစုံသည် ဦးစားပေးဖြစ်သည်။ ကိုယ်ပိုင်အကိုင်းအခက်များ ပြောင်းရွှေ့ခြင်းသည် ဖာထေးမှု၏ရင်းမြစ်၊ သက်ဆိုင်သော အခြေခံအချက်များ၊ ပဋိပက္ခကိုင်တွယ်ခြင်းနှင့် အမူအကျင့်ပြောင်းလဲမှုများကို မှတ်တမ်းတင်ထားသင့်ပြီး သက်ဆိုင်ရာ ရေစီးကြောင်း ဆုတ်ယုတ်မှုအသုံးပြုမှု ကိစ္စများကို အသုံးပြုခြင်းနှင့် ဤလုပ်ငန်းလုပ်ငန်းစဉ်ကို အတည်ပြုခြင်းတို့ကို ပြုလုပ်သင့်သည်။ ဤနေရာတွင် အကြံပြုချက်များသည် ခွဲဝေပေးသူ၊ VM၊ စက်ရှင်နှင့် ဘဝသံသရာ အပြောင်းအလဲများကို တောင်းဆိုသည့်အပိုင်းကို ခွဲခြမ်းစိတ်ဖြာခြင်းမှ လာပါသည်။ S4S5

7. PHP 7.4၊ 8.0၊ 8.1 ၏ အရေးပေါ်နောက်ပြန်ပို့တ်

PHP သည် ပြင်းထန်မှုအပေါ်အခြေခံ၍ အကိုင်းအခက်ဟောင်းသုံးခု၏ အနိမ့်ဆုံးအရင်းအမြစ်ကုဒ်နောက်ကြောင်းပြန်ပို့မှုကို တရားဝင်ပေးဆောင်ပါသည်။ ဌာနခွဲအမည်များမှာ-

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

ဌာနခွဲလင့်ခ်များအတွက် S7S8S9 ကိုကြည့်ပါ။ ၎င်းတို့သည် ဤအားနည်းချက်အတွက် အရေးပေါ်ပေးပို့မှုများဖြစ်ပြီး ဌာနခွဲဟောင်းအတွက် ပုံမှန်အထက်ပိုင်းပံ့ပိုးမှုသို့ ပြန်သွားရန် ကိုယ်စားမပြုသည့်အပြင် ၎င်းတို့သည် အခြားလုံခြုံရေးအပ်ဒိတ်များကို အစားမထိုးပါ။ S1

7.1 PHP 8.1 backport ကို နမူနာအဖြစ် ယူပါ

PHP 8.1 အတွက် သက်ဆိုင်ရာ တင်ပြချက်များမှာ-

1d7dec178a094e6e75b229ce22754045f8c6070a

၎င်း၏ဗျူဟာသည် ပျက်ကွက်မှုကို မြန်ဆန်စေသည်- သက်ဆိုင်ရာ OOM လမ်းကြောင်းတွင် ရောဂါရှာဖွေမှုများကို ထုတ်ပေးပြီးနောက် _exit(1) ဟုခေါ်ကာ၊ ကမ္ဘာလုံးဆိုင်ရာ အခြေအနေနှင့် အခြားသက်ဆိုင်ရာ ပြင်ဆင်မှုများ အပါအဝင်၊ စက်ရှင် အပ်လုဒ် တိုးတက်မှု၏ သက်ဆိုင်ရာ စီမံဆောင်ရွက်မှုကို စက်တွင်း၌ ပိတ်နေစဉ်။ သက်ဆိုင်ရာ ရင်းမြစ်ကုဒ် တင်ပြမှုအတွက်၊ S6 ကို ကြည့်ပါ။

၎င်းသည် ပံ့ပိုးထားသော ဌာနခွဲရှိ ပိုမိုပြီးပြည့်စုံသော နှောင့်နှေးနေသည့် OOM ဒီဇိုင်းနှင့် အပြုအမူဆိုင်ရာ ကွာခြားချက်ဖြစ်သည်။ အပ်လုဒ်တိုးတက်မှုကို ဖွင့်ထားဆဲဖြစ်ကြောင်း ဖွဲ့စည်းမှုပုံစံက ပြသနေဆဲဖြစ်သောကြောင့်၊ ဤ backport ပြီးနောက် အတွင်းပိုင်းလုပ်ဆောင်ခြင်းအမူအကျင့်သည် ပြောင်းလဲမည်မဟုတ်ကြောင်း မဆိုလိုပါ။

7.2 အသုံးပြုသည့်အခါ သင်လက်ခံရမည့်စျေးနှုန်း

လုပ်ငန်းစဉ်ကို တိုက်ရိုက်ထွက်ခြင်းသည် လက်ရှိတောင်းဆိုချက်အား ကျရှုံးစေသည်၊ ပုံမှန် PHP ခေါ်ဆိုမှုပိတ်ခြင်းနှင့် အပလီကေးရှင်းပိတ်ခြင်းအပိုင်းကို ကျော်သွားခြင်း၊ အကယ်၍ host သည် thread model တစ်ခုကို လက်ခံပါက၊ အခြားသော concurrent work တွင် host process exit တစ်ခုလုံး၏ အကျိုးသက်ရောက်မှုကို အကဲဖြတ်ရန်လည်း လိုအပ်ပါသည်။ လုပ်ငန်းစဉ်မန်နေဂျာသည် အစားထိုးခြင်းလုပ်ငန်းစဉ်ကို အချိန်မီဆွဲနိုင်သည်ရှိမရှိ စိစစ်ခြင်းတွင် ထည့်သွင်းသင့်သည်။

ထို့ကြောင့်၊ ဗားရှင်းအဟောင်းအသုံးပြုသူများသည် အစဉ်လိုက်စဉ်းစားသင့်သည်-

  1. ပံ့ပိုးထားသော PHP ဌာနခွဲနှင့် ၎င်း၏ ပုံသေဗားရှင်းသို့ ပြောင်းရွှေ့ပါ။
  2. CVE သို့မဟုတ် LTS ထုတ်လုပ်သူ အပ်ဒိတ် နှစ်မျိုးလုံးကို အတိအလင်း အကျုံးဝင်သည့် ထုတ်ဝေမှုကို အသုံးပြုပါ။
  3. အကယ်၍ ၎င်းသည် အရင်းအမြစ်ကုဒ်၏ ဗားရှင်းဟောင်းနှင့် အမှန်တကယ် သက်ဆိုင်ပါက၊ ပြီးပြည့်စုံသော အပြောင်းအလဲများနှင့် လိုက်ဖက်ညီမှုကို အတည်ပြုရန် ကိုက်ညီသော ဗားရှင်း၏ တရားဝင် အရေးပေါ် နောက်ခံကို အသုံးပြု၍ နောက်ဆက်တွဲ ပြောင်းရွှေ့မှုကို စီစဉ်ပါ။

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

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

ဤပြုပြင်မှုပြီးမြောက်ရန်အတွက် အောက်ပါရလဒ်များကို အသုံးပြုရန် အကြံပြုအပ်ပါသည်။

လက်ခံပစ္စည်းများပြီးစီးမှုစံနှုန်း
အားနည်းချက် လွှမ်းခြုံမှုတည်ဆောက်သူ သို့မဟုတ် ရောင်းချသူ ကြေညာချက်သည် CVE-2026-109618 နှင့် CVE-2026-109619 ကို ပြတ်သားစွာ ပြင်ဆင်သည်
ဖြန့်ကျက်လွှမ်းခြုံပေါ်တယ်များ၊ ရေကူးကန်များ၊ ဝန်ဆောင်မှုများနှင့် ပုံတူများအားလုံးကို ပြုပြင်ထားသော runtime ကို အသုံးပြုသည်။
လုပ်ငန်းစဉ်က အသက်ဝင်တယ်။အလုပ်သမားဟောင်း၊ အိမ်ရှင်ဟောင်း လုပ်ငန်းစဉ်နှင့် ကွန်တိန်နာဟောင်းများအားလုံး ထွက်ပေါက်
တောင်းဆိုချက် စစ်မှန်ကြောင်း အတည်ပြုခြင်း။ကက်ရှ်လမ်းကြောင်းမှားခြင်းကို ဖယ်ရှားရန် အမှန်တကယ် Web လင့်ခ်ဖြင့် တည်ဆောက်ပြီး ပြုပြင်ထားသော SAPI အတည်ပြုထားသည်
လုပ်ငန်းရရှိနိုင်မှုစက်ရှင်၊ အပ်လုဒ်တင်ခြင်း၊ တင်သွင်းခြင်းနှင့် အမှားအယွင်း ကိုင်တွယ်ခြင်းကဲ့သို့သော အဓိကလုပ်ဆောင်ချက်များသည် ပုံမှန်အတိုင်း ပြန်ဖြစ်လာသည်။
ယာယီအစီအမံများ အဆုံးသတ်ခြင်း။အကန့်အသတ်မရှိ မှတ်ဉာဏ်နှင့် အလွန်အမင်း လုပ်သားပြန်လည်အသုံးပြုသည့် ပုံစံများကို စွမ်းရည်အစီအစဉ်အရ ပြန်လည်ရယူထားသည် သို့မဟုတ် ထိန်းသိမ်းထားရန် ရှင်းလင်းသော အကြောင်းပြချက်ရှိသည်
ပြောင်းလဲမှုအထောက်အထားပက်ကေ့ဂျ်ဗားရှင်း သို့မဟုတ် ရုပ်ပုံအကျဉ်းချုပ်၊ နယ်ပယ်ကို အပ်ဒိတ်လုပ်ရန်၊ ပြီးစီးချိန်နှင့် အတည်ပြုမှုရလဒ်များကို မှတ်တမ်းတင်ပါ။

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

PHP ပြင်းထန်သော၊ အလုပ်သမားပျက်ကျမှု၊ ပုံမှန်မဟုတ်သော ပြန်လည်စတင်မှု၊ တောင်းဆိုမှု အမှားနှုန်းနှင့် WAF ဖြစ်ရပ်များကို အပ်ဒိတ်မလုပ်မီနှင့် အပြီးစစ်ဆေးပါ။ မှတ်တမ်းများသည် စုံစမ်းစစ်ဆေးမှုသဲလွန်စများကိုသာ ပေးစွမ်းနိုင်သည်- OOM သည် ၎င်းကို အမြတ်ထုတ်သည်ဟု မဆိုလိုပါ၊ နှင့် နှိုးဆော်ချက်များ ကင်းမဲ့ခြင်းသည် အမြတ်ထုတ်ခြင်း မရှိကြောင်း သက်သေမပြနိုင်ပါ။ အဆင့်မြှင့်တင်မှုသည် အနာဂတ်တွင်ရောက်ရှိနိုင်သည့် အားနည်းချက်လမ်းကြောင်းများကို ပြင်ဆင်ပေးသည်။ ဖိုင်ကို ဆော့ကစားခြင်း သို့မဟုတ် အထောက်အထား ယိုစိမ့်မှုကဲ့သို့သော ကွဲလွဲချက်များကို တွေ့ရှိပါက သီးခြားဖြစ်ရပ် စုံစမ်းစစ်ဆေးမှုများ ပြုလုပ်သင့်သည်။

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

အရင်းအမြစ်လင့်ခ်များအားလုံးကို အောက်တွင် စုစည်းထားသည်။ အကြံပေးချက်များ၊ ဖာထေးမှုများနှင့် ရောင်းချသူလမ်းညွှန်ချက်များသည် October 22၊ 2026 ၏ စစ်ဆေးမှုများကို ထင်ဟပ်ပါသည်။ နောက်ဆက်တွဲ အသုံးချမှုများသည် ရောင်းချသူ အပ်ဒိတ်များအတွက် စစ်ဆေးသင့်သည်။ စာသားပါ နံပါတ်တပ်ထားသော ကိုးကားချက်များသည် ဤအရာများကို ရည်ညွှန်းပါသည်။

S1 — PHP တရားဝင် လုံခြုံရေးစာစောင်နှင့် ပြုပြင်မှုဗားရှင်း

  • အရင်းအမြစ်- ပရောဂျက် PHP၊ အောက်တိုဘာ ၂၁၊ ၂၀၂၆။
  • ရည်ရွယ်ချက်- အန္တရာယ် အတိုင်းအတာ၊ တရားဝင် ပြုပြင်မှု ဗားရှင်း လေးခု၊ တရားဝင် ယာယီ အစီအမံများနှင့် အကိုင်းအခက် အဟောင်းများအတွက် အရေးပေါ် အခြေအနေ ညွှန်ကြားချက်များ။
  • ကိုးကားချက်: PHP 2026 This security bulletin သည် နှစ်စဉ် စာစောင် မော်ကွန်းတွင် ရှိသည်။

S2 — CVE-2026-109618 တရားဝင် နည်းပညာဆိုင်ရာ သတင်းလွှာ

  • အရင်းအမြစ်- php/php-src GitHub Security Advisory၊ အောက်တိုဘာ ၂၁၊ ၂၀၂၆။
  • အထောက်အထား- GHSA-w8hw-w9fx-j79w။
  • ရည်ရွယ်ချက်- OOM အတွက် လွှမ်းခြုံနိုင်သော နယ်နိမိတ်၊ အစိတ်အပိုင်းများစွာ ချဲ့ထွင်ခြင်း၊ SAPI ကွာခြားချက်နှင့် လျော့ပါးသက်သာစေခြင်း။
  • ကိုးကားချက်: RCE via OOM corruption

S3 — CVE-2026-109619 တရားဝင် နည်းပညာဆိုင်ရာ သတင်းလွှာ

  • အရင်းအမြစ်- php/php-src GitHub Security Advisory၊ အောက်တိုဘာ ၂၁၊ ၂၀၂၆။
  • အထောက်အထား- GHSA-6wmf-4rv5-p3rp။
  • ရည်ရွယ်ချက်- အပြန်အလှန်တောင်းဆိုမှု dangling အခြေအနေ၊ ထုတ်လုပ်သူနှင့် စားသုံးသူများ၊ အစောပိုင်း အစပျိုးမှု၊ ဖွဲ့စည်းမှု လျှော့ချရေး။
  • ကိုးကားချက်: RCE via stale global state

S4 — PHP 8.5 တရားဝင် ပြင်ဆင်မှု တင်ပြချက်

  • အရင်းအမြစ်- php/php-src။
  • တင်ပြရန်- 31c0ea7d7ff1d1fccb6492e52dab544011628065။
  • ရည်ရွယ်ချက်- အားနည်းချက်နှစ်ခုကို တစ်ပြိုင်နက်တည်း ဖြေရှင်းရန် တရားဝင်တင်ပြမှုကို အတည်ပြုပြီး အလုံးစုံပြောင်းလဲမှု ဦးတည်ချက်ကို ရှင်းပြပါ။
  • ကိုးကားချက်: Avoid state corruption via bailout

S5 — PHP 8.5 တရားဝင်ပြန်လည်ရယူပြီး ပြီးပြည့်စုံသောကွာခြားချက်

  • အရင်းအမြစ်- တူညီသောတရားဝင်တင်ပြချက်နှင့် ကွဲပြားသည်။
  • ရည်ရွယ်ချက်- ခွဲဝေပေးသူ၊ VM၊ HTTP globals၊ စက်ရှင်၊ အမှတ်စဉ်သတ်မှတ်ခြင်းနှင့် တောင်းဆိုမှုဘဝစက်ဝန်း၏ သီးခြားအကောင်အထည်ဖော်မှုကို စစ်ဆေးပါ။
  • ကိုးကားချက်: official complete diff

S6 — PHP 8.1 တရားဝင် အရေးပေါ် backport တင်ပြခြင်း

  • အရင်းအမြစ်- php/php-src။
  • တင်ပြရန်- 1d7dec178a094e6e75b229ce22754045f8c6070a။
  • ရည်ရွယ်ချက်- အကိုင်းအခက်ဟောင်းများ၏ အမြန်ထွက်ပေါက်ကို စစ်ဆေးပြီး တိုးတက်မှု အပြုအမူပြောင်းလဲမှုများကို အပ်လုဒ်လုပ်ပါ။
  • ကိုးကားချက်: PHP 8.1 Emergency backport submission
  • ကိုးကားချက်: corresponds to complete diff

S7 — PHP 7.4 တရားဝင် အရေးပေါ် backport ဌာနခွဲ

  • အရင်းအမြစ်- php/php-src၊ PHP တရားဝင်လုံခြုံရေးစာစောင်တွင် ဖော်ပြထားသော အကိုင်းအခက်များ။
  • ကိုးကားချက်: PHP-7.4-CVE-2026-109618-109619

S8 — PHP 8.0 တရားဝင် အရေးပေါ် backport ဌာနခွဲ

  • အရင်းအမြစ်- php/php-src၊ PHP တရားဝင်လုံခြုံရေးစာစောင်တွင် ဖော်ပြထားသော အကိုင်းအခက်များ။
  • ကိုးကားချက်: PHP-8.0-CVE-2026-109618-109619

S9 — PHP 8.1 တရားဝင် အရေးပေါ် backport ဌာနခွဲ

  • အရင်းအမြစ်- php/php-src၊ PHP တရားဝင်လုံခြုံရေးစာစောင်တွင် ဖော်ပြထားသော အကိုင်းအခက်များ။
  • ကိုးကားချက်: PHP-8.1-CVE-2026-109618-109619

S10 — Ubuntu လုံခြုံရေးသတင်းလွှာ USN-8948-1

  • အရင်းအမြစ်- Canonical / Ubuntu၊ အောက်တိုဘာ ၂၁၊ ၂၀၂၆။
  • ရည်ရွယ်ချက်- backport ကိုထုတ်ပြီး ပက်ကေ့ဂျ်ဗားရှင်းနမူနာများ အပြည့်အစုံ။
  • ကိုးကားချက်: USN-8948-1: PHP vulnerabilities

S11 — PHP-FPM Configuration လက်စွဲစာအုပ်

  • အရင်းအမြစ်- PHP တရားဝင်စာရွက်စာတမ်း။
  • ရည်ရွယ်ချက်- php_admin_value၊ php_admin_flag၊ pm.max_requests စသည်ဖြင့် ဖွဲ့စည်းမှုဆိုင်ရာ ဝေါဟာရများ
  • ကိုးကားချက်: PHP-FPM Configuration

S12 — PHP Core INI ဖွဲ့စည်းမှုလက်စွဲ

  • အရင်းအမြစ်- PHP တရားဝင်စာရွက်စာတမ်း။
  • ရည်ရွယ်ချက်- တောင်းဆိုချက်ကိုယ်ထည်၊ အပ်လုဒ်လုပ်မှု၊ မန်မိုရီနှင့် အလိုအလျောက် POST ၏ အဓိပ္ပါယ်ဖွင့်ဆိုချက်နှင့် ဘောင်။
  • ကိုးကားချက်: Description of core php.ini directives

S13 — Nginx တောင်းဆိုချက် ကိုယ်ထည်အရွယ်အစား ကန့်သတ်ချက်

  • အရင်းအမြစ်- Nginx တရားဝင်စာရွက်စာတမ်း။
  • ရည်ရွယ်ချက်- client_max_body_size ၏အဓိပ္ပာယ်နှင့် ရရှိနိုင်သောဖွဲ့စည်းပုံအဆင့်များ။
  • ကိုးကားချက်: ngx_http_core_module / client_max_body_size

S14 — Nginx FastCGI တောင်းဆိုချက် ကြားခံ

  • အရင်းအမြစ်- Nginx တရားဝင်စာရွက်စာတမ်း။
  • ရည်ရွယ်ချက်- fastcgi_request_buffering ၏ လုပ်ငန်းစဉ် အဆင့်ဆင့်နှင့် လုပ်ဆောင်ချက်။
  • ကိုးကားချက်: ngx_http_fastcgi_module / fastcgi_request_buffering

S15 — Nginx အခြေအနေနှင့် ပြန်ပေးလမ်းညွှန်ချက်များ

  • အရင်းအမြစ်- Nginx တရားဝင်စာရွက်စာတမ်း။
  • ရည်ရွယ်ချက်- if နှင့် return ၏ဖွဲ့စည်းပုံအထားအသို။
  • ကိုးကားချက်: ngx_http_rewrite_module

S16 — Cloudflare PHP2Shell ကာကွယ်မှု ညွှန်ကြားချက်များ

  • အရင်းအမြစ်- Cloudflare တရားဝင်ဘလော့ဂ်။
  • ရည်ရွယ်ချက်- ၎င်း၏ WAF ဖြန့်ကျက်မှုနယ်ပယ်၊ Free အစီအစဉ် အစီအစဉ်နှင့် ထောက်လှမ်းမှု ယန္တရား၏ ဖော်ပြချက်။
  • ကိုးကားချက်: Cloudflare deploys protections against php2shell vulnerability