Таңертең поштаға DigitalOcean-нан тақырыбында «URGENT» деген белгісі бар хат келеді. Хаттың басында PHP-дегі екі критикалық осалдық туралы айтылған: екеуі де қашықтан код орындауға (RCE) мүмкіндік береді, ал нөмірлері CVE-2026-109618 және CVE-2026-109619. Мұндай хатты «кейін қараймыз» деп қалдыруға болмайтын сәттер болады, және бұл - солардың бірі. PHP әлемдегі сайттардың өте үлкен бөлігінің негізінде тұр, ал мұндай осалдық сайтқа кіру үшін логин мен парольді де қажет етпейді.
Бұл мақалада не болғанын, осалдықтардың мәні неде екенін, оларға қарсы нақты қандай шаралар бар екенін және біздің команда жағдайды бір күн ішінде қалай жапқанын баяндаймыз. Мақсат - өз сайтыңыз бен серверіңізді тексеру үшін нақты бағдар беру және мұндай жағдайда бизнес қалай әрекет етуі керек екенін көрсету.
Не болды
2026 жылғы 21 қазанда PHP жобасы PHP 8.5.12, 8.4.27, 8.3.36 және 8.2.35 нұсқаларын шығарды. Бұл - қауіпсіздік жаңартулары, олар екі критикалық осалдықты жабады: CVE-2026-109618 және CVE-2026-109619. PHP өзі екеуін де аутентификациясыз қашықтан код орындауға әкелуі мүмкін осалдықтар ретінде сипаттап, барлық пайдаланушыны дереу жаңартуға шақырды. Осалдықтарға жиі PHP2Shell деген атау беріледі, ал қауіптілік деңгейі екеуіне де CVSS v4.0 шкаласы бойынша 9,2 болып бағаланған, яғни критикалық аумақта.
Бізге хабарлама хостинг-провайдерден келді. DigitalOcean өз клиенттеріне жағдайды ескертіп, жаңартуды шұғыл жүргізуді сұрады. Бұл жерде маңызды нәрсе: осалдық белгілі болғаннан кейін көп ұзамай оны пайдалану әрекеттері пайда болады. Кейбір қауіпсіздік зерттеулері пайдалану әрекеттері ресми жария етілуге дейін-ақ тіркелгенін хабарлаған, сондықтан бұл жағдайда уақыт сағатпен өлшенеді, аптамен емес.
Осалдықтар қарапайым тілде
Техникалық тереңдікке кірмей-ақ мәнін түсіндіруге болады. Екі осалдықтың екеуі де жадпен жұмыс істеудегі қателікке байланысты: PHP бір сұранысты өңдеу кезінде жадтың бір бөлігін босатып қояды, ал кейін сол босатылған жадты әлі де қолданыста деп санайды. Нақты жағдайларда мұндай қате шабуылдаушыға сервердегі жадтың мазмұнын оқуға немесе өз кодын орындатуға мүмкіндік береді.
Біріншісі (CVE-2026-109618) файл жүктеу барысын бақылайтын механизмдегі қатеге байланысты, оның салдары - жад мазмұнының ашылуы және код орындау. Екіншісі (CVE-2026-109619) қатты қате (fatal error) болғаннан кейін бір сұраныстың ішкі күйі жад босатылғаннан кейін де қалып қойып, келесі сұранысты өңдеген сол жұмыс процесі оны қолдануына байланысты. Екінші осалдыққа апаратын белгілі жолдардың бірі - PHP-де әдепкі бойынша қосулы тұратын «session upload progress» мүмкіндігі, ол қосымша сессияны ешқашан пайдаланбаса да жұмыс істей береді. Негізгі тұжырым қарапайым: бұл - әдеттегі сайт қолданбасы дұрыс жазылған болса да, PHP-нің өзіндегі олқылық, сондықтан оны қолданба деңгейінде түзету мүмкін емес.
Неге бұл бизнеске қатысты
PHP-де WordPress, Joomla, көптеген интернет-дүкен жүйелері, CRM мен әкімшілік панельдер, сондай-ақ Laravel сияқты фреймворктермен жазылған жеке жобалар жұмыс істейді. Сондықтан бұл осалдық бір ғана сайтқа емес, PHP-ге сүйенген барлық нәрсеге қатысты: корпоративтік сайт, каталог, жеке кабинет, ішкі есеп жүйесі. Егер серверде PHP-нің осал нұсқасы тұрса, бұл - тек бір сайттың мәселесі емес, сол серверде орналасқан барлық жобаның қаупі.
Салдары да бизнеске жақын: сайттың бүлінуі, клиент деректерінің ағуы, сайтқа зиянды код орналастырылуы, сервердің басқа мақсатқа пайдаланылуы және соның нәтижесінде репутациядан айырылу. Бұл сайттың көрінбейтін, бірақ маңызды техникалық негізі: сайтты әдемі жасауға болады, бірақ ол тұрған PHP жаңартылмаса, бүкіл жұмыс бір сұраныспен құлауы мүмкін. Мұндай тәуекелдерді біз «Ашық порттар және ұмытылған сервистер» мақаласында да талқылағанбыз.
Біз қалай әрекет еттік: бір күндік жоспар
Хабарлама келген бойда біз бұл мәселені жоспарлы жұмыс ретінде емес, шұғыл іс ретінде қабылдадық. Алдымен жағдайды түсіндік: қайсы серверлерде және жобаларда PHP қолданылатынын, қандай нұсқалар тұрғанын және оларға қол жеткізу кімде екенін анықтадық. Бұл қадам маңызды, өйткені «қанша жүйе қауіп астында?» деген сұраққа жауап болмаса, жаңартуды толық жүргізуге болмайды: жиі нақты ұмытылып қалған бір ескі сервер жаңа тәуекел болып шығады.
Содан кейін екі қабатты әрекет жүргіздік. Бірінші, жылдам қадам ретінде PHP-нің өзі ұсынған уақытша қауіпсіздік параметрлерін қостық, яғни session upload progress мүмкіндігін өшірдік және PHP 8.5 жағдайында қатты қате трассасын өшіретін параметрді қолдандық. Бұл толық шешім емес екенін біз бастан-ақ білдік, сондықтан оны тек жаңарту дайындалғанша созылатын көпір ретінде қарастырдық. Екінші, негізгі қадам ретінде PHP-ді жабылған нұсқаларға - 8.2.35, 8.3.36, 8.4.27 немесе 8.5.12 - дейін жаңарттық. Маңызды ескертпе: жаңартудан кейін PHP-FPM мен веб-серверді қайта іске қосу керек, әйтпесе жадта тұрған ескі процестер осал күйінде жұмыс істей береді.
Үшінші қадам - тексеру. Жаңартудан кейін әр сервердегі PHP нұсқасын қайта растап, сайттардың жұмыс істеп тұрғанын, формалар мен әкімші панельдердің дұрыс жауап беретінін қарадық. Бұдан кейін біз қауіпсіздік журналдары мен ерекше белсенділікке мониторингті күшейттік, себебі осалдық жария болған алғашқы күндерде шабуыл әрекеттері көбейеді. Нәтижесінде жағдайды бір күн ішінде жаптық: осалдықтан хабардар болған сәттен бастап жаңартылған және қайта іске қосылған жүйелерге дейін бір жұмыс күнінен аспады. Мұндай жылдамдық кездейсоқ емес, ол бұрыннан бар серверлер тізімі, нақты жауапты адамдар мен жаңартуды тез жүргізуге дайын процестің арқасында мүмкін болды.
Уақытша шара мен толық шешім: айырмашылығы неде
Бұл жерде ең көп қателесетін нүкте - уақытша параметрлерді толық шешім деп қабылдау. PHP жобасы ашық түрде былай деп хабарлады: толық қорғайтын жеңілдету жоқ, жаңарту - жалғыз сенімді таңдау. session.upload_progress.enabled параметрін өшіру екінші осалдыққа апаратын белгілі жолдардың бірін жабады, бірақ бұл барлық мүмкін нұсқаны жаппайды, және ол біріншісіне (CVE-2026-109618) қатысты емес. Сондықтан бұл шараны тек жаңартуға дейінгі қысқа мерзімдік қорғаныс ретінде қолдануға болады.
Параметрді қайда орнату да маңызды. Ресми ұсыныс бойынша ол php.ini файлында немесе PHP-FPM пулының конфигурациясында тұруы керек, ал ini_set() не .user.ini арқылы орнату жұмыс істемейді, себебі осалдыққа апаратын жол сұраныс скриптке жеткенге дейін-ақ өңделеді. Параметрді өзгерткеннен кейін барлық жұмыс процестерін қайта іске қосу қажет. Ал жаңартудан кейін, егер хостинг-провайдер өзі уақытша өшірген болса, оларды өздігінен қайта қоспай, провайдер патчтың шыққанын растағанша күту дұрыс.
Сұрақ қойыңыз немесе өтінім қалдырыңыз
Серверлеріңіздегі PHP нұсқаларын анықтап, жаңартамыз және мониторингті баптаймыз - бизнеске тоқтаусыз.
Форманы жіберу арқылы дербес деректерді өңдеуге келісім бересіз.
PHP нұсқасын қалай тексеруге болады
Өз серверіңіз болса, ең алдымен қандай нұсқа тұрғанын білу керек. Командалық жолда php -v командасы пайдаланылатын нұсқаны көрсетеді, ал веб-сервер үшін PHP-FPM немесе Apache модулі басқа нұсқа қолдануы мүмкін екенін ескеру қажет, сондықтан әр пулдың нұсқасын жеке тексерген жөн. Егер нұсқа 8.2.35, 8.3.36, 8.4.27 немесе 8.5.12-ден төмен болса, сервер осал.
Debian және Ubuntu негізіндегі жүйелерде жаңарту әдетте пакет менеджері арқылы жүргізіледі, мысалы бір ғана PHP-ге қатысты барлық пакетті бірге жаңартқан дұрыс: sudo apt update && sudo apt install --only-upgrade 'php8.*'. Одан кейін PHP-FPM қызметін қайта іске қосу керек, мысалы sudo systemctl restart php8.3-fpm (атау нұсқаға байланысты өзгереді), немесе Apache қолданылса, оны да қайта жүктеңіз. Жаңартқаннан кейін php -v арқылы нұсқаны қайта тексеріп, сайттың жұмысын қараңыз. Docker қолданылса, PHP-нің жаңа нұсқасы бар образды қайта жинап, контейнерді қайта іске қосу керек. PHP 8.1 және одан ескі нұсқаларға PHP жобасынан ресми жаңарту шықпағанын ұмытпаңыз: мұндай жағдайда провайдерден бэкпортты сұрау немесе қолдауы бар нұсқаға көшу керек.
Хостингте тұрсаңыз не істеу керек
Егер сайт ортақ хостингте тұрса, сервердің PHP нұсқасын хостинг-провайдер басқарады, сондықтан негізгі әрекет - провайдердің хабарламасын оқып, жаңарту қашан және қалай жүргізілетінін біліп алу. Көп хостинг-провайдерлер мұндай жағдайда қысқа мерзімде өздері жаңартады, ал кейбірі алдымен қорғаныс параметрлерін қосып, содан кейін патч шығарады. Басқару панелінде PHP нұсқасын таңдау мүмкіндігі болса, оны қолдауы бар және жабылған нұсқаға ауыстырып қойыңыз.
Сонымен қатар өз сайтыңыздың жағын да тексеріңіз: WordPress, плагиндер мен тақырыптарды жаңартыңыз, пайдаланылмайтын плагиндерді жойыңыз, әкімші панельге күшті пароль мен екі факторлы аутентификация қосыңыз. Бұлар осы осалдықтың өзінен қорғамайды, бірақ шабуылдаушының басқа жолдарын жабады және сайттың жалпы қауіпсіздігін арттырады. Егер сайтты әзірлеуші немесе студия қолдаса, олардан нақты не жасалғанын жазбаша сұраңыз: бұл қолдау келісімінің қалыпты бөлігі.
Біз бұл жағдайдан не үйрендік
Бұл оқиға бірнеше қарапайым, бірақ маңызды нәрсені растады. Біріншіден, серверлер мен жобалардың нақты тізімі шұғыл жағдайда жылдамдықты анықтайтын негізгі фактор: қанша жүйе барын және қайда тұрғанын білмесеңіз, барлығын жаппай жаңарту мүмкін емес. Екіншіден, жаңартуларды «тыныш уақытқа» қалдырудың құны жоғары: осалдық жария болған кезде шабуылдар оның күшіне қарай бірнеше сағатта басталады, ал дайын процесі бар команда сол сәтте жұмысқа кіріседі.
Үшіншіден, уақытша шара мен толық шешімді ажырата білу керек: параметрді өшіру тыныштық береді, бірақ қауіпті жоймайды. Төртіншіден, провайдерлердің хабарламаларын назардан тыс қалдыруға болмайды: DigitalOcean сияқты провайдерлердің «URGENT» хаты көбіне нақты қауіп туралы болады, оны жай жарнама деп бұрмалап жіберіп алмау керек. Және ақыр соңында, бұл - қолдау келісімінің мәнін көрсететін жағдай: сайтты жасап тастап кету емес, оны үнемі жаңартып отыру - қауіпсіздіктің негізі. Бұл туралы біз техникалық қолдау келісімі мен сайтты қолдау мақалаларында да жазғанбыз.
Тексеру тізімі
- Барлық сервер мен жобаның тізімі бар, PHP қолданатындары белгіленген
- Әр серверде PHP нұсқасы тексерілген (8.2.35, 8.3.36, 8.4.27 немесе 8.5.12 және одан жоғары)
- Жаңарту аяқталғанша уақытша параметр қосылған (session.upload_progress.enabled = 0, PHP 8.5-те қосымша fatal_error_backtraces = 0), және ол php.ini немесе PHP-FPM пулында тұр
- PHP жаңартылып, PHP-FPM/Apache және басқа ұзақ жұмыс істейтін процестер қайта іске қосылған
- Жаңартудан кейін нұсқа қайта расталған, сайттар, формалар мен әкімші панельдер тексерілген
- PHP 8.1 және одан ескі нұсқалар үшін бэкпорт немесе қолдауы бар нұсқаға көшу жоспарланған
- Docker образдары қайта жиналып, контейнерлер қайта іске қосылған
- Хостинг-провайдердің хабарламасы оқылған, жаңарту мерзімі расталған
- Қауіпсіздік журналдары мен ерекше белсенділікке мониторинг күшейтілген
- Қолдау келісімінде қауіпсіздік жаңартуларына жауапты адам тағайындалған
