PHP xavfsizlik yangilanishi 2026: PHP2Shell CVSS 9.2 tuzatish qo'llanmasi

Ma'lumot e'lon qilinishining o'zi g'ayrioddiy kechdi. 20-oktabr kuni PHP xavfsizlik jamoasi oldindan ogohlantirish berdi, relizni 21-oktabr soat 14:00 UTCga belgiladi va uni rejalashtirilgan vaqtdan ilgari chiqarish huquqini o'zida saqlab qoldi. CVE identifikatorlari e'londan bir kun oldin oshkor bo'lib ketdi, ularga zarar darajasi va ta'sir etilgan versiyalar haqidagi bo'rttirilgan da'volar ham qo'shildi. Distributivlar o'z paketlari uchun patchlarni allaqachon olgan edi, milliy CERTlar esa kod hali ommaga chiqmasidan turib tavsiyalar e'lon qila boshlagan edi. Boshqacha aytganda: reliz chiqishi bilanoq kechiktirish uchun hech kimda qonuniy bahona qolmagan edi.

Ikki zaiflik, bitta favqulodda reliz

Ikkala xatolik ham ilovadagi mantiqiy xato emas. Ikkalasi PHP so'rovni tayyorlash va yakunlash tartibida yotadi — shu sababli hech qanday freymvork yangilanishi, plagin yangilanishi yoki WAF qoidasi interpretatorni yangilashning o'rnini bosolmaydi.

CVE-2026-109618 — xotira tugashi natijasidagi buzilish orqali RCE. PHP xotirasi tugaganda so'rovni davom ettirmasdan to'xtatadi. Bildirishnomada shunday yo'l tasvirlangan: bu to'xtatish PHP'ni ichki so'rov ma'lumotlari faqat qisman ishga tushirilgan holatda uzib qo'yadi, natijada keyingi so'rovni tozalash bosqichi yaroqsiz ma'lumotni yaroqli deb qabul qiladi. Xotira ishlatilishini chegaragacha yetkaza oladigan hujumchi shu tarzda keyingi jarayonlarga yo'l ko'rsatishi mumkin. Aynan shu zaiflik mitigatsiya maslahatini intuitivga zid qiladi: ishlab chiqaruvchi administratorlardan PHP'ning o'z xotira chegarasiga yetib olishiga to'sqinlik qilishni, uni siqishni emas, so'raydi.

CVE-2026-109619 — eskirgan global holat orqali RCE. Bir so'rovga tegishli ichki holat, uning ostidagi xotira bo'shatilgandan keyin ham saqlanib qolishi mumkin. Xuddi shu ishchi jarayonga tushgan keyingi so'rov, odatdagi ishga tushirish uni qayta tiklashidan oldin, shu eskirgan holatni ishlatib yuborishi mumkin. Uzoq yashovchi ishchi jarayonda — PHP-FPM, mod_php va LiteSpeed aynan shunday — xotiraning qayta ishlatilishi oddiy va doimiy holat, shuning uchun bu g'ayrioddiy konfiguratsiyalar uchungina ko'rinadigan chetki holat emas.

PHP2Shell nomi PHP loyihasining rasmiy yorlig'i emas; uni tadqiqotchilar va xavfsizlik kompaniyalari berdi va nom yopishib qoldi — shuning uchun siz uni skaner natijalarida, hosting byulletenlarida va CERT tavsiyalarida aynan shu ikki CVEga qaratilgan holda ko'rasiz.

Aslida kim xavf ostida

Bildirishnomada ochiq aytilgan: veb-so'rovlarga xizmat ko'rsatadigan barcha PHP o'rnatmalari xavf ostida. Bunga nginx yoki Apache ortidagi PHP-FPM, mod_php bilan Apache, php-cgi, LiteSpeed va FrankenPHP kiradi. Ular orasidagi farq — hujumchi qancha kuch sarflashi kerakligida.

Agar savdo biznesingiz uchun WordPress, WooCommerce, Laravel, Magento, Magento bilan integratsiyalashgan ERP tizimlari yoki boshqa har qanday PHP bron qilish portalini yuritsangiz, ilova kodi mukammal bo'lsa-da birinchi uch qatorga kirasiz. Runtime'ni birinchi navbatda kim o'z qo'liga olishi kerak degan savol bo'yicha kengroq mulohaza uchun Türkiyada IT autsorsing bo'yicha qo'llanmamizga murojaat qiling.

