PHP CVE-2026-109618 va CVE-2026-109619: serverni bosqichma-bosqich yangilash

2026-yil oktyabr oyida milliy kiberxavfsizlik markazi PHP'dagi ikki zaiflik — CVE-2026-109618 va CVE-2026-109619 — haqida ogohlantirish e'lon qildi. Ular PHP asosida ishlaydigan veb-saytlar, axborot tizimlari, boshqaruv panellari va boshqa servislarga taalluqli. PHP-FPM, Apache mod_php va boshqa PHP muhitlari tekshirilishi kerak.

Bu maqolada ogohlantirishdagi tavsiyalarni amaliy qadamlarga aylantiramiz va real serverlarni yangilash paytida o'zimiz duch kelgan tuzoqlarni ko'rsatamiz. Ular oddiy ko'rinadi, lekin aynan ular tufayli "yangiladik" deb hisoblangan server aslida eski, zaif PHP bilan ishlashda davom etadi.

Nima ma'lum va nima noma'lum

Tuzatilgan versiyalar (yoki shu tarmoqdagi undan keyingi versiyalar):

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Agar PHP distributiv paketlaridan (Ubuntu, Debian, RHEL va boshqalar) o'rnatilgan bo'lsa, versiya raqami boshqacha bo'lishi mumkin: distributivlar tuzatishni eski versiya raqamiga "backport" qiladi. Bunday holatda tuzatish o'rnatilganini distributiv ishlab chiqaruvchisining xavfsizlik bildirishnomasi orqali tasdiqlash kerak.

Bizning manbalarimizda zaifliklarning texnik tafsilotlari ochiq e'lon qilinmagan. Shuning uchun ularning mexanizmi haqida taxmin qilmaymiz. Amaliy xulosa bitta: PHP ishlaydigan har bir tizimni topish, yangilash va yangilanish haqiqatan ishga tushganini tasdiqlash kerak.

Paketni yangilash — ishning yarmi. Qolgan yarmi — eski jarayonlar to'xtatilib, yangi binar fayl ishlayotganini tekshirish.

Nima uchun bu ekspertiza uchun muhim

Rasmiy kiberxavfsizlik ekspertizasi dasturiy ta'minot versiyalarini ham tekshiradi. Server ma'lum zaifligi e'lon qilingan PHP versiyasida ishlayotgan bo'lsa, bu hisobotda alohida topilma bo'ladi. Bundan tashqari, ko'p serverlar PHP versiyasini o'zi oshkor qiladi: X-Powered-By: PHP/8.3.x headeri orqali. Bu ham ma'lumot ochiqlanishi sifatida qayd etiladi va tekshiruvchiga versiyani bir qarashda aniqlash imkonini beradi.

Ekspertizaga topshirishdan oldin PHP'ni yangilash va versiyani yashirish — eng arzon va tez yopiladigan topilmalardan biri.

1-qadam: barcha PHP o'rnatmalarini toping

Avval inventarizatsiya. Internetga ochiq tizimlardan boshlang: veb-saytlar, portallar, boshqaruv panellari. Bitta serverda bir nechta PHP bo'lishi odatiy hol, va ularning hammasi bitta paket menejeri orqali o'rnatilmagan bo'ladi.

# Paket menejeri orqali o'rnatilganlar
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
dpkg -l | grep -E '^ii\s+(php|lsphp)' | awk '{print $2, $3}'
rpm -qa | grep -Ei '^(php|lsphp)'          # RHEL/Alma/Rocky

# Panel o'zi kompilyatsiya qilgan PHP (aaPanel uslubidagi panellar)
ls -d /www/server/php/*/ 2>/dev/null

# OpenLiteSpeed lsphp
ls -d /usr/local/lsws/lsphp*/ 2>/dev/null

# Hozir ishlab turgan PHP jarayonlari
ps -eo pid,user,cmd | grep -E 'php-fpm|lsphp|apache2|httpd' | grep -v grep

Konteynerlar uchun:

docker ps --format '{{.Names}}  {{.Image}}'
docker exec <konteyner> php -v

Natijani jadvalga yozing: server, PHP manbasi (apt, panel, LiteSpeed, konteyner), versiya, qaysi sayt ishlatadi, internetga ochiqmi.

2-qadam: aynan qaysi PHP ishlayotganini aniqlang

Bu yerda birinchi tuzoq bor. php -v buyrug'i faqat CLI versiyasini ko'rsatadi — ya'ni PATH dagi birinchi php binarini. Saytni esa PHP-FPM, mod_php yoki lsphp xizmat qiladi va ular butunlay boshqa versiya bo'lishi mumkin.

