PHP2Shell: сервердегі PHP RCE осалдықтарын тексеру және жабу

PHP2Shell: сервердегі PHP RCE осалдықтарын тексеру және жабу

2026 жылғы 21 қазанда PHP жобасы PHP2Shell деп аталған, PHP-дің өзіндегі екі осалдықты түзету үшін 8.5.12, 8.4.27, 8.3.36 және 8.2.35 нұсқаларын шығарды. Екеуі де жүйеге кірмеген адамның сұранысына PHP воркері атынан код орындауға мүмкіндік береді. Қате WordPress, Drupal немесе Joomla-да емес, орындау ортасының өзінде, сондықтан CMS-ті немесе оның плагиндерін жаңарту оны жаппайды. Бұл нұсқаулықта кімге қатысты екені, серверді бір командамен қалай тексеру керегі, әзірге жаңарту мүмкін болмаса бүгін не істеу керегі және қауіпсіз жаңарту жолы көрсетілген.

Екі осалдық деген не

• CVE-2026-109618, жады жетіспегендегі зақымдану - жадыны бөлу сәтсіз болғанда PHP сұранысты оның ішкі деректері жартылай ғана дайындалған кезде тоқтатуы мүмкін, ал одан кейінгі тазалау осы бүлінген деректерге сенеді. Арнайы жасалған multipart сұранысы мұны сіз баптаған өлшем шектерінің ішінде де тудыра алады.
• CVE-2026-109619, ескірген ғаламдық күй - бір сұранысқа тиесілі күй оның артындағы жадыдан ұзағырақ өмір сүруі мүмкін. Сол воркер қызмет көрсететін келесі сұраныс босатылған жадыны ол қалпына келтірілмей тұрып пайдалана алады (use-after-free). Расталған жол session upload progress функциясы мен фаталды қателер арқылы өтеді.

Екеуі де CVSS 4.0 бойынша 9.2 (critical) деп бағаланған. PHP хабарламасында зерттеу барысында жұмыс істейтін эксплойт жасалғаны және тәуекел mod_php бар Apache үшін ең жоғары екені айтылады, онда шабуыл қолданбаның кез келген кодынан бұрын орындалады. Бірнеше күн ішінде бірнеше жария proof-of-concept эксплойт пайда болды; Rapid7 олардың әрқайсысы ОЖ, PHP нұсқасы мен веб-сервердің тек бір үйлесімінде ғана жұмыс істейтінін хабарлайды және пайдалану әрекеттерін байқаған. Мұны шұғыл патч ретінде қабылдаңыз.

Кімге қатысты

Веб-сұраныстарға қызмет көрсететін әр PHP орнатымына: PHP-FPM, mod_php бар Apache, php-cgi, FrankenPHP және LiteSpeed. Бұл WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel және Nextcloud бар серверлердің дерлік барлығы.

PHP тармағы	Осал нұсқалар	Алғашқы түзетілген нұсқа
8.5	8.5.0 - 8.5.11	8.5.12
8.4	8.4.0 - 8.4.26	8.4.27
8.3	8.3.0 - 8.3.35	8.3.36
8.2	8.2.0 - 8.2.34	8.2.35
7.4, 8.0, 8.1	барлығы	php.net-те шығарылым жоқ; бастапқы кодтағы бэкпорттар, дистрибутив немесе LTS жеткізушісінің пакеттері
7.3 және ескілері	барлығы	түзету жоқ

Дистрибутивтер көбіне ескі нұсқа нөмірін қалдырып, түзетуді бэкпорт ретінде енгізеді (мысалы, әлі де 8.2.x көрсететін Debian немесе Ubuntu пакеті), сондықтан пакеттен орнатылған PHP үшін тек нөмірді емес, дистрибутивіңіздің security tracker-індегі пакетті тексеріңіз.

Серверді бір командамен тексеру

Мұны php2shell-check.php ретінде сақтап, сайтыңызға қызмет көрсететін сол PHP-мен іске қосыңыз. Скрипт нұсқаны, ол түзетуден ескі ме екенін және төмендегі уақытша шаралар өзгертетін екі параметрді шығарады.

<?php
// PHP2Shell check: is this PHP build older than the October 21, 2026 fixes?
$fixed = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;
echo "PHP " . PHP_VERSION . " (" . PHP_SAPI . ")\n";
if (!isset($fixed[$branch])) {
    echo "Branch $branch gets no php.net release: check your distro or LTS vendor, or upgrade to 8.4.\n";
} elseif (version_compare(PHP_VERSION, $fixed[$branch], '<')) {
    echo "VULNERABLE: upgrade to {$fixed[$branch]} or later (or a distro build with the backport).\n";
} else {
    echo "Patched upstream version ({$fixed[$branch]}+).\n";
}
echo "session.upload_progress.enabled = " . (ini_get('session.upload_progress.enabled') ? 'On' : 'Off') . "\n";
echo "post_max_size = " . ini_get('post_max_size') . ", memory_limit = " . ini_get('memory_limit') . "\n";

php php2shell-check.php

Нәтиже 2026-10-24 күні ресми php Docker бейнелерінде тексерілді:

PHP 8.3.30 (cli)
VULNERABLE: upgrade to 8.3.36 or later (or a distro build with the backport).
session.upload_progress.enabled = On
post_max_size = 8M, memory_limit = 128M

PHP 8.4.27 (cli)
Patched upstream version (8.4.27+).