Versiyangizni ikki daqiqada tekshiring

Bu yerdagi tuzoq — versiya arifmetikasi. Distributivlar PHP 8.3.6 yoki 8.2.x'ni yillar davomida yetkazib beradi hamda xavfsizlik tuzatishlarini xuddi shu ko'rinadigan versiya raqamiga bekport qiladi, shuning uchun php -v yolg'iz o'zi siz himoyalanganingizni ko'rsatmaydi. Uchta narsani solishtiring.

1. Ko'rinadigan PHP versiyasi va trafikka xizmat ko'rsatayotgan SAPI.

2. Upstream versiyasi emas, distributiv paketining versiyasi. Debian va Ubuntuda halol javob — changelog; RPM tizimlarida esa paket changelog'ini so'rab ko'ring.

Agar changelog o'rnatilgan versiyada ikkala CVEni ham tilga olsa, php -v baribir 8.3.6 deb ko'rsatasa-da, siz patchlangansiz. Mana shu — haqiqiy xavfsizlik javobi bilan versiya raqamiga bo'lgan xurofiy ishonch o'rtasidagi farq.

3. Ishlayotgan jarayon patchlangan binarni qaytadan yuklaganmi. Qayta ishga tushirish bilan yakulanmagan paket yangilanishi eski kodni xotirada saqlab qoladi. Xizmatning ishga tushgan vaqtini paket o'rnatilgan vaqti bilan solishtiring:

cPanel, Plesk, DirectAdmin yoki boshqariladigan platformada bunga teng amal — PHP selektori va hosting beruvchining xavfsizlik byulleteni: panelda e'lon qilingan eng yangi versiyani emas, saytingiz haqiqatan ishlatayotgan ichki versiyani aniqlang. Agar hosting beruvchingiz patch sanasini ayta olmasa, saytni patchlanmagan deb hisoblang. Bizning raqamli infratuzilma xizmatlarimiz shu auditni ham, yangilashning o'zini ham qamrab oladi; yoki shunchaki stack'ingiz bilan biz bilan bog'laning — biz nimalarni tekshirishimizni aytib beramiz.

Tuzatilgan versiyalar va qo'llab-quvvatlashning tugashi

PHP har bir shoxni ikki yil faol rivojlantirish va undan keyin yana ikki yil xavfsizlik tuzatishlari bilan qo'llab-quvvatlaydi. Aynan shu siyosat 21-oktabr kuni to'rtta bir vaqtdagi tuzatishni berdi — va aynan shu siyosat eski shoxlarni o'z taqdiriga tashlab qo'yadi.

Bildirishnomadan ikkita amaliy ogohlantirish. Birinchidan, PHP'ni distributivdan emas, jamoatchilik repozitoriyasidan o'rnatganingizda, bu repozitoriya xavfsizlik oynasidan orqada qolishi mumkin: keng qo'llaniladigan Remi paketlarini yurituvchilar aynan shu kunga yangilanishlar bo'lmaydi degan edilar, shuning uchun xavfsiz yo'l — distributiv paketlaringiz yoki manbadan yig'ish. Ikkinchidan, PHP 8.1 yoki undan eskisida tursangiz, «hostingimizni kutamiz» degan qaror — mijozlaringiz nomidan qabul qilayotgan xavfsizlik qaroringizdir; uni hujjatlashtiring yoki o'zgartiring.

Production-serverni hodisasiz patchlash

Bir minor ichidagi xavfsizlik yangilanishlari ilovani kamdan-kam buzadi; sinovdan o'tmagan qayta ishga tushirishlar buzadi. Quyidagi tartib — biz jonli savdo platformalarida qo'llaydigan tartib: u saytni tavakkalga qo'ymasdan xavf oynasini qisqa saqlaydi.