To'g'ri usul — ishlayotgan master jarayonning binar faylini ko'rish:

pgrep -a php-fpm
# 1234 php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)

ls -l /proc/1234/exe
# /proc/1234/exe -> /usr/sbin/php-fpm8.3

/usr/sbin/php-fpm8.3 -v

Panel PHP'si uchun ham xuddi shunday: ls -l /proc/<pid>/exe sizga /www/server/php/83/sbin/php-fpm kabi yo'lni ko'rsatadi va aynan shu binar versiyasini tekshirish kerak.

Agar ls -l /proc/<pid>/exe natijasi oxirida (deleted) yozuvi bo'lsa, bu muhim belgi: paket yangilangan, diskdagi fayl almashtirilgan, lekin xotirada hali eski binar ishlab turibdi. Bunday jarayon qayta ishga tushirilmaguncha zaiflik yopilmagan hisoblanadi.

3-qadam: har bir manba bo'yicha yangilang

Distributiv paketlari (apt, dnf)

# Debian/Ubuntu
apt update
apt install --only-upgrade 'php8.3*'

# Tuzatish o'rnatilganini changelog orqali tasdiqlash
apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'

# RHEL va hosilalari
dnf update 'php*'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

Agar PHP uchinchi tomon repozitoriysidan o'rnatilgan bo'lsa, odatda u yerda versiya raqamlari rasmiy PHP versiyalariga mos keladi va yuqoridagi ro'yxat bilan to'g'ridan-to'g'ri solishtirish mumkin.

Panel kompilyatsiya qilgan PHP

aaPanel uslubidagi panellar PHP'ni o'zi manba koddan yig'adi va /www/server/php/83 kabi papkalarga joylaydi. apt upgrade bu nusxaga umuman tegmaydi. Server egasi apt yangilanishini o'tkazib, "hammasi yangilandi" deb o'ylashi mumkin, sayt esa panel PHP'sida ishlashda davom etadi.

Bunday PHP panelning o'z dasturiy ta'minot menejeri orqali yangilanadi yoki qayta kompilyatsiya qilinadi. Keyin binar versiyasini bevosita tekshiring:

/www/server/php/83/bin/php -v
/www/server/php/83/sbin/php-fpm -v

OpenLiteSpeed va lsphp

OpenLiteSpeed o'zining lsphp paketlari bilan keladi (lsphp83, lsphp84 va hokazo). Ular LiteSpeed repozitoriysidan yangilanadi, odatiy php8.3-* paketlari bilan bog'liq emas:

apt install --only-upgrade 'lsphp83*'
systemctl restart lsws
ps -eo pid,lstart,cmd | grep lsphp | grep -v grep

Oxirgi buyruq orqali lsphp jarayonlari qayta ishga tushirilgandan keyin boshlanganini tekshiring — eski jarayon qolib ketmagan bo'lishi kerak.

Konteynerlar

Konteynerni qayta ishga tushirish yetarli emas: u eski image'dan ko'tariladi. Image'ni yangilangan bazaviy image'dan qayta yig'ish kerak:

docker build --pull --no-cache -t myapp:latest .
docker compose up -d --force-recreate
docker exec <konteyner> php -v

Dockerfile da FROM php:8.3-fpm kabi umumiy teg bo'lsa, --pull eng so'nggi patch versiyani olib keladi. Aniq versiya qotirilgan bo'lsa (php:8.3.20-fpm), tegni tuzatilgan versiyaga o'zgartiring.

Ishlatilmayotgan versiyalar

Yana bir tuzoq: serverda biror vaqt sinov uchun o'rnatilgan php8.1 yoki php8.5 CLI turibdi. Hech qaysi sayt uni ishlatmaydi, lekin u ham zaif va ekspertiza skanerlari uni topishi mumkin. Ikki yo'l bor: yangilash yoki o'chirish. O'chirishdan oldin cron vazifalari va skriptlar unga murojaat qilmasligini tekshiring:

grep -rE 'php8\.1|php8\.5' /etc/cron* /var/spool/cron 2>/dev/null
apt purge 'php8.1*'

4-qadam: qayta ishga tushiring va tasdiqlang

Paket yangilangandan keyin PHP xizmatlari va worker jarayonlari qayta ishga tushirilishi shart:

systemctl restart php8.3-fpm        # yoki panel PHP'si uchun panel xizmati
systemctl restart apache2           # mod_php ishlatilsa
systemctl restart supervisor        # Laravel queue va boshqa worker'lar

