2026-yil 22-oktabr holatiga koʻra tekshirilgan manbalar. Audience: PHP ilova operatorlari, xavfsizlik xizmati xodimlari va maxsus PHP tuzilmalariga xizmat ko‘rsatuvchi muhandislar.
Ushbu maqolada PHP2Shell zaifligining sababi, ta’sir doirasi, rasmiy ta’mirlash jarayoni, vaqtinchalik yumshatish choralari va rasmiy yamoqni joriy qilish jamlangan. Asosiy matn S1 kabi raqamlar yordamida keltiriladi; barcha manba havolalari matn oxiridagi ilovada keltirilgan. Konfiguratsiya fragmenti joriy etish shablonidir, uni haqiqiy versiya, biznes imkoniyatlari va konfiguratsiya merosi munosabati asosida sozlash kerak.
TL; DR: Ta’mirlash bosqichlari va takliflar
- PHP ish vaqtini yangilang: tegishli filialni kamida 8.2.35, 8.3.36, 8.4.27 yoki 8.5.12. Tarqatish paketlari uchun sotuvchi ikkala CVEni tuzatganligini tasdiqlagan toʻliq paket versiyasidan foydalaning. S1S10
- Barcha eski jarayonlarni almashtiring: yangilangandan so’ng har bir PHP worker, xosting xizmati va konteynerni qayta ishga tushiring yoki boshqasiga o’tkazing va eski namunalar tugaganligini tasdiqlang.
- Haqiqiy Web so‘rov yo‘li orqali tasdiqlang: Web SAPI, to‘liq paket versiyasi va ishlayotgan misolni tekshiring.
php -vni tekshirishning o’zi jonli xizmat o’rnatilganligini aniqlamaydi. - Biznesning regressiya tekshiruvini o‘tkazing va oddiy resurs budjetlarini tiklang: test kirish, seansni boshqarish, yuklash, import qilish va xatolarni qayta ishlash. Agar PHP xotira chegarasi vaqtinchalik olib tashlangan bo’lsa, tuzatishdan so’ng tegishli cheklangan byudjetni tiklang.
- Agar darhol yangilash imkonsiz bo’lsa: ishonchsiz trafikni PHP ga yetguncha cheklang. Yuklash jarayoni va PHP 8.5 halokatli orqa izlarini 5-bo‘limda tavsiflanganidek o‘chirib qo‘yishni baholang. Konfiguratsiyani yumshatish va WAF qoidalari cheklangan qamrovga ega va yangilanish o‘rnini bosa olmaydi. S1S2S3
1. Zaifliklarni ko’rib chiqish va xavfni baholash
Ushbu maqoladagi PHP2Shell PHP tomonidan 2026-yil 21-oktabrda rasman oshkor qilingan Critical darajasidagi ikkita zaiflikka ishora qiladi. Ikkalasi ham PHP dvigatelining xotirasi va so‘rovning hayot aylanishini boshqarish bilan bog‘liq bo‘lib, masofaviy kodni chiqarish xavfini tug‘diradi. S1S2S3
| Loyiha | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| rasmiy nomi | RCE via OOM corruption | RCE via stale global state |
| asosiy masalalar | Xotiraning etarli emasligi g’ayritabiiy sakrashga olib keladi va hali ishga tushirish tugallanmagan holatni qoldiradi. | Ishchida qolgan global holat bo’shatilgan so’rov xotirasiga ishora qiladi. |
| Oddiy paydo bo’lish vaqti | Joriy so’rovni ishga tushirish, bajarish yoki tozalash jarayoni | Oldingi so’rov statusni qoldiradi va keyingi so’rovlar uni oldindan iste’mol qiladi. |
| OOM zaruriy shartmi? | Zaiflikning asosiy tetiklash mexanizmiga tegishli | Yo’q; boshqa halokatli xatolar va tashxisdan keyingi tozalash ham ishtirok etishi mumkin |
| Asosiy ta’mirlash yo’nalishi | Ajratishdagi nosozliklarni va tugatishni so’rashni xavfsiz boshqarish | Davlat mulkini, tozalash vaqtini va erta ishga tushirishni tuzatish |
| Utilizatsiya qilish talablari | ta’mirlanishi kerak | bir vaqtning o’zida ta’mirlanishi kerak |
Asos: Ikkita rasmiy xavfsizlik byulletenlari va tuzatishlar. S2S3S4
1.1 Ta’sir qilingan joylashtirishlarni tushunish
PHP rasman hisoblaydi hammasi PHP joylashtirishni boshqarish Web so’rovlar xavf ostida, shu jumladan PHP-FPM , Apache mod_php , php-cgi , FrankenPHP , va LiteSpeed . Namoyish qilingan mod_php Hujum dastur kodi ishga tushirilgunga qadar sodir bo’lishi mumkin, shuning uchun tizimga kirish tekshiruvlari, o’rta dastur va ilovalarni yuklash tekshiruvi bu yo’lni qamrab olmaydi. S1
“O’rnatishni tuzatish kerak” va “ma’lum bir hujum zanjiri to’liq isbotlangan” o’rtasidagi farqni ajratish kerak. CVE-2026-109618 e’loni: FPM so’rovni ishga tushirish muvaffaqiyatsiz tugagandan so’ng, boshlang’ich jarayondan chiqib ketadi va ishga tushirilgandan so’ng mod_php mos keladigan tozalash yo’lini bloklaydi; ammo, muvaffaqiyatli ishga tushirilgandan keyin OOM yo’li hali ham xavf ostida. E’londa, shuningdek, ushbu CVE uchun FPM to’liq ekspluatatsiyasi hali namoyish etilmagani ta’kidlanadi. Bu cheklovdan FPM xavfsiz ekanligini aniqlash uchun foydalanish mumkin emas, ayniqsa CVE-2026-109619ni e’tiborsiz qoldirib bo’lmaydi. S2S3
Muvaffaqiyatli ekspluatatsiya uchun bevosita ruxsat chegaralari PHP hosting jarayonining identifikatoriga va u foydalanishi mumkin bo’lgan resurslarga bog’liq. Umuman olganda, veb-sayt kodiga, yuklash katalogiga, ma’lumotlar bazasi hisob ma’lumotlariga, xizmat tokenlariga va ichki tarmoqqa kirish imkoniyatlariga e’tibor qaratish lozim; “Masofadan kodni bajarish” tabiiy ravishda ildiz ruxsatnomalarini olishni anglatmaydi. Natijalar qarori jarayonga ruxsat berish modeliga asoslanadi va amaldagi ta’sir joylashtirish ruxsatlari bilan birgalikda baholanishi kerak.
Oddiy bir martalik CLI skriptlarida bir xil HTTP yozuvi mavjud emas; lekin CLI yoki oʻrnatilgan rejimda uzoq vaqt davomida tashqi vazifalarni bajaradigan jarayonlar hali ham ish vaqti va hayot tsikli inventariga kiritilishi kerak. Faqat CMS, ramka yoki Composer bog’liqliklari yangilanadi va asosiy PHP dvigateli avtomatik ravishda almashtirilmaydi.
2. Sabablarni tahlil qilish
2.1 Avval ikkita hayot tsiklini tushunib oling
PHP worker ko’pincha ketma-ket bir nechta so’rovlarni bajaradi. So’rov davomida ajratilgan xotira so’rov oxirida bir xilda chiqarilishi mumkin, shu bilan birga ishchining o’zi va uning ba’zi global maydonlari mavjud bo’lib qoladi.
Shuning uchun dvigatel ikkita cheklovni saqlab turishi kerak:
- Initializatsiya cheklovi: Boshqa kodlarga ko’rinadigan ma’lumotlar xavfsiz o’qilishi, o’tishi va yo’q qilinishi mumkin bo’lgan holatda bo’lishi kerak.
- Lifecycle cheklovi: so’rov xotirasi bo’shatilgandan so’ng, uzoq muddatli maydonlar ushbu xotiradagi manzillarni haqiqiy holat sifatida ko’rib chiqmasligi kerak.
Ushbu ikkita cheklov zaiflikning ikki guruhining asosiy muvaffaqiyatsizlik rejimlariga mos keladi. Quyidagi jarayon e’lonlar va yamoq kompilyatsiyasini birlashtirgan mexanizm tavsifidir. Bu har bir joylashtirishning aynan bir xil erishish yo’li bor degani emas. S2S3S5
2.2 CVE-2026-109618: OOM tugallanmagan holat yangilanishini to’xtatdi
Eski dastur OOM bilan ishlash uchun longjmp() tipidagi mahalliy bo’lmagan sakrashdan foydalanadi va bog’langan yo’l zend_bailout() orqali joriy ijro kontekstidan chiqadi. Xavfli tomoni shundaki, C kodining bir qismi yangi ob’ekt, massiv yoki so’rov holatini boshqa kodga e’lon qilgan bo’lishi mumkin, lekin hali barcha maydonni ishga tushirishni tugatmagan; bu vaqtda, tegishli vaqtda har qanday ajratish xatosi odatdagi yopish bosqichlarini o’tkazib yuborishga olib kelishi mumkin. S2
Muvaffaqiyatsizlik jarayonini to’rt bosqichga bo’lish mumkin:
- So’rovning ichki tuzilmasini yarating yoki yangilang va undan foydalanish mumkin bo’lsin.
- Keyingi xotira ajratish muvaffaqiyatsiz tugadi va OOM ishga tushadi.
- Amalga oshirish oqimi joriy funktsiyadan uzoqlashadi va dastlab ishga tushirishni yakunlash yoki holatni tiklash uchun ishlatiladigan kod bajarilmaydi.
- Soʻrovni tozalash ushbu tuzilmalarni qayta ishlashni davom ettiradi va yaroqsiz tarkiblarni yaroqli maydonlar yoki manzillar sifatida koʻradi.
Muammo shundaki, xotiraning tugashi har doim RCE sabab bo’ladi. Aksincha, xotiraning tugashi boshqaruv oqimini o’zgartiradi va dvigatelning to’g’ri tuzilmalari haqidagi taxminlarini buzadi. Muvaffaqiyatsiz taqsimot oxir-oqibat noto’g’ri o’qiladigan tuzilmani bevosita o’z ichiga olmaydi. S2
Nima uchun kichikroq so’rovlar ham xotiradan chiqib ketishi mumkin
So’rov tanasidagi baytlar soni va tahlildan keyin to’pdan foydalanish bir xil narsa emas. A maydoni PHP ichidagi bir nechta satrlar, massiv elementlari va metama’lumotlar obyektlariga mos kelishi mumkin; kirish strukturasining murakkabligi xotirani kuchaytirish darajasiga ta’sir qiladi.
Rasmiy eʼlonda koʻrsatilgan koʻp qismli muammolarga quyidagilar kiradi: mavjud deklaratsiya uzunligi yoʻq boʻlganda boshlangʻich oʻlchamdagi tekshiruv oraligʻi, bitta qism uchun sarlavhalar soni yetarli darajada cheklanmagan va boʻsh fayl boshqaruvlari hamon metamaʼlumotlarni ishlab chiqaradi, ichki oʻrnatilgan nomlar massiv ish yukini yanada oshiradi. Ilovaning oʻzi ochishi, dekodlashi yoki kiritishni qayta tayinlashi ham OOM manbai boʻlishi mumkin. S2
Bundan ikkita himoyaviy xulosa chiqarish mumkin:
- PHP ga kirishdan oldin so’rov organi cheklovlari iloji boricha amalga oshirilishi kerak va haqiqiy o’qish uzunligi va strukturaviy murakkablik hisobga olinishi kerak.
- Fayl hajmini, fayllar sonini alohida cheklash yoki faqat bitta yuklash portalini yopish barcha OOM manbalarini qamrab olmaydi.
Nima uchun ilovani autentifikatsiya qilish juda kech bo’lishi mumkin
mod_php da so’rovni ishga tushirish bosqichida so’rov tanasi avtomatik ravishda tahlil qilinishi mumkin; ishga tushirish muvaffaqiyatsiz bo’lsa ham, tegishli so’rovni tozalash hali ham amalga oshiriladi. Tasdiqlangan hujum yo’llari shuning uchun dastur kodidan oldin paydo bo’lishi mumkin. Ushbu bosqichda taʼsir qilishni kamaytirish uchun teskari proksi-server, Web serveri yoki PHP soʻrovini qayta ishlashdan oldingi boshqa chegarada cheklovlar qoʻyilishi kerak. S1S2
2.3 CVE-2026-109619: So’rov xotirasi chiqarildi, global ma’lumot hali ham mavjud
Bu muammo xatolik, seans, ob’ekt yoki kengaytma holatini o’z ichiga oladi: maydon ishchi uzoq muddatli kirish joyida saqlanadi, lekin maydon tomonidan havola qilingan ma’lumotlar bitta so’rovga tegishli. Agar so’rovlar to’plami chiqarilgunga qadar havola to’g’ri tozalanmasa, keyingi so’rovlar osilgan holatga duch kelishi mumkin, bu esa foydalanishdan keyin foydalanishni tashkil qiladi. S3
Rasmiy tahlil ekspluatatsiya shartlarini “ishlab chiqaruvchilar” va “iste’molchilar” ga ajratadi:
| rol yoki shart | ma’nosi | Himoya uchun ta’sir |
|---|---|---|
| davlat ishlab chiqaruvchisi | Bu soʻrovga tegishli davlatni keyinroq kirish mumkin boʻlgan joyga qoʻying | Anormal chiqishdan keyin tegishli tozalash tugallanganligini tekshirish |
| Holati qolmoqda | U tozalanmagan, yoki u tozalangan va keyin kech operatsiya bilan to’ldirilgan. | Avvalgi o’chirish bosqichida bir marta tozalash etarli bo’lmasligi mumkin |
| ishchilarni qayta ishlatish | Xuddi shu ishchi keyingi so’rovlarni qayta ishlashda davom etadi | Bir nechta ishchi - bu xotira xavfsizligi kafolati emas, balki faqat rejalashtirish farqidir |
| avans iste’molchisi | Tegishli holat normal ishga tushirilgunga qadar qoldiq qiymatni o’qing, qoldiring yoki aniqlang. | Ishga tushirishdan oldin INI, sessiya va boshqa yo’llarni tekshirish kerak |
Ushbu shartlarni birgalikda bajarish kerak; har qanday xato jurnali o’z-o’zidan zaiflikdan muvaffaqiyatli foydalanilganligini isbotlamaydi. S3
Bu zaruriy shart sifatida OOM ni talab qilmaydi
Muhim xatolar juftlashgan davlat nashri va tiklanishiga xalaqit berishi mumkin. Kompilyatsiya yoki tahlil qilishdagi nosozliklar, noma’lum xatolar, require nosozliklari va bajarish vaqtining uzilishi muayyan holatlarni ortda qoldirishi mumkin. Kechiktirilgan tozalashda halokatli bo’lmagan diagnostika allaqachon o’chirilgan xato ma’lumotlarini qayta to’ldirishi mumkin. S3
Shuning uchun memory_limit ni cheksizga o’zgartirish ushbu zaifliklar to’plamini qamrab olmaydi.
”Ishga tushirishdan oldin” alohida ko’rib chiqilishi kerak
Ikki turdagi tasdiqlangan iste’molchilarning vaqti boshqacha:
- Early INI diagnostics: Soʻrov boʻyicha qoʻllaniladigan baʼzi konfiguratsiyalar oddiy ijrochi ishga tushirilgunga qadar ogohlantirish, ogohlantirish yoki eskirishni keltirib chiqaradi va diagnostika ishlovi eski xato holatiga kirishi mumkin.
- sessiyani yuklash jarayoni: so’rov tanasini tahlil qilish jarayonida sessiya oldindan qayta ishlanishi mumkin, ammo
RINIToddiy moduli hali tugallanmagan; yo’l mavjud emas deb xulosa qilib bo’lmaydi, chunki ilova aniqsession_start()ni chaqirmaydi. S3
Hammasi emas INI konfiguratsiyalar bir xil xavf vaqtiga ega. ning katalog darajasidagi konfiguratsiyasi mod_php va PHP_VALUE / PHP_ADMIN_VALUE tomonidan o’tdi FPM oldingi qismni oddiydan ajratish kerak php.ini , FPM pool ishga tushirish konfiguratsiyasi va FPM .user.ini . Ikkinchisi turli xil konfiguratsiya vaqtlariga ega va ularni birgalikda bir xil dastlabki iste’molchilar deb atash mumkin emas. S3
display_errors, log_errors-ni o’chirish, error_reporting-ni qisqartirish yoki @-dan foydalanish faqat tashxisning ko’rinishiga ta’sir qiladi; jurnalni chiqarishga qaror qilishdan oldin tegishli ichki holatga kirgan bo’lishi mumkin. S3
3. Ta’mirlash versiyasi va yamoq tanlash
3.1 Rasmiy yuqori oqimni tuzatish bazasi
| Hozirgi PHP filiali | Ushbu rasmiy tuzatishni o’z ichiga olgan birinchi versiya | Takliflar |
|---|---|---|
| 8.2 | 8.2.35 | Ushbu versiyaga yoki bir xil tuzatishlarni o’z ichiga olgan keyingi versiyaga yangilang |
| 8.3 | 8.3.36 | Yuqoridagi kabi |
| 8.4 | 8.4.27 | Yuqoridagi kabi |
| 8.5 | 8.5.12 | Yuqoridagi kabi |
| 8.1 va oldingi versiyalar | Yuqori oqimdagi umumiy yordam tugadi | Qo’llab-quvvatlanadigan filiallarga ko’chirishga ustuvor ahamiyat bering; qisqa muddatli tekshirish reliz yoki LTS ishlab chiqaruvchi backport |
Versiya va qoʻllab-quvvatlash holati PHP rasmiy eʼloniga asoslanadi va asosiy vaqt 2026-yil 22-oktabr. S1
Bu filialga xos tuzatish chegaralari. Ularni 8.5.12 ostidagi har bir versiya zaif ekanligi haqidagi bayonot bilan almashtirib bo’lmaydi: boshqa filiallardagi 8.2.35 va 8.4.27 kabi versiyalarda allaqachon tuzatishlar mavjud.
3.2 To’liq tarqatish paketi versiyasini tekshiring
Distros ko’pincha eski yuqori oqim versiyalari asosida xavfsizlik tuzatishlarini qo’shadi. Qabul qilish, shuningdek, reliz versiyasini, ombor manbasini, to’liq paket versiyasini va xavfsizlik byulletenini tekshirishi kerak.
Masalan, Ubuntu USN-8948-1 uchun roʻyxatlangan Ubuntu 24.04 LTS tuzatish paketi versiyasi:
8.3.6-0ubuntu0.24.04.13Uning yuqori qismi hali ham 8.3.6, ammo ushbu tarqatishning to’liq paketli versiyasi ushbu tuzatish e’loniga kiritilgan. Bu xulosa faqat tegishli tarqatish va paket manbasiga taalluqlidir va 8.3.6 ni ham ko‘rsatadigan har qanday tuzilma uchun umumlashtirib bo‘lmaydi. S10
3.3 To’g’ri yamoqni tanlash
| sahna | Ustuvor reja | Qabul qilish uchun asosiy fikrlar |
|---|---|---|
| PHP tarqatish paketidan foydalanish | Ishlab chiqaruvchi tomonidan chiqarilgan xavfsizlik yangilanishlarini o’rnating | E’lon CVE ikkalasini ham qamrab oladi; to’liq paket versiyasi to’g’ri |
| Rasmiy PHP konteyneridan yoki o’z-o’zidan qurilgan tasvirdan foydalaning | Asosiy ish vaqtini yangilang, qayta quring va joylashtiring | Ishlayotgan namuna yangi tasvirdan foydalanadi; barcha eski nusxalar o’chiriladi |
| O’z-o’zidan tuzilgan qo’llab-quvvatlanadigan filiallar | Ushbu filialning rasmiy xavfsizlik versiyasidan yoki to’liq rasmiy yamoq to’plamidan foydalaning | Filialni moslashtirish, qaramlikni yakunlash, kengaytma mosligi va regressiyadan o’tish |
| 7.4, 8.0, 8.1 shartlariga muvofiq | Sotuvchining orqa portiga ustunlik bering; agar kerak bo’lsa, favqulodda manba kodining rasmiy filialini baholang | Xulq-atvordagi o’zgarishlarni aniqlang va qo’llab-quvvatlanadigan versiyalarga ko’chirishni rejalashtiring |
Rasmiy yamalar chiqarildi va haqiqiy tuzatishlar shu yamoqlardan boshlanishi kerak. 6-bo’limdagi kod parchalari dizayn va ko’rib chiqishning diqqatga sazovor joylarini tasvirlash uchun mo’ljallangan va mustaqil ravishda qo’llanilishi mumkin bo’lgan to’liq yamoqni tashkil etmaydi. S1S4S6
4. Rasmiy ta’mirlash jarayoni
4.1 so’rovlarni amalga oshiradigan ish vaqti inventarizatsiyasi
Hech bo’lmaganda quyidagilarni qayd etish uchun qisqacha daftarni shakllantirish tavsiya etiladi:
- Kirish domen nomi yoki xizmati, teskari proksi-server, PHP SAPI.
- PHP filiali, toʻliq paket versiyasi yoki tasvir dayjesti, qurish manbasi.
- FPM pool, haqiqiy xizmat ko’rsatish birligi, konteyner yoki Pod, nusxalar soni.
- Kengaytmalar, asosiy konfiguratsiya va qo’shimcha konfiguratsiya fayllari yuklandi.
- To’g’ridan-to’g’ri kirish mumkin bo’lgan boshqa PHP versiyalari, eski tarqatish nusxalari yoki manba portallari bormi?
Bular “yangilangan” har bir haqiqiy trafik yozuviga mos kelishi uchun amalga oshirish bo’yicha takliflardir. Ayniqsa, PHP va Web PHP buyruq satrlari turli versiyalardan foydalanayotganligini, tasvir qurilgan, lekin eski konteyner ishlayotganligini, hovuzning bir qismi yoki nusxasi almashtirilmaganligini va hokazolarni tekshiring.
4.2 To’g’ri yangilanishni tanlang va o’rnating
Mavjud ishonchli paket manbasi yoki boshqariladigan tuzilma zanjiri yordamida 3-bo‘limga muvofiq tuzatish versiyasini tasdiqlang. Yangilanish doirasi FPM to’plami, Apache PHP moduli, CGI ikkilik yoki PHP o’rnatilgan xizmat tuzilmasi kabi so’rovni qabul qiluvchi komponentni o’z ichiga olishi kerak.
Yangilashdan oldin konfiguratsiya va paketlar roʻyxatini saqlang va ishga tushirish va asosiy xizmatlarni ishlab chiqarishga oʻxshash muhitda tekshiring. O’z-o’zidan qo’llab-quvvatlanadigan kengaytmalar uchun PHP versiyasiga mos keladigan qurish va ishga tushirish mosligini tekshiring. Boshqa filialdan tegishli ko’rinadigan majburiyatni tanlash butun tuzatishlar to’plami amalga oshirilganligini kafolatlamaydi.
4.3 Ishlayotgan misollarni qayta ishga tushiring yoki aylantiring
Faylni o’rnatish va jarayonga yangi kodni yuklash ikki xil narsadir. Tegishli xizmat qayta ishga tushirilishi yoki prokatni almashtirish tugallanishi va eski ishchi va eski konteynerning chiqib ketganligi tasdiqlanishi kerak.
mod_php uchun modulni joylashtirish Apache jarayonini qayta ishga tushiring. PHP o’rnatilgan xizmatlar hosting jarayonini o’zgartirishi kerak. FPM uchun OPcache ni tozalash ish vaqtini yangilash va eski ishchilarni ishdan bo’shatish o’rnini bosmaydi.
Aqlli kommutatsiyadan foydalanganda, eski avlod jarayoni hali ham uzoq ulanishlarni yoki muhim so’rovlarni bajarayotganini tekshirishingiz kerak. Qabul qilish yozuvi haqiqiy xizmatni, o’rnatish versiyasini, o’zgartirishni yakunlash vaqtini va eski namunaning chiqish natijalarini o’z ichiga olishi kerak.
4.4 Haqiqiy Web so’rovlari orqali tasdiqlang
Faqat bitta versiya buyrug’iga tayanmasdan, quyidagi dalillarni birlashtirish tavsiya etiladi:
| dalil | Nimani isbotlash mumkin | Bir o’zi hech narsani isbotlab bo’lmaydi |
|---|---|---|
| Paket menejeri yoki tasvir metama’lumotlari | O’rnatish manbalari va to’liq tuzilmalar | Trafik ushbu misolga almashtirildi |
| Jarayon va joylashtirish holati | ishchi yoki konteyner almashtirishni tugatadi | Tashqi kirish joyi unga yo’naltirilishi kerak |
| Haqiqiy portal orqali cheklangan diagnostika natijalariga kirish mumkin | Haqiqiy Web SAPI va ishlaydigan konfiguratsiya | Chiqarish orqa porti ikkita CVE-ni qamrab oladimi |
| Sotuvchi e’loni yoki to’liq yamoq yozuvi | Ushbu xato tuzatish ushbu tuzilishga kiritilgan | Barcha replikalar joylashtirilgan |
PHP_VERSION, PHP_SAPI, yuklangan konfiguratsiya fayllari va favqulodda konfiguratsiyalar mavjud ichki diagnostika imkoniyatlari yoki vaqtinchalik va kirish nazorati ostidagi diagnostika portallari orqali tekshirilishi mumkin. So’rov bevosita CDN yoki sahifa keshi tomonidan qaytarilmaganligiga ishonch hosil qiling; tugallangandan so’ng vaqtinchalik diagnostika yozuvini olib tashlang.
php -v odatda faqat qobiq tomonidan tanlangan CLI ikkilik faylini bildiradi; php-fpm -i kabi buyruqlar trafikni qabul qilayotgan mavjud ishchini tekshirishga teng emas. To’liq phpinfo() sahifasini uzoq vaqt davomida umumiy tarmoqqa qo’ymang.
4.5 Biznes regressiyasini tekshirish va favqulodda vaziyatlar sozlamalarini olib tashlash
Oddiy kirish, seansni o’qish va yozish, shakllantirish va yuklash, import qilish, xatolarni qayta ishlash va ushbu o’zgarishdan ta’sirlangan funktsiyalar atrofida ishchi barqarorligini tekshiring. Xato tezligi, javob kechikishi, xotira cho’qqisi, jarayondan chiqish va qayta tiklash chastotasi g’ayritabiiy yoki yo’qligini tekshiring.
Agar memory_limit=-1 vaqtincha o’rnatilgan bo’lsa, biznes imkoniyatlariga mos keladigan cheklangan byudjet rasmiy yamoq kuchga kirgandan keyin tiklanadi; agar pm.max_requests=1 o’rnatilgan bo’lsa, ta’mirlash tasdiqlangandan so’ng sig’im bilan baholangan hayot aylanishi konfiguratsiyasi tiklanadi. Kirish hajmi chegaralari va manbaga kirishni boshqarish biznes ehtiyojlariga qarab saqlanishi mumkin.
Yangilash vaqtida moslik bilan bog’liq muammolar yuzaga kelsa, ta’sirlangan portalni to’xtatib turish, uning tashqi kirishini cheklash yoki orqaga qaytarishdan oldin ilovani sozlashga ustuvor ahamiyat berish kerak. To’g’ridan-to’g’ri ta’mirlanmagan ish vaqtining umumiy tarmoqqa yana xizmat ko’rsatishiga ruxsat berish dastlabki xavfni qayta ochadi.
5. Darhol yangilash mumkin bo’lmaganda, yumshatish choralari
Ushbu bo’lim qisqa muddatli ta’sirni kamaytirish yoki mavjudligini yaxshilash uchun mo’ljallangan. Har bir o’lchov faqat ma’lum bir yo’lni qamrab oladi va bir nechta chora-tadbirlarning kombinatsiyasi to’liq ta’mirlashga teng emas. S1S2S3
5.1 PHP dan oldin trafikni boshqarishga ustuvor ahamiyat bering
Agar xizmat ruxsat bersa, PHP dan oldin nozik so’nggi nuqtalarni ishonchli manbalar bilan vaqtincha cheklang yoki kirish nazoratini tatbiq eting. Yuklash ish yuklari uchun so’rovning asosiy hajmini, maydonlar sonini, qismlarni hisoblashni, har bir qism sarlavhalarini va joylashtirish chuqurligini cheklang. Ko’p qismga muhtoj bo’lmagan xizmatlar uni frontendda rad etishi mumkin. S2
Ushbu cheklovlar PHP ga barcha kirishlarni qamrab oladi. Faqatgina “yuklash” deb nomlangan URL ni ushlab turish, so‘rov matnida PHP tomonidan avtomatik ravishda tahlil qilinadigan boshqa yozuvlarni o‘tkazib yuboradi. Parchalangan o’tkazmalar, mavjud e’lon qilingan uzunlik yo’qligi va hokazolar uchun chegara haqiqiy o’qish hajmiga asoslanishi kerak; Ilova kontentni ochish yoki kengaytirishda ham o’zining chiqish hajmi byudjetiga ega bo’lishi kerak.
5.2 FPM pool konfiguratsiya shabloni
Quyidagi sozlamalarni php.ini da so‘zma-so‘z emas, balki so‘rovlariga xizmat qiluvchiFPM pool konfiguratsiya bo‘limiga joylashtiring. 8M va 4M qiymatlari ish yukini sozlash uchun misollardir. Butun POST so’rovini cheklashda shakl maydonlari va ko’p qismli chegaralar uchun joy qoldiring. S11S12
; 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] = offFaqat PHP 8.5, shuningdek:
php_admin_flag[fatal_error_backtraces] = offHar birining funktsiyalari va chegaralari quyidagicha:
| Konfiguratsiya | kutilgan ta’sir | Saqlanishi kerak bo’lgan cheklovlar tavsifi |
|---|---|---|
memory_limit=-1 | Bashorat qilinadigan PHP so’rovi xotirasi yuqori chegarasi ishga tushirish holatini olib tashlang | Bu asosiy taqsimot xatosini oldini olmaydi; asl byudjetni bekor qilish xotiraning tugashi va xizmatni to’xtatish xavfini oshirishi mumkin. |
Kichikroq post_max_size | Tahlil qilish jarayoniga kiruvchi ma’lumotlar hajmini kamaytiring | Aniqlanmagan tahlilchi ma’lum bo’shliqqa ega; xotirani kuchaytirishni mustaqil ravishda oldini olish mumkin emas |
upload_max_filesize < post_max_size | Bitta fayl hajmini cheklang va so’rov uchun ortiqcha joyni zaxiralang | Barcha maydonlar, metadata yoki ilova ichidagi taqsimotlarni cheklamaydi |
| Yuklash jarayonini yopish | Tasdiqlangan seans bilan bog’liq yo’lni bloklash | Boshqa global davlat variantlarini qamrab olmaydi |
| PHP 8.5 halokatli orqaga qaytish | Tasdiqlangan tegishli status ishlab chiqaruvchilarni bloklash | Seans kabi boshqa yo’llarni qamrab olmaydi |
O’lchov chegaralari rasmiy e’londan kelib chiqadi; hovuz sintaksisi va boshqaruv darajasidagi konfiguratsiya semantikasi uchun PHP qoʻllanmasiga qarang. S1S2S3S11
Boshqaruv darajasidagi php_admin_* sozlamalarini ini_set() orqali ilovalar tomonidan bekor qilib bo‘lmaydi. Haqiqiy so’rovlardagi qiymatlar kutilganidek ekanligini tasdiqlash uchun barcha hovuz, katalog darajasidagi va oldingi kirish konfiguratsiyalari hali ham ko’rib chiqilishi kerak. O’zgartirishdan so’ng, mavjud jarayonlarning eski holatini saqlab qolishning oldini olish uchun barcha ishchilarni qayta tiklang.
Agar siz php.ini ni bevosita oʻzgartirishni tanlasangiz, sintaksis quyidagiga oʻzgartirilishi kerak:
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = OffHovuzdagi php_admin_value-dan farqli o’laroq, memory_limit=-1-ni php.ini-ga o’rnatishning o’zi ilovaning uni qayta o’zgartirishiga to’sqinlik qilmaydi. Ramka, dastur kodi va boshqa konfiguratsiyalar cheklangan qiymatni qayta o’rnatganligini tekshirish uchun tekshirilishi kerak; amal qilish zarur bo’lganda, joriy SAPI uchun mos boshqaruv darajasidagi sozlamalardan foydalaning va haqiqiy samarali qiymatni tekshiring. S11S12
Faqat PHP 8.5 uchun fatal_error_backtraces = Off qo’shing. Ilova darajasidagi ini_set() ni yuklash jarayonini oʻchirish uchun vaqtinchalik yechim sifatida ishlatmang va soʻrovni tahlil qilishdan oldin uni samarali qilish uchun FPM .user.ini ga tayanmang. S1S3
5.3 PHP xotira cheklovlarini olib tashlash xarajatlarini boshqaring
memory_limit=-1 - tuzatilmagan muhitlar uchun vaqtinchalik yo’l yumshatish va uzoq muddatli standart konfiguratsiya sifatida nusxa ko’chirilmasligi kerak. Ilova yoki so‘rov nazoratdan chiqib ketganda, u xost xotirasidan ko‘proq foydalanishi mumkin. Shuning uchun, foydalanishdan oldin, siz bir vaqtning o’zida bir vaqtning o’zida sonini, eng yuqori bitta ishchi va umumiy xizmat ko’rsatish hajmini baholashingiz va oldingi kirish cheklovlarini o’rnatishingiz kerak. S2
Konteyner yoki guruh xotirasi chegaralari mavjudlik chegaralarini ta’minlashi mumkin, lekin ajratish hech qachon muvaffaqiyatsiz bo’lmasligiga kafolat bermaydi; Limit ishga tushirilganda butun konteyner, usta va barcha ishchi ham tugatilishi mumkin. Izolyatsiyaning granulyarligi va tugatish strategiyalari joylashtirish bilan birgalikda baholanishi kerak va bu ikkita CVE uchun to’liq himoya deb atash mumkin emas. S2
Yuqoridagi strategiyalarni RLIMIT_AS, RLIMIT_DATA yoki tegishli jarayon manzili boʻshliqlari cheklovlari bilan almashtirmang; ular to’g’ridan-to’g’ri asosiy taqsimotning hali ham muammoli OOM yo’liga tushmasligiga olib kelishi mumkin. S2
5.4 Nginx konfiguratsiya namunasi
Nginx so’rovlarni PHP-FPM ga yo’naltiradigan joylashtirish uchun qo’llaniladi. U haqiqiy xosting xizmatining konfiguratsiya darajasida o’rnatilishi mumkin:
client_max_body_size 8m;
fastcgi_request_buffering on;client_max_body_size so’rovning asosiy hajmini cheklaydi; fastcgi_request_buffering on Nginx ga avval so‘rovning to‘liq qismini o‘qib, keyin uni FastCGI serveriga yuborish imkonini beradi. Muayyan server yoki location da kuchga kiradimi, mavjud meros va qamrov munosabatlari bilan birgalikda tekshirilishi kerak. S13S14
Faqat biznesga ko’p qismli kerak bo’lmasa, tegishli xizmat kirishiga rad etish qoidasini qo’shishingiz mumkin:
if ($http_content_type ~* "multipart/form-data") {
return 403;
}Bu if va return-dan foydalanadigan oddiy kirishni cheklash shablonidir, tahlilchi zaifliklari uchun umumiy filtrlash qoidasi emas. O’rnatishdan oldin konfiguratsiya sintaksisi va oddiy so’rovlarni tekshiring va maxsus error_page 403 ta so’rovni PHP ga yo’naltirishini tekshiring. String moslashuvi barcha tahliliy farqlarga to’liq kafolat bermaydi. S15
Bundan tashqari, ushbu konfiguratsiyalar ma’lumotlar miqdorini, maydonlar sonini yoki dastur tomonidan ochiladigan PHP ob’ektlari sonini avtomatik ravishda cheklamaydi; yuklashi kerak bo’lgan korxonalar o’z so’rovlarining tuzilishini tushunadigan qo’shimcha cheklovlardan foydalanishlari kerak.
5.5 Ixtiyoriy yumshatish: har bir FPM ishchisiga bitta so‘rov
Qo’shimcha xarajatlarga ega bo’lgan FPM joylashtirishlari uchun qisqa muddatli sozlashlarni baholash mumkin:
pm.max_requests = 1Va mavjud ishchini qayta tiklang. Bu ishchi qayta foydalanish darajasida tasvirlangan o’zaro so’rovlar zanjirini bloklaydi, lekin jarayonni yaratish va ishga tushirish xarajatlarini oshiradi; bir vaqtning o’zida u OOM so’rovini tuzata olmaydi va CVE-2026-109618 muammolarini tozalay olmaydi. Qiymat kichikroq, lekin 1 dan katta bo’lsa, so’rovni qayta ishlatish oynasi mavjud. S3S11
5.6 WAF va Cloudflare qamrov chegaralari
Cloudflare PHP2Shell dan, jumladan Free rejasidan himoyalanish uchun joylashtirish choralarini e’lon qildi. Uning xizmatlaridan foydalanganda haqiqiy trafik proksi-server orqali o’tadimi yoki yo’qmi, himoya qoidalari amal qiladimi va kelib chiqish joyini to’g’ridan-to’g’ri chetlab o’tish mumkinmi yoki yo’qligini tekshirishingiz kerak; pullik rejalar uchun, shuningdek, tegishli boshqariladigan qoidalarning konfiguratsiyasi va istisnolarini tekshirishingiz kerak. S16
Sotuvchi tomonidan tavsiflangan ba’zi aniqlashlar javob signallaridan foydalanadi, shuning uchun barcha himoyalarni “har bir hujum PHP ga yetguncha bloklanadi” deb talqin qilib bo’lmaydi. WAF taʼsir qilishni kamaytirishga va kuzatuv maʼlumotlarini taqdim etishga yordam beradi, ammo PHP ga doimiy yangilanishlar zarur. S16
5.7 Nima uchun umumiy choralar etarli emas
| choralar yoki hukmlar | kamchiliklar |
|---|---|
Faqat file_uploads ni yoping | Barcha ko’p qismli ishlov berishni qamrab olmaydi va o’zining OOM yo’lini qo’llay olmaydi |
enable_post_data_reading=Off sozlamalari | POST/FILESni avtomatik to’ldirish xatti-harakatlarini o’zgartirish; so’rov organi hali ham dastur tomonidan o’qilishi mumkin va oddiy biznesni buzishi mumkin |
Xato ko’rsatishni o’chiring, jurnalga yozing yoki @ dan foydalaning | Ichki diagnostika jarayoni hali ham osilgan holatga kirishi mumkin |
| Ishchilar sonini ko’paytirish | Xavfsiz davlatni tozalash mexanizmini o’rnatmang va bitta ishchining qayta ishlatilishini bekor qilmang |
Faqat disable_functions yoki open_basedir sozlang | Ushbu cheklovlar C dvigatel qatlami xotirasining buzilishini tuzatmaydi |
| Versiyani yoki bitta nusxasini faqat bir marta tekshiring | Barcha kirishlar va ishlaydigan misollar almashtirilganligini isbotlab bo’lmaydi |
| Hech qanday istisno jurnallari ko’rinmaydi | Bu zaiflik mavjud emasligini yoki undan oldin foydalanilmaganligini isbotlay olmaydi. |
Ular orasida PHP konfiguratsiyasi va zaiflik mexanizmi asosini S2S3S12 da topish mumkin; qamrab olish, qabul qilish va ruxsat berish chegaralari haqidagi qarorlar ushbu mexanizmlar tomonidan ilgari surilgan amalga oshirish bo’yicha takliflarga asoslanadi.
6. Rasmiy yamoqni amalga oshirish g’oyalari va ko’rib chiqish nuqtalari
6.1 To’g’ri filial uchun to’liq tuzatishlardan foydalaning
PHP 8.5 uchun vakolatli rasmiy taqdimnoma:
31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailoutMajburiyat OOM chiqish mexanizmini sozlash va ishga tushirish bosqichida kirish mumkin bo’lgan global holatni tuzatish uchun ikkita CVE-ni aniq bog’laydi. Toʻliq farq bilan sahifani yuborish S4S5. Boshqa filiallar o’zlarining rasmiy xavfsizlik relizlari yoki mos keladigan yamoqlardan foydalanishlari kerak va 8.5 ga kiritilgan o’zgartirishlar to’g’ridan-to’g’ri istalgan eski versiyaga qo’llanilishi mumkin deb hisoblab bo’lmaydi.
6.2 OOM Ta’mirlash: avval qayta ishlanadigan holatni tiklang, so’ngra so’rovni to’xtating
Rasmiy amalga oshirish yumshoq va qattiq OOM ishlov berishning ikki darajasini joriy qiladi: yumshoq chegaraga erishilganda, kutilayotgan holat qayd etiladi va VM kabi xavfsiz joyda boshqariladigan chiqish amalga oshiriladi; muvaffaqiyatsiz ajratish interfeysi qo’ng’iroq qiluvchiga nosozlikni aniq hal qilish imkonini beradi. To’g’ridan-to’g’ri muvaffaqiyatsizlikni qaytara olmaydigan ajratmalar uchun, agar yuqoriroq chegaradan oshib ketishi kutilsa, xavfli oraliq holatda so’rovlarni qayta ishlashni davom ettirmaslik uchun jarayon bevosita to’xtatiladi. S2S5
Quyida kutilayotgan OOM ni belgilash uchun ishlatiladigan 8.5 farqidagi kalit kodidan ko‘chirma keltirilgan:
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);VM uzilishlarni qayta ishlash va boshqa xavfsiz joylar keyinchalik zend_handle_delayed_oom() ni chaqiradi. Uning foydalanuvchi kodini bajarish konteksti boshqariladigan ochish yo’lidan foydalanadi; qattiq OOM yo’li _exit(137) ni chaqiradi. S5
Dizayn nuqtai nazaridan asosiy o‘zgarish: tuzilma oraliq holatda bo‘lganida C chaqiruv steki bo‘ylab ixtiyoriy sakrashdan qochish va chiqishni holat invariantlarini saqlash mumkin bo‘lgan nuqtaga ko‘chirish. Yumshoq chegara ishga tushirilgandan so‘ng, ishlov berishni yakunlash uchun qo‘shimcha xotira kerak bo‘lishi mumkin. Shu sababli yangi yumshoq chegarani jarayonning jami xotirasi uchun mutlaq yuqori chegara deb tushunmaslik kerak.
Buni “PHP barcha zend_bailout() ni o’chirib tashladi” deb ham umumlashtirib bo’lmaydi. Yamoq hali ham muayyan kontekstlarda tegishli mexanizmlardan foydalanadi; belgilangan narsa - xavfli chiqish vaqti va unga hamroh bo’lgan davlat boshqaruvi. S5
6.3 Alohida qo’ng’iroq qiluvchilarni yangilang va birgalikda ko’p qismli tahlil qiling
Agar siz ajratish funksiyasini faqat “noto’g’ri bo’lganda NULLni qaytarish” ga o’zgartirsangiz va asl qo’ng’iroq qiluvchi hali ham to’g’ri ko’rsatgich har doim qaytariladi deb hisoblasa, siz yangi null ko’rsatkichga kirishlarni yoki to’liq bo’lmagan tozalashni kiritasiz. Yamoqdagi muvaffaqiyatsiz ajratish interfeysi qo’ng’iroq qiluvchini tekshirish va istisnolarni tarqatish bilan birga ko’rib chiqilishi kerak. S5
ko’p qismli tegishli tuzatishlar, shuningdek, haqiqiy o’qish hajmiga asoslangan kümülatif tekshiruvlarni amalga oshirish, foydasiz yoki takroriy sarlavhalarni qayta ishlashni qisqartirish va OOM kutilayotganda izchil chiqish va tozalash mantig’ini qabul qilishni o’z ichiga oladi. Ushbu o’zgarishlar resurs kuchaytirilishini kamaytiradi va tahlil qiluvchini yangi OOM protokoliga moslashtiradi. S5
O’z filiallariga ega bo’lgan jamoalar uchun kodni ko’rib chiqishda quyidagi masalalarga e’tibor qaratish tavsiya etiladi:
- Davlat to’liq ishga tushirilgunga qadar tashqi dunyoga ko’rinadimi?
- Ajratishda xatolik yoki qayta qo’ng’iroq qilishdan keyin ham egalik yagona va aniq emasmi?
- Yarim yo’lda muvaffaqiyatsizlikka uchragan bo’lsangiz, birlashgan tozalashga chiqishingiz mumkinmi?
- Tozalash funktsiyasi ishga tushirilmagan yoki bo’shatilgan maydonlarni taniy oladimi?
- Tahlil byudjeti faqat ishonchli so’rov da’volariga emas, balki haqiqiy qayta ishlash hajmiga asoslanganmi?
- Yangi nosozlikni qaytarish qiymati barcha qo’ng’iroq qiluvchilar tomonidan ko’rib chiqilganmi?
Bular tuzatish mexanizmi asosida umumlashtirilgan ko’rib chiqish savollari bo’lib, taqdim etilmagan kod bazasi uchun yakunlangan auditning xulosasi emas.
6.4 Oʻzaro soʻrovni tuzatish: avval ishga tushirish, soʻnggi tozalash keyinroq
CVE-2026-109619 ga mos keladigan yamoq bir vaqtning o’zida bir nechta hayot tsikli chegaralarini sozlaydi. Quyida keltirilgan fayllar va operatsiyalar PHP 8.5 rasmiy farqini misol qilib oladi. S5
| joylashuvi | yo’nalishini o’zgartirish | Muammo hal qilindi |
|---|---|---|
Zend/zend_execute_API.c va boshqalar. | Xatolar, istisnolar, ishlov beruvchilar, ob’ektlar va boshqalar kabi ijrochi holatini tiklash. | So’rov tugagandan so’ng, keyingi so’rov orqali kirish mumkin bo’lgan eski havolalar mavjud. |
main/main.c ishga tushirish yo’li | SAPI faollashtirilgunga qadar php_basic_early_rinit() ga qo’ng’iroq qiling | Erta iste’molchi paydo bo’lganda, tegishli asosiy holat hali ishga tushirilmagan. |
main/main.c yo’lini yoping | HTTP globals-ni yo’q qiling va uni aniqlanmagan deb belgilang | Chiqarilgan qiymat hali ham haqiqiy ob’ekt hisoblanadi |
| so’rovlar to’plami nihoyat bo’shatilguncha | Oxirgi xato xabarini yana tozalang | Kechiktirilgan tozalash diagnostikasi xato holatini to’ldiradi |
ext/session/session.c | yuklash jarayonining dastlabki yo’li birinchi sessiya global miqyosda ishga tushiriladi | Oddiy modul RINIT avvalroq eski holatiga kirgan |
| Serializatsiya bilan bog’liq kod | Erta ishlov berishda sinfni tahlil qilish va foydalanuvchi qo’ng’iroqlarini cheklash | Boshlash tugallanmaganda qo’shimcha foydalanuvchi kodini bajaring |
Masalan, ishga tushirish ketma-ketligi quyidagilarni o’z ichiga oladi:
zend_activate();
php_basic_early_rinit();
sapi_activate();HTTP globals yo’q qilingandan so’ng, nosozlik holati belgisini qo’shing:
zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);Ushbu iqtiboslar ikkita tamoyilni ko’rsatadi: XQ00000QXImum bo’lgan eng erta iste’molchidan oldin ishga tushiring va holatni qayta yaratishi mumkin bo’lgan oxirgi operatsiyadan so’ng yakuniy tozalashni amalga oshiring. Ko’rsatgichni faqat oddiy RINIT yoki oldingi o’chirish bosqichida qayta o’rnatish oldingi yoki keyingi kirishlarni o’tkazib yuborishi mumkin. S5
6.5 Nima uchun o’zingizning “bir qatorli ta’mirlash” ni amalga oshirish tavsiya etilmaydi?
Barcha zend_bailout() ni _exit() bilan almashtirish yoki ma’lum bir yozuvda null ko’rsatkichni tekshirishni qo’shish juda ko’p turli xil ijro kontekstlarini qamrab oladi. Ular boshqa holat maydonlarini o’tkazib yuborishi yoki yo’q qilish, kengaytirilgan qayta qo’ng’iroqlarni o’zgartirishi, xosting jarayonini o’zgartirishi va yakuniy semantikani so’rashi mumkin.
Qo’llab-quvvatlanadigan versiyalar uchun allaqachon chiqarilgan to’liq tuzatishlar ustuvor hisoblanadi. O’z filiallarining migratsiyasi yamoqlar manbasini, tegishli asosiy ko’rsatkichlarni, nizolarni hal qilish va xatti-harakatlardagi o’zgarishlarni qayd etishi va tegishli regressiyadan foydalanish holatlaridan foydalanishi va ushbu biznes jarayonini tekshirishi kerak. Bu yerdagi takliflar ajratuvchi, VM, seans va soʻrovning hayotiy siklidagi oʻzgarishlar boʻyicha yamoq qamrovini tahlil qilishdan kelib chiqadi. S4S5
7. PHP 7.4, 8.0, 8.1 favqulodda yordam porti
PHP rasmiy ravishda jiddiylik darajasiga qarab uchta eski filialning minimal manba kodini taqdim etadi. Filial nomlari:
PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619Filial havolalari uchun qarang: S7S8S9. Bular ushbu zaiflik uchun favqulodda yetkazib berish bo’lib, eski filial uchun muntazam yuqori oqim qo’llab-quvvatlashiga qaytishni anglatmaydi va boshqa xavfsizlik yangilanishlarini almashtirmaydi. S1
7.1 Misol tariqasida PHP 8.1 backportini oling
PHP 8.1 uchun tegishli taqdimnomalar:
1d7dec178a094e6e75b229ce22754045f8c6070aUning strategiyasi muvaffaqiyatsizlikni qo’llab-quvvatlaydi: tegishli OOM yo’lida diagnostika chiqqandan so’ng _exit(1) ga qo’ng’iroq qilish va global holat va boshqa tegishli tuzatishlarni o’z ichiga oladi; seansni yuklash jarayoniga mos ishlov berishni ichki o’chirib qo’ygan holda. Tegishli manba kodini yuborish uchun S6 ga qarang.
Bu qo’llab-quvvatlanadigan filialda to’liqroq kechiktirilgan OOM dizaynidan xatti-harakatlarning farqidir. Konfiguratsiya hali ham yuklash jarayoni yoqilganligini ko’rsatganligi sababli, bu orqa portdan keyin ichki ishlov berish harakati o’zgarishsiz qoladi degani emas.
7.2 Joylashtirishda qabul qilishingiz kerak bo’lgan narx
Jarayondan to’g’ridan-to’g’ri chiqish joriy so’rovning bajarilmasligiga olib kelishi mumkin, oddiy PHP o’chirish qo’ng’iroqlarini va ilova yopilishining bir qismini o’tkazib yuborishi mumkin; agar xost ip modelini qabul qilsa, butun xost jarayonidan chiqishning boshqa parallel ishlarga ta’sirini ham baholash kerak. Jarayon menejeri almashtirish jarayonini o’z vaqtida boshlashi mumkinmi yoki yo’qmi, tekshirishga ham kiritilishi kerak.
Shuning uchun eski versiya foydalanuvchilari quyidagi tartibda e’tiborga olishlari kerak:
- Qo’llab-quvvatlanadigan PHP filialiga va uning sobit versiyasiga ko’chiring.
- CVE yoki LTS ishlab chiqaruvchi yangilanishini aniq qamrab oladigan nashrdan foydalaning.
- Agar u haqiqatan ham manba kodining eski versiyasiga tobe bo’lsa, to’liq o’zgarishlar va muvofiqlikni tekshirish va keyingi migratsiyani tashkil qilish uchun mos keladigan versiyaning rasmiy favqulodda yordam portidan foydalaning.
Bu yerda “minimal backport” amaldor tomonidan tanlangan muvofiqlik va amalga oshirish doirasini tavsiflaydi va avtomatik ravishda “maʼlum toʻliq boʻlmagan zaifliklarni tuzatish” deb talqin qilinmasligi kerak. Siz tegishli filialning manba kodi va ishlab chiqaruvchining e’loniga asoslanib hukm qilishingiz kerak va qo’llab-quvvatlovchi o’zgarishlarni o’zingiz o’chirmang. S1S6
8. Qabul qilish mezonlari va keyingi tekshiruvlar
Ushbu ta’mirlashni yakunlash uchun asos sifatida quyidagi natijalardan foydalanish tavsiya etiladi:
| Qabul qilish elementlari | To’ldirish standartlari |
|---|---|
| zaiflikni qoplash | Qurilish yoki sotuvchi e’lonlari CVE-2026-109618 va CVE-2026-109619 ni aniq tuzatadi |
| Joylashtirish qamrovi | Barcha portallar, hovuzlar, xizmatlar va nusxalar tuzatilgan ish vaqtidan foydalanadi |
| Jarayon kuchga kiradi | Eski ishchi, eski xost jarayoni va eski konteyner hammasi chiqadi |
| Haqiqiy so’rovni tekshirish | Tasdiqlangan SAPI, keshni noto’g’ri yo’naltirishni bartaraf etish uchun haqiqiy Web havolasi bilan qurilgan va sozlangan |
| biznesning mavjudligi | Seans, yuklash, import qilish va xatolarni qayta ishlash kabi asosiy funktsiyalar odatdagidek qaytdi. |
| Vaqtinchalik choralarni tugatish | Cheksiz xotira va ekstremal ishchi qayta ishlash konfiguratsiyalari sig’im rejasiga muvofiq tiklandi yoki saqlash uchun aniq sababga ega |
| O’zgarishlarning isboti | Paket versiyasini yoki tasvir dayjestini, yangilash ko’lamini, tugatish vaqti va tekshirish natijalarini yozib oling |
Yuqoridagilar amalga oshirish uchun tavsiyalardir. Agar siz OOM xatti-harakatini, g’ayritabiiy chiqishni yoki maxsus yamoqlarni tekshirishingiz kerak bo’lsa, qabul qilish usuli sifatida ishlab chiqarish muhitida qayta-qayta xotira charchashiga yo’l qo’ymaslik uchun izolyatsiyalangan muhitda yuqori oqim regressiyasi testidan yoki boshqariladigan nosozliklarni kiritishdan foydalanishingiz kerak.
Shuningdek, PHP halokatli, ishchi ishdan chiqishi, anormal qayta ishga tushirish, so’rov xatosi tezligi va yangilanishdan oldin va keyin WAF hodisalarini tekshiring. Jurnallar faqat tergov maslahatlarini berishi mumkin: OOM ning paydo bo’lishi uning ekspluatatsiya qilinganligini anglatmaydi va signallarning yo’qligi ekspluatatsiya sodir bo’lmaganligini isbotlamaydi. Yangilanish kelajakda erishish mumkin bo’lgan zaiflik yo’llarini tuzatadi; agar fayllarni buzish yoki hisob ma’lumotlarining sizib chiqishi kabi anomaliyalar aniqlansa, hodisa yuzasidan alohida tekshiruvlar o’tkazilishi kerak.
Ilova: keltirilgan manbalar va havolalar
Barcha manba havolalari quyida to’plangan. Maslahatlar, yamoqlar va sotuvchi bo’yicha ko’rsatmalar hozirgi paytdagi tekshiruvlarni aks ettiradi 2026 yil 22 oktyabr ; keyingi joylashtirishlar sotuvchi yangilanishlarini tekshirishi kerak. Matndagi raqamlangan iqtiboslar ushbu yozuvlarga tegishli.
S1 - PHP rasmiy xavfsizlik byulleteni va ta’mirlash versiyasi
- Manba: PHP loyihasi, 2026 yil 21 oktyabr.
- Maqsad: Xavf doirasi, to’rtta rasmiy ta’mirlash versiyasi, rasmiy vaqtinchalik choralar va eski filiallar uchun favqulodda vaziyatlar bo’yicha ko’rsatmalar.
- Manba: PHP 2026 This security bulletin yillik byulleten arxivida
S2 — CVE-2026-109618 rasmiy texnik byulleten
- Manba: php/php-src GitHub Security Advisory, 2026 yil 21 oktyabr.
- Identifikatsiya: GHSA-w8hw-w9fx-j79w.
- Maqsad: OOM uchun qamrov chegarasi, ko’p qismli kuchaytirish, SAPI farqi va yumshatish.
- Manba: RCE via OOM corruption
S3 — CVE-2026-109619 rasmiy texnik byulleten
- Manba: php/php-src GitHub Security Advisory, 2026 yil 21 oktyabr.
- Identifikatsiya: GHSA-6wmf-4rv5-p3rp.
- Maqsad: o’zaro so’rovning osilgan holati, ishlab chiqaruvchilar va iste’molchilar, erta ishga tushirish, konfiguratsiyani yumshatish.
- Manba: RCE via stale global state
S4 - PHP 8.5 rasmiy tuzatish taqdim etish
- Manba: php/php-src.
- Yuborish:
31c0ea7d7ff1d1fccb6492e52dab544011628065. - Maqsad: Bir vaqtning o’zida ikkita zaiflikni tuzatish uchun rasmiy topshirishni tasdiqlang va umumiy o’zgarish yo’nalishini tushuntiring.
- Manba: Avoid state corruption via bailout
S5 — PHP 8.5 Rasmiy tiklangan va toʻliq farq
- Manba: bir xil rasmiy taqdimnomadan farq.
- Maqsad: ajratuvchi, VM, HTTP globals, seans, ketma-ketlashtirish va so’rovning hayot aylanishining maxsus bajarilishini tekshiring.
- Manba: official complete diff
S6 — PHP 8.1 rasmiy favqulodda vaziyat portini taqdim etish
- Manba: php/php-src.
- Yuborish:
1d7dec178a094e6e75b229ce22754045f8c6070a. - Maqsad: Eski filiallarning tez chiqishini tekshiring va o’zgarishlar xatti-harakatlarini yuklang.
- Manba: PHP 8.1 Emergency backport submission
- Manba: corresponds to complete diff
S7 — PHP 7.4 rasmiy favqulodda yordam porti filiali
- Manba: rasmiy xavfsizlik byulletenida keltirilgan php/php-src, PHP manba kodi filiallari.
- Manba: PHP-7.4-CVE-2026-109618-109619
S8 — PHP 8.0 rasmiy favqulodda yordam porti filiali
- Manba: rasmiy xavfsizlik byulletenida keltirilgan php/php-src, PHP manba kodi filiallari.
- Manba: PHP-8.0-CVE-2026-109618-109619
S9 — PHP 8.1 rasmiy favqulodda yordam porti filiali
- Manba: rasmiy xavfsizlik byulletenida keltirilgan php/php-src, PHP manba kodi filiallari.
- Manba: PHP-8.1-CVE-2026-109618-109619
S10 — Ubuntu Xavfsizlik byulleteni USN-8948-1
- Manba: Canonical / Ubuntu, 2026 yil 21 oktyabr.
- Maqsad: Backport va to’liq paket versiyasi misollarini chiqarish.
- Manba: USN-8948-1: PHP vulnerabilities
S11 — PHP-FPM Configuration qo’llanma
- Manba: PHP rasmiy hujjati.
- Maqsad:
php_admin_value,php_admin_flag,pm.max_requestsva boshqalar kabi konfiguratsiya semantikasi. - Manba: PHP-FPM Configuration
S12 - PHP yadro INI konfiguratsiya qo’llanmasi
- Manba: PHP rasmiy hujjati.
- Maqsad: So’rovning ta’rifi va hajmi, yuklash, xotira va avtomatik POST o’qish konfiguratsiyasi.
- Manba: Description of core php.ini directives
S13 — Nginx so‘rovi tana o‘lchami chegarasi
- Manba: Nginx rasmiy hujjati.
- Maqsad:
client_max_body_sizema’nosi va mavjud konfiguratsiya darajalari. - Manba: ngx_http_core_module / client_max_body_size
S14 — Nginx FastCGI so’rov buferi
- Manba: Nginx rasmiy hujjati.
- Maqsad:
fastcgi_request_bufferingning qayta ishlash ketma-ketligi va funktsiyasi. - Manba: ngx_http_fastcgi_module / fastcgi_request_buffering
S15 — Nginx Vaziyat va qaytarish bo’yicha ko’rsatmalar
- Manba: Nginx rasmiy hujjati.
- Maqsad:
ifvareturnkonfiguratsiya sintaksisi. - Manba: ngx_http_rewrite_module
S16 — Cloudflare PHP2Shell himoya qilish bo’yicha ko’rsatmalar
- Manba: Cloudflare rasmiy blogi.
- Maqsad: WAF joylashtirish doirasi tavsifi, Free rejasini tartibga solish va aniqlash mexanizmi.
- Manba: Cloudflare deploys protections against php2shell vulnerability