1. Avval snapshot oling. Qayta tiklashni haqiqatda sinab ko'rilgan gipervizor yoki hajm snapshoti bir necha daqiqada tiklanadi — va bu patchlash qarorini arzonlashtiradi.
2. Versiyani stagingda takrorlang. Bir xil shox, bir xil kengaytmalar, bir xil PHP konfiguratsiya fayllari, production ma'lumotlarining nusxasi. Faqat bosh sahifani emas — xaridni yakunlash, so'rov yuborish va to'lov yo'llarini ham sinab ko'ring.
3. Paketlar to'plamini bir butunlikda yangilang. Yangilangan CLI bilan eski FPM binarini aralashtirib yuborish — odamlarning patchlangan php -v natijasi va patchlanmagan veb-yo'li bilan qolib ketishining odatiy sababi: apt-get update && apt-get install --only-upgrade 'php8.3-*' yoki RPM hostlarda dnf update --security 'php*'.
4. So'rovga xizmat ko'rsatayotgan jarayonni qayta ishga tushiring, so'ng qayta ishga tushganiga ishonch hosil qiling. systemctl restart php8.3-fpm (yoki Apache'ni reload qiling / LiteSpeed'ni qayta ishga tushiring), so'ng xizmatning ishga tushgan vaqtini yana tekshirib, versiya va changelog so'rovlarini yana bir bor bajaring.
5. Xato jurnalini bir soat kuzatib turing. OOM xabarlari, yangi fatal-xato izlari va g'ayrioddiy 5xx ulushi — quyidagi mitigatsiya sozlamalarini moslashtirish kerak bo'lishi mumkinligining belgisi, yangilashni keyinga surish uchun bahona emas.
6. Dalillarni yozib qoldiring. Paket versiyasi, ikkala CVEni tilga olgan changelog qatori, qayta ishga tushirish vaqti. Mijozlar, auditorlar va ISO 27001 uslubidagi nazorat tekshiruvlari aynan shularni so'raydi — va ularni saqlab qo'yish o'n sekund vaqt oladi.

Yangilashni keyinga surish shart bo'lganda — tasdiqlangan ERP integratsiyasi, relizlarga taqiq qo'yilgan kalendari yoki mijoz tasdiqlash jarayoni tufayli — portni ochiq qoldirib umid qilishning o'rniga shu kunning o'zida oldinga qoplovchi nazorat chorasini qo'ying. Milliy CERTlarning tavsiyalari aynan shu holat uchun xuddi shuni aytdi: darhol patchlash imkonsiz bo'lsa, internetga qaragan PHP ilovalarini ommaviy tarmoqdan ajratib oling.

Vaqtinchalik himoya: oynani toraytiradi, yopmaydi

PHP bildirishnomasi shuni ochiq aytadiki, to'liq mitigatsiya mavjud emas va yagona xavfsiz tanlov — yangilash. Quyidagilarga kunlar — haftalar emas — hisobidagi qoplama sifatida qarang, ilova bekor qila olmaydigan darajada qo'llang va keyin barcha ishchilarni qayta ishga tushiring.