PHP 7.2.34 (cli)
Branch 7.2 gets no php.net release: check your distro or LTS vendor, or upgrade to 8.4.

Командалық жолдағы php сайтыңыздың артындағы құрастырудан басқа болуы мүмкін. Веб жағын тексеру үшін php-fpm -v (Debian мен Ubuntu-да php-fpm8.3 -v) орындаңыз немесе скриптті бір сұранысқа сайттың түбір каталогына салып, бірден өшіріңіз.

Бүгін жаңарту мүмкін болмаса: уақытша шаралар

PHP командасы толық қорғаныс жоқ екенін және жалғыз қауіпсіз таңдау - жаңарту екенін анық айтады. Бұл баптаулар жаңартуды жоспарлап жатқанда шабуыл аясын тарылтады. Оларды қолданба қайта анықтай алмайтын жерде орнатыңыз - php.ini ішінде немесе FPM пулында php_admin_value арқылы, - өйткені ini_set() және .user.ini тым кеш қолданылады. Содан кейін барлық воркерлерді қайта іске қосыңыз.

; FPM pool, e.g. /etc/php/8.3/fpm/pool.d/zz-php2shell.conf (the [www] section of your pool)
[www]
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M

php-fpm8.3 -t && systemctl restart php8.3-fpm

Біз бұл пул файлын PHP 8.4-те php-fpm -t арқылы тексердік (configuration test successful). Әр жол не істейді:

• session.upload_progress.enabled = 0 CVE-2026-109619 осалдығының расталған жолын жабады, бірақ барлық нұсқасын емес. Жүктеу прогресінің жолағы соған тәуелді болмаса, оны өшіріңіз.
• post_max_size жүктеулер болмаса 8M, ал сайт файл қабылдаса 32M, және PHP командасы ұсынғандай upload_max_filesize одан төмен болсын. Сондай-ақ сұраныс өлшемін nginx-те (client_max_body_size 32m;) немесе Apache-та (LimitRequestBody) шектеңіз.
• Тек PHP 8.5-те fatal_error_backtraces = 0 қосыңыз.
• PHP сондай-ақ әкімші орнатқан memory_limit = -1 мәнін ұсынады, сонда жады шегінің өзін CVE-2026-109618 осалдығын іске қосу үшін пайдалану мүмкін болмайды. Мұны тек PHP айналасында контейнер немесе cgroup жады шегі болғанда ғана жасаңыз, әйтпесе бір зиянды сұраныс сервердің бүкіл RAM-ын алып қоюы мүмкін. Бұл үшін RLIMIT_AS немесе RLIMIT_DATA қолданбаңыз: олар осалдықты іске қосуы мүмкін.

Қателерді жасыру (display_errors, error_reporting, @) көмектеспейді, ал бос қателер журналы серверге шабуыл жасалмағанын дәлелдемейді.

Қалай жаңарту керек

1. Пакеттен орнатылған PHP (Debian, Ubuntu, RHEL, AlmaLinux). Қауіпсіздік жаңартуын орнатыңыз (apt update && apt upgrade немесе dnf upgrade 'php*'), содан кейін PHP-FPM немесе Apache-ты қайта іске қосыңыз, өйткені жұмыс істеп тұрған воркерлер ескі кодты сақтайды. Пакеттің changelog-ында CVE-2026-109618 аталғанына көз жеткізіңіз.
2. Docker бейнелері. Түзетілген тегте (php:8.4-fpm қазір 8.4.27-ге сәйкес келеді) docker compose build --pull арқылы қайта құрастырып, контейнерлерді қайта жасаңыз. Жұмыс істеп тұрған контейнер ауыстырылмайынша ескі PHP-ді сақтайды.
3. PHP 7.4 - 8.1. Жеткізушіңіздің бэкпорты бар пакетін пайдаланыңыз немесе 8.4-ке көшіңіз. PHP 7.3 және ескілері ешқашан түзету алмайды: сайт көшірілгенше оны allow-list немесе VPN артына жасырыңыз.
4. Жаңартудан кейін тексеру скриптін қайта іске қосып, 21 қазаннан бергі веб-сервер журналынан әдеттен тыс multipart POST сұраныстары мен PHP воркерлерінің құлауларын іздеңіз.

Көмек керек болса, басқарылатын сервер әкімшілігі осындай патчтарды қамтиды, ал WordPress үшін бұлттық сервер туралы нұсқаулығымыз осы баптауларды пулда сақтайтын PHP-FPM орнатымын көрсетеді. Жұмыс істеп тұрған сайтты жаңартпас бұрын снапшот жасаңыз: VM-ді сақтық көшірмелеу және қалпына келтіру мұны қалай істеу керегін түсіндіреді.

Біз не істедік

Сол аптада біз PHP-де жұмыс істейтін DCXV-тің әрбір сервисін тексеріп, осы нұсқаулықтағы шараларды қолдандық. Клиенттердің серверлерін олардың иелері басқарады: егер DCXV бұлттық немесе арнайы серверінде PHP жұмыс істесе, жоғарыдағы тексеруді бүгін орындаңыз. Жаңа бұлттық сервер алғашқы apt upgrade кезінде өзекті пакеттерді алады.

Дереккөздер (2026-10-24 тексерілді): 2026 жылғы 21 қазандағы PHP 8.x қауіпсіздік шығарылымдары туралы хабарлама, PHP-дің GHSA-w8hw-w9fx-j79w және GHSA-6wmf-4rv5-p3rp бюллетеньдері және Rapid7 талдауы.