PHP2Shell: что владельцу сайта на DLE нужно знать о двух RCE в PHP

21 октября 2026 года вокруг PHP появилась срочная причина проверить серверную часть сайта. В проекте исправили CVE-2026-109618 и CVE-2026-109619 — ошибки, при которых запрос извне способен привести к исполнению кода на не обновлённом веб-обработчике. Для владельца DLE-сайта главный вывод простой: версия движка и установленные модули не отменяют риск, потому что уязвимый компонент находится на уровне PHP.

Релизы с исправлениями от самого PHP: 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Со старыми ветками 8.1, 8.0 и 7.4 сравнение только по короткой строке версии ненадёжно. Их стандартная поддержка завершена, а поставщик хостинга или дистрибутива может перенести исправление в свой пакет, сохранив базовый номер.

Коротко#

• Уязвимости имеют идентификаторы CVE-2026-109618 и CVE-2026-109619; обе оценены в 9,2 из 10 по CVSS v4.0.
• Риск есть у PHP-FPM, Apache с mod_php и у других веб-обработчиков, включая php-cgi с LiteSpeed.
• php -v в SSH показывает версию командной строки. Она может не совпадать с PHP, который отвечает посетителям сайта.
• WAF, Cloudflare, ограничение загрузки файлов и выключение одного расширения не заменяют обновление. Временные меры только уменьшают отдельные варианты атаки.
• После установки обновления нужно убедиться, что перезапущен именно веб-обработчик PHP и страницы сайта работают уже на исправленной версии.

Что произошло#

В экстренном сообщении PHP речь идёт о двух дефектах управления памятью в самом интерпретаторе. Это не очередная проблема конкретного шаблона, плагина или CMS.

При CVE-2026-109618 сбой выделения памяти может оборвать разбор запроса в промежуточном состоянии. Затем логика очистки обращается с частью получившихся структур так, словно они были корректно подготовлены. CVE-2026-109619 затрагивает повторное использование процесса: после освобождения данных в нём может остаться устаревшая ссылка, к которой обратится следующий запрос прежде, чем состояние успеет штатно обновиться.

В обоих случаях отправная точка — HTTP-запрос к доступному извне сайту. Вход в админ-панель, уязвимый модуль DLE или загрузка расширения не являются обязательным условием. Поэтому публичные проекты нужно ставить в начало очереди на обновление.

PHP отдельно указывает, что наибольший риск сейчас связывается с mod_php: там подтверждён сценарий, в котором неавторизованный запрос запускает атаку до выполнения кода самого приложения. Но считать PHP-FPM безопасным только потому, что он другой, нельзя. В официальном списке подверженных веб-установок перечислены разные варианты: PHP-FPM, php-cgi, FrankenPHP; LiteSpeed.

Кого касается проблема#

Владелец сайта на DLE обычно смотрит на версию движка и версии модулей. В этой ситуации порядок другой: сначала нужно выяснить, какой PHP запускает страницу сайта.

Под проверку попадают:

• сайт на обычном виртуальном хостинге;
• VPS с nginx и PHP-FPM;
• Apache с mod_php или PHP-FPM;
• сервер под управлением ISPmanager, Hestia, Plesk, cPanel и аналогичных панелей;
• несколько сайтов на одном сервере, даже если только один из них использует DLE;
• панели и готовые продукты, внутри которых PHP работает как зависимость.

В последнем пункте легко ошибиться. Например, Plesk отдельно обновляет пользовательские PHP-обработчики и свой внутренний sw-engine. Если обновить только PHP для сайтов, это не означает, что обновлён сам компонент панели. Конкретный список версий и статус патчей надо смотреть у своего поставщика панели, а не переносить таблицу из чужой инструкции.

Какие версии закрывают проблему#

Для поддерживаемых веток проекта PHP фикс вышел 21 октября:

Для PHP, собранного из исходников проекта, меньший номер означает, что нужно перейти на указанную исправленную версию. У пакетного PHP сначала проверьте advisory своего дистрибутива: поставщик может перенести патч в версию с другим номером. «У меня PHP 7.4.33» само по себе не отвечает на вопрос. Upstream-ветки 7.4, 8.0 и 8.1 завершили стандартную поддержку. PHP подготовил минимальные исходные backport-ветки, а некоторые дистрибутивы и LTS-поставщики включили исправления в свои пакеты. Номер базовой версии при этом может остаться прежним. Это видно и в таблице Plesk для EOL-веток.