Queue worker'lar, uzoq ishlaydigan PHP skriptlari va daemon'lar ham alohida jarayon — ular ham eski binar bilan qolib ketishi mumkin. Keyin tekshiring:

for p in $(pgrep -f 'php'); do ls -l /proc/$p/exe; done | grep deleted

Bu buyruq hech narsa chiqarmasligi kerak. Debian/Ubuntu'da needrestart utilitasi ham eski kutubxonalar bilan ishlayotgan xizmatlarni ko'rsatadi.

Va nihoyat, versiya headerini yoping. php.ini da:

expose_php = Off

nginx orqasida qo'shimcha ravishda fastcgi_hide_header X-Powered-By; qo'yish mumkin.

Darhol yangilab bo'lmasa

Ba'zan yangilashni darhol qilib bo'lmaydi: eski ilova yangi versiyada ishlamaydi yoki o'zgarishlar oynasi kerak. Bunday holatda:

• Tizimga tashqi kirishni vaqtincha cheklang — masalan, admin panelni faqat ichki tarmoq yoki VPN orqali ochiq qoldiring.
• Ishlab chiqaruvchi tavsiya qilgan vaqtinchalik choralarni qo'llang.
• WAF filtrlarini yoqing.

Lekin buni aniq tushunish kerak: WAF filtrlari va vaqtinchalik sozlamalar zaiflikni to'liq yo'q qilmaydi. Ular faqat vaqt yutish uchun. Yangilash rejasi va muddatini aniq belgilang.

Loglarni tahlil qiling

Yangilash bilan bir qatorda server avval zaiflikdan foydalanilganmi, yo'qmi, tekshirib chiqing. Veb-server, PHP va xavfsizlik loglarida shubhali so'rovlarni, ruxsatsiz fayl o'zgarishlarini va kutilmagan jarayonlarni qidiring:

# Yaqinda o'zgargan yoki yaratilgan PHP fayllar
find /var/www -name '*.php' -newermt '2026-10-01' -ls

# uploads kabi papkalardagi PHP fayllar
find /var/www -path '*uploads*' -name '*.php'

# Veb-server foydalanuvchisi nomidan ishlayotgan jarayonlar
ps -u www-data -o pid,lstart,cmd

# PHP jarayonlarining tashqi ulanishlari
ss -tnp | grep -E 'php|lsphp'

Access log'da notanish .php fayllarga POST so'rovlari, g'ayrioddiy uzun parametrlar, bir manzildan qisqa vaqtda ko'p xato javoblar — e'tibor beriladigan belgilar.

Agar hodisa belgilari topilsa, birinchi navbatda loglarni va dalillarni saqlang (nusxa oling, hech narsani o'chirmang) va Markazga xabar bering. Buzilgan saytni tozalash qanday ko'rinishini WordPress backdoor tahlili maqolasida batafsil ko'rsatganmiz.

Qisqa checklist

1. Barcha serverlardagi PHP o'rnatmalari ro'yxatga olingan: apt/dnf, panel, lsphp, konteynerlar.
2. Har bir saytni qaysi PHP binari xizmat qilishi /proc/<pid>/exe orqali aniqlangan.
3. Versiyalar 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 yoki undan yuqori, distributiv paketlarida esa tuzatish bildirishnoma orqali tasdiqlangan.
4. Ishlatilmayotgan PHP versiyalari yangilangan yoki o'chirilgan.
5. PHP-FPM, Apache, lsws va worker'lar qayta ishga tushirilgan, (deleted) binarlar qolmagan.
6. Konteynerlar yangi image'dan qayta yig'ilgan.
7. expose_php = Off, X-Powered-By headeri yo'q.
8. Yangilab bo'lmaydigan tizimlarga tashqi kirish vaqtincha cheklangan va yangilash muddati belgilangan.
9. Loglar tahlil qilingan, shubhali fayl va jarayonlar tekshirilgan.

Xulosa

Bu zaifliklarni yopish texnik jihatdan murakkab emas, lekin real serverlarda PHP odatda bir nechta joyda turadi va ularning bittasi e'tibordan chetda qolsa, server zaifligicha qoladi. Inventarizatsiya, yangilash, qayta ishga tushirish va tasdiqlash — to'rtta qadamning hammasi bajarilishi kerak.

Serveringizda qaysi PHP haqiqatan ishlayotganini va boshqa ochiq qolgan joylar bormi, aniqlamoqchimisiz? Skanerlash uchun ariza qoldiring — Claude AI agenti va mutaxassisimiz server sozlamalarini ko'rib chiqadi, topilgan teshiklarni yopishga va ekspertizaga tayyorlanishga yordam beramiz.