CVE-2026-109618 ga qarshi (xotira tugashi yo'li)

• PHP o'z chegarasida emas, mashinaning xotirasida tugashiga yo'l qo'ying: memory_limit = -1, afzalrogi php_admin_value memory_limit = -1 ko'rinishida — shunda ilova kodi shipni qayta qo'yib qo'ya olmaydi.
• So'rov tanalarini interpretator oldida kichik ushlab turing: bildirishnoma tavsiyasi — yuklamalar bo'lmasa taxminan 8 MB, bo'lsa taxminan 32 MB atrofida, upload_max_filesize esa post_max_size dan past bo'lsin.
• Qimmat cheklovlarni proksida majburiy qiling, chunki zarar kanal hajmida emas, ochilgan so'rov ichida yotadi: ochilgan tananing umumiy hajmi, kiritish maydonchalari soni, multipart qismlar soni, sarlavhalar soni, ichma-ichlik chuqurligi — va ishlatib bo'lmaydigan Content-Length bilan kelgan so'rovlarni ham qamrab oling.
• Portlash radiusini konteyner yoki cgroup xotira chegarasi bilan cheklang, hajmini shunday tanlangki, o'ldirilgan ishchi — butun host hodisasi emas, mavjudlik hodisasi bo'lib qolsin. RLIMIT_AS yoki RLIMIT_DATA ni o'rnini bosuvchi qilib qo'ymang: ular aynan zaif yo'lga tegishli taqsimot muvaffaqiyatsizligini keltirib chiqaradi.

CVE-2026-109619 ga qarshi (eskirgan holat yo'li)

• Sessiya yuklanish kuzatuvi funksiyasini session.upload_progress.enabled = 0 bilan o'chirib qo'ying — php.ini, FPM pool yoki server konfiguratsiyasida, so'rov tahlil qilinishidan oldin kuchga kiradigan joyda. So'ng barcha ishchilarni qayta ishga tushiring, chunki FPM ishga tushirilgan modul holatini so'rovlar orasida bo'lib ishlatadi. ini_set() va .user.ini esa yordam berish uchun juda kech qoladi.
• PHP 8.5'da fatal_error_backtraces = 0 qo'yib qayta ishga tushiring.
• Dastlabki ishga tushirish paytida diagnostika chiqaradigan yaroqsiz yoki eskirgan so'rovga tegishli sozlamalarni olib tashlang. Xabarni error_reporting, display_errors yoki @ bilan yashirish kod yo'lini olib tashlamaydi.
• Hujumchi yetib oladigan fatal xatoliklarni va uzoq davom etuvchi timeoutlarni yuklash hamda import funksiyalarida, callback kodlarida va tozalash tartiblarida qidiring — ikkala xatolik yashaydigan joylar aynan shular.

Originni oldida turgan CDN yoki WAF baribir foyda beradi: chastotani cheklash, g'ayrioddiy so'rov shakllarini bloklash va virtual patchlash shovqinni kamaytiradi, tasodifiy skanerlashni sekinlashtiradi. Ular maqsadli hujumchi uchun yo'ldagi to'siqdir, tuzatish sifatida imzo qo'yiladigan nazorat chorasi emas.

Bugun hosting beruvchingizdan nima so'rash kerak

Yordam xizmatining tayyor javoblari bu savolga «biz doimo patchlanganmiz» deydi. Buning o'rniga faylga qo'yib qo'yadigan dalil so'rang:

• Bizning hisobimizga biriktirilgan ichki PHP versiyasi va uning distributiv paketimi yoki ishlab chiqaruvchi yig'imi ekanligi
• CVE-2026-109618 va CVE-2026-109619 tuzatishlari serverlaringiz parkiga qachon yetib kelgani — ichki paket versiyasi qatori bilan birga
• Tuzatish saytimizga xizmat ko'rsatayotgan SAPIga (FPM, LiteSpeed, mod_php) hamda tiklashi mumkin bo'lgan istalgan staging yoki zaxira tugunga tegishlimi
• Agar platforma hali patchlanmagan bo'lsa: qanday qoplovchi nazorat joriy etilgan va qachongacha
• Qo'llab-quvvatlashi tugaydigan shoxlar bo'yicha doimiy siyosatingiz — PHP 8.2 xavfsizlik qo'llab-quvvatlashi to'xtagan 2027-yil 1-yanvarda saytim bilan nima bo'ladi

Bu besh savolga bitta elektron xatda javob beradigan provayderni saqlab qolishga arziydi. Marketing matni bilan aylanib qaytgan provayder esa ko'chish haqidagi suhbatning boshlanishi; xuddi shu sinchkovlik bizning ISO 27001 tafovut baholash ishlarimizda ham qo'llanadi — u yerda yetkazib beriladigan narsa ishonchlantirish emas, dalildir.

Buzilgan deb hisoblash kerakmi?

Avtomatik tarzda emas — lekin taxmin qilmang, tekshiring: ayniqsa server patchdan oldingi oyna davomida ommaviy internetga ochiq turgan bo'lsa.

• Siz yaratmagan jarayonlar, tinglayotgan portlar va cron yozuvlarini hamda PHP ishchi foydalanuvchisidan chiqayotgan tashqi ulanishlarni qidiring.
• Yozish mumkin bo'lgan ilova papkalarini haqiqiy joylashtirish manbasi bilan solishtiring: yangi PHP fayllari, o'zgargan yuklash papkalari, kutilmagan holda bajariladigan vaqtinchalik papkalar.
• Veb-jurnallarda e'lon soatlaridagi so'rov to'lqinlarini, odatdan tashqari katta multipart tanalarni yoki PHP xato jurnalida OOM izlari bilan 500 qaytargan so'rovlarni qidiring.
• Patchlangan binar haqiqatan ishlayotganini tekshiring — yuqoridagi ishga tushirish vaqtini solishtirish bunga javob beradi.
• Biror narsa shubhali ko'rinsa, uni hodisa sifatida qarang: diskni va jurnallarni asrab qo'ying, ilova o'qiy oladigan har bir kirish ma'lumotini almashtiring va ma'lum bo'lgan yaxshi tasvirdan qayta quring. Buzilgan host ustiga PHP paketini qayta o'rnatish tuzatish emas.

O'z infratuzilmamizdan olingan amaliy misol

worldwidetradex.com saytini biz Ubuntu 24.04 LTS, nginx va PHP-FPM ustida yuritamiz, shuning uchun yuqoridagi tekshiruvlarni 22-oktabr kuni o'z serverimizda o'tkazdik. Natijalar versiya arifmetikasi nima uchun muhimligini yaxshi ko'rsatadi:

Saboq har qanday stackka o'tadi: xavfsizlik holatingiz — hosting panelidagi marketing versiya qatori emas, paket versiyasi, changelog va qayta ishga tushirishdir.

Patchlashni qahramonlik ishidan kundalik ishga aylantiring

PHP2Shell ekzotik bo'lgani uchun emas — vebning katta qismi ishlab turgan interpretatorda muhim, autentifikatsiyadan oldingi xatolik chiqqani va minglab hostlar bir necha soat ichida javob berishi kerak bo'lgani uchun esda qoladi. Bu oyni tinch uyqu bilan o'tkazgan jamoalar omadli emas edi — ularning avtomatlashtirishi bor edi.

• Interpretator uchun nazoratsiz xavfsizlik yangilanishlari — versiya va qayta ishga tushirish avtomatik yozib boriladigan tarzda.
• Har bir sayt qaysi SAPI va qaysi PHP shoxidan foydalanishini biladigan inventarizatsiya — staginglar, zaxiralar va 2019-yildagi o'sha bir dona WordPress ham ichida.
• Oldindan mashq qilingan qayta tiklash yo'li, shunda «hozir patchlang» degan talab hech qachon «orqaga qaytira olmaymiz» degan xavotir bilan tortib ko'rilmasin.
• Shoxlar rejasi: xavfsizlik qo'llab-quvvatlashi keyingi o'n ikki oy ichida tugaydigan PHP relizida hech narsa ishlamasligi kerak.
• Har bir server uchun nomlangan bitta mas'ul va patch chershanba kuni soat 14:00 UTCda tushadigan kunlar uchun yozma eskalatsiya marshruti.

Agar bu imkoniyatni xodimlar bilan qurish o'rniga sotib olishni afzal ko'rsangiz, biz production PHP platformalarini — patch jadvali, monitoring, zaxiralar va hujjatlashtirilgan qayta tiklashlar — boshqariladigan infratuzilma xizmatimiz doirasida o'z zimmamizga olamiz. Qisqa tavsif va miqdorlar bilan boshlang: so'rov yuboring.

Ko'p so'raladigan savollar

Manbalar

• PHP — «Critical remote code execution vulnerabilities, update now» xavfsizlik bildirishnomasi va 2026-yil 21-oktabrdagi reliz e'lonlari, jumladan mitigatsiya tavsiyalari hamda qo'llab-quvvatlanadigan versiyalar sahifasidagi qo'llab-quvvatlash jadvali.
• PHP repozitoriyasi uchun GitHub Security Advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) va GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Security Advisory 2026-018, «Critical Vulnerabilities in PHP», ikkala CVEni nomlaydi.
• Infosecurity Magazine — «Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches» (2026-yil 21-oktabr) va «PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure» (2026-yil 22-oktabr).

Yangilash sizning uchun bajarib berilsinmi? Patchlash, versiya auditi, boshqariladigan va patchlangan PHP platformasiga ko'chish yoki uning atrofidagi infratuzilma bo'yicha maslahat uchun biz bilan bog'laning yoki +90 505 679 78 03 raqamiga qo'ng'iroq qiling.