Именно поэтому на старом хостинге не надо самостоятельно решать, что патча нет, и не стоит верить общей фразе «сервер обновляется автоматически». Напишите в поддержку точный вопрос: «Подтвердите исправление CVE-2026-109618 и CVE-2026-109619 для PHP-обработчика моего сайта, укажите версию пакета и дату сборки». Это даст проверяемый ответ, а не обещание.

Почему php -v — только начало проверки#

На VPS привычно выполнить:

php -v

Команда полезна, но она показывает PHP для командной строки. Сайт может обслуживаться другой веткой PHP-FPM, альтернативным бинарником панели или отдельным обработчиком LiteSpeed. Бывают и более запутанные варианты: в CLI уже установлена новая версия, а старые FPM-воркеры продолжают держать в памяти прежний рантайм.

Порядок проверки должен быть таким:

1. Узнайте в панели хостинга или настройках сайта назначенную ему версию PHP и обработчик.
2. Сравните её с версией установленного пакета, если есть доступ по SSH.
3. После обновления перезапустите именно службу, которая выполняет веб-запросы сайта.
4. Проверьте версию через закрытый от посторонних диагностический механизм панели или временную защищённую страницу. Не оставляйте публичный phpinfo() в корне сайта: он раскрывает лишние детали о сервере.
5. Откройте сайт и сделайте обычные пользовательские действия: вход в панель, загрузка изображения, сохранение новости, работа формы обратной связи. Затем посмотрите журнал ошибок PHP и веб-сервера.

На виртуальном хостинге чаще всего это делает провайдер. Ваша задача — не писать в поддержку «обновите PHP», а назвать конкретный сайт, PHP-handler и две CVE. Если панель позволяет выбрать PHP 8.4, выбор «8.4» ещё не равен 8.4.27: попросите показать полную версию обработчика.

Как действовать на VPS#

На сервере нельзя слепо копировать одну команду из интернета: Debian, Ubuntu, AlmaLinux, панели управления и сторонние репозитории поставляют PHP по-разному. Безопасная последовательность одинакова.

Сначала сделайте резервную копию конфигураций и зафиксируйте текущие версии пакетов. Затем обновите пакеты из доверенного репозитория дистрибутива или репозитория вашей панели. Если используется PHP-FPM, перезапустите нужный пул или сервис после обновления. Для Apache с mod_php потребуется перезапуск Apache. После этого повторите проверку через веб, а не только в SSH.

Ubuntu прямо предупреждает: автоматическое применение обновления пакета не гарантирует, что уже запущенное приложение использует новую библиотеку. Обработчик должен быть перезапущен или сервер перезагружен по вашему регламенту. На нагруженном сайте продумайте короткое окно работ: сначала обновить небоевой экземпляр, затем основной узел, проверить журнал и доступность.

Если вы используете Hestia, ISPmanager, Plesk или cPanel, сначала посмотрите документацию именно панели. Она может управлять отдельными пакетами PHP и их версиями независимо от системного /usr/bin/php. Самостоятельная установка стороннего репозитория «лишь бы получить новую цифру» иногда ломает связку с панелью и не закрывает тот обработчик, который фактически обслуживает сайт.

Что делать, если сайт работает на PHP 7.4, 8.0 или 8.1#

С PHP 7.4, 8.0 и 8.1 ситуация сложнее. DLE-сайт может годами работать на PHP 7.4, потому что старый шаблон или модуль не готов к новой ветке. Но «работает» не означает «можно не обновлять». Проект PHP больше не выпускает для этих веток обычные обновления.

Дальше есть три реалистичных пути.

Первый — получить подтверждённый backport от хостера или поставщика Linux. Это временное решение, которое закрывает именно текущие CVE, но не возвращает ветке полноценную поддержку.

Второй — перейти на поддерживаемую ветку PHP и доработать несовместимый код. Это требует подготовки и резервной копии, зато перестаёт превращать каждую новую уязвимость в срочную поисковую операцию.

