Критические уязвимости в PHP (PHP2Shell)

21 октября 2026 года команда PHP выпускает экстренное обновление безопасности. Оно закрывает две критические уязвимости в самом интерпретаторе PHP, которые позволяют злоумышленнику удалённо выполнить код на сервере. Уязвимости уже получили неофициальное название PHP2Shell.

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

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

Команда безопасности PHP объявила о выпуске исправлений для двух критических уязвимостей. Обе получили оценку 9.2 из 10 по шкале CVSS v4.0. Исследователи отслеживают их под номерами CVE-2026-109618 и CVE-2026-109619.

Исправления выходят 21 октября в 17:00 по Москве (14:00 UTC). Изначально публикация планировалась на день позже, но информация об уязвимостях утекла в сеть раньше срока, и PHP перенёс релиз. По данным компании Patchstack, утром 21 октября хостинг-провайдеры уже сообщали о попытках эксплуатации.

Кого это касается

Уязвимость находится не в CMS или плагине, а в самом PHP. Поэтому под угрозой любой сайт на уязвимой версии PHP: WordPress, WooCommerce, Joomla, Drupal, 1С-Битрикс, Magento, Laravel и самописные проекты. Обновление CMS и плагинов от этой проблемы не защищает.

По предварительным данным, затронуты все версии начиная с PHP 5.4. Официальные исправления выйдут только для поддерживаемых веток:

Точный список затронутых и исправленных версий PHP опубликует вместе с релизом. Мы дополним статью, как только он появится.

Что известно и что пока не раскрыто

PHP пока не опубликовал технических деталей. Всё, что известно сейчас, — из утечки и анализа независимых исследователей:

• уязвимости позволяют выполнить произвольный код на сервере без авторизации, достаточно отправить специальный запрос на сайт;
• как минимум одна из них связана с механизмом отслеживания прогресса загрузки файлов (session.upload_progress), который в PHP включён по умолчанию;
• вторая, по данным исследователей, находится в обработчике загрузки файлов и от этой настройки не зависит.

До выхода релиза официально не подтверждены:

• точное описание уязвимостей и условия атаки;
• список затронутых и исправленных версий;
• признаки компрометации (IoC).

Специалисты по безопасности ожидают массовых атак в первые минуты после публикации исправлений: сравнив старый и новый код, злоумышленники быстро поймут, как работает уязвимость. Поэтому обновление нельзя откладывать.

Что мы делаем

Не дожидаясь официального релиза, мы приняли меры на уровне всей инфраструктуры:

1. Добавили правила фильтрации запросов, блокирующие известный сценарий атаки. Это ограниченная мера: часть атак может пройти мимо фильтра, поэтому она лишь выигрывает время до обновления.
2. Усилили мониторинг: отслеживаем подозрительную активность процессов PHP на серверах и аварийные завершения PHP, которые могут указывать на попытки атаки.
3. Подготовили обновление PHP. Сразу после выхода релиза установим исправленные версии для веток 8.2–8.5 на всех серверах виртуального хостинга. Об окончании работ сообщим отдельно.

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

Что нужно сделать вам

Если у вас виртуальный хостинг

Основную работу мы делаем сами. От вас нужно:

1. Проверить версию PHP в разделе настроек PHP панели управления для каждого сайта.
2. Если версия 8.2 или новее — ничего делать не нужно: исправленную версию мы установим автоматически.
3. Если версия 8.1 или старше — переключите сайт на ветку 8.2 или новее (см. следующий раздел).
4. Не включайте обратно session.upload_progress в собственных настройках PHP, даже если это предлагает инструкция к плагину.

Если у вас VPS или выделенный сервер

На VPS и выделенных серверах PHP управляете вы, и обновить его за вас мы не можем. Сделайте следующее как можно скорее:

1. Найдите все установленные версии PHP на сервере. Учитывайте, что панели управления (ISPmanager, cPanel, Plesk, FastPanel и другие) часто держат несколько версий одновременно.
2. Отключите отслеживание прогресса загрузки до выхода обновления. Для PHP-FPM добавьте строки в конфигурацию каждого пула, например /etc/php/8.3/fpm/pool.d/www.conf: php_admin_flag[session.upload_progress.enabled] = off php_admin_flag[session.use_strict_mode] = on Если PHP работает как модуль Apache (mod_php), задайте эти параметры в php.ini и перезапустите Apache. Настройку нельзя изменить из кода через ini_set().
3. Перезапустите PHP-FPM и проверьте результат: создайте файл <?php phpinfo(); в корне сайта, откройте его в браузере и убедитесь, что session.upload_progress.enabled имеет значение Off. Сразу удалите этот файл. Проверка через php -i в консоли не подходит — она показывает настройки командной строки, а не веб-сервера.
4. Обновите PHP, как только исправленные пакеты появятся в репозитории вашего дистрибутива или панели управления. Затем перезапустите PHP-FPM или Apache — без перезапуска продолжит работать старая версия.

Отключение session.upload_progress закрывает, по данным исследователей, только одну из двух уязвимостей. Это временная мера, а не замена обновлению.

Если сайт работает на PHP 8.1 или старше

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

1. Запланируйте переход на PHP 8.2 или новее. Мы рекомендуем PHP 8.4. Учтите, что ветка 8.2 получает исправления безопасности только до 31 декабря 2026 года.
2. Проверьте совместимость на тестовой копии сайта. Переход между ветками — это миграция, а не простое обновление: старые версии CMS, тем и плагинов могут не работать на новом PHP. Сначала обновите CMS и расширения, затем переключите версию PHP.
3. Если перейти быстро не получается, уберите сайт из открытого доступа до завершения миграции: ограничьте доступ по IP-адресам, паролем или через VPN.

Если самостоятельно оценить совместимость сложно, обратитесь в поддержку — поможем с переносом.

Как проверить, не взломан ли сайт

Атаки начались ещё до выхода исправления, поэтому после обновления PHP стоит убедиться, что сайт не был взломан раньше. Особое внимание — периоду начиная с 20 октября.

1. Проверьте файлы сайта на незнакомые PHP-файлы, особенно в папках загрузок, кэша и временных файлов. Обратите внимание на файлы, изменённые после 20 октября.
2. Проверьте задания cron на незнакомые записи.
3. Проверьте учётные записи администраторов в CMS, а на VPS — системных пользователей и ключи в ~/.ssh/authorized_keys.
4. Просмотрите журналы веб-сервера на подозрительные POST-запросы с загрузкой файлов, особенно на адреса, где загрузок быть не должно.
5. На VPS проверьте процессы: процессы PHP-FPM или Apache не должны запускать sh, bash, curl, wget, nc, python или perl.
6. Запустите антивирусную проверку сайта средствами панели управления или специализированного сканера.

Если нашли что-то подозрительное, не удаляйте файлы сразу: сохраните копии и журналы, смените пароли от CMS, базы данных и FTP/SSH и напишите нам.

Нужна помощь?

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

Мы обновим статью, когда PHP опубликует официальные подробности и номера исправленных версий, и отдельно сообщим об установке обновлений на наших серверах.