Третий — изолировать или временно отключить публичный сервис до появления исправления. Он неприятный, но честнее, чем оставлять интернет-доступным сайт с критической RCE и рассчитывать на удачу.

В Plesk для некоторых EOL-веток исправленный пакет может сохранить тот же номер, но иметь другую дату сборки. Значит, проверка по строке 7.4.33 недостаточна. Нужны данные панели, дата пакета или официальный ответ провайдера.

Временные меры: что они дают и чего не дают#

У PHP есть рекомендации для тех, кто физически не успевает обновиться. Их нельзя превращать в заголовок «как защититься без обновления». Официальная позиция жёсткая: полной защитой остаётся только установка исправленного PHP.

Для CVE-2026-109618 проект PHP советует убрать управляемую приложением конечную границу memory_limit, ограничить размер POST-запросов и следить, чтобы лимит загрузки был ниже общего лимита POST. Это сокращает подтверждённый путь через контролируемую нехватку памяти, но не исключает реальную ошибку выделения памяти и не закрывает второй CVE. Полные границы этих мер перечислены в advisory PHP.

Для CVE-2026-109619 упоминается отключение session.upload_progress.enabled на уровне конфигурации, применяемой до разбора запроса, и обязательный перезапуск воркеров. Это перекрывает подтверждённые пути через сессии, но не все возможные варианты. Изменение через ini_set() внутри DLE-модуля или .user.ini недостаточно: к моменту выполнения кода запрос уже разобран.

Cloudflare, WAF и фильтры запросов не исправляют память PHP и не должны быть причиной отложить обновление. То же относится к удалению формы загрузки файлов: оно не является доказательством безопасности всего рантайма.

Что проверить на сайте DLE после обновления#

Одного открытия главной страницы после обновления недостаточно. PHP-обновление может затронуть расширения, OPcache, обработку изображений, старые вызовы функций и настройки кодировки.

Начните с главной страницы и нескольких разных разделов. Затем войдите в административную панель, откройте редактирование новости, сохраните тестовую запись в непубличной категории или удалите её после проверки, загрузите и удалите тестовое изображение, проверьте комментарий или форму обратной связи, если они включены. Посмотрите error_log PHP и журнал веб-сервера: предупреждения, которые не видны посетителю, часто первыми показывают несовместимость старого модуля.

На сайте с очередями, парсерами или cron-задачами проверьте и их. Они могут использовать другой CLI-PHP, чем веб, поэтому в задаче планировщика должна быть указана та же исправленная ветка или подтверждённый пакет с backport. Не меняйте версию в бою одновременно для всех сайтов без резервной копии и плана отката.

Если есть подозрение на взлом#

Патч останавливает известный путь, но не удаляет уже оставленный на сервере код. На публичном сайте приоритет — ограничить доступ либо поставить исправление; не откладывайте это ради долгого аудита. Если ситуация позволяет, сохраните журналы веб-сервера и PHP, список недавно изменённых файлов, задания cron и данные о новых пользователях панели до работ или сразу после них. Затем проверьте подозрительные PHP-файлы в папках загрузок, неизвестные задания cron, добавочные администраторские учётные записи, изменения в .htaccess и исходящие соединения.

Не стоит объявлять сайт чистым только потому, что антивирус ничего не нашёл. И не стоит автоматически считать любой странный файл следствием этой уязвимости: нужна проверка дат, журналов и назначения файла. Британский NCSC рекомендует тем, кто не может быстро обновиться или отключить сервис, оценить систему на признаки компрометации до работ и при необходимости привлечь специалистов по реагированию.

Источники#

• PHP: Security advisory: Critical remote code execution vulnerabilities, update now
• ENISA: Joint statement on critical PHP vulnerabilities
• NCSC UK: Critical security issue affecting PHP
• Ubuntu: php2shell vulnerability fixes available
• Plesk: PHP RCE in PHP shipped with Plesk

Проверено по источникам: 22.10.2026. Технические рекомендации необходимо сверять с документацией своего хостинга и панели: состав пакетов и способы перезапуска у поставщиков различаются.

Проверено на: Официальные источники PHP, ENISA, NCSC, Ubuntu и Plesk — 22.10.2026