Уязвимость PHP2Shell: что случилось и как мы закрыли её на своих серверах

В октябре 2026 года в самом интерпретаторе PHP нашли две критические уязвимости — CVE-2026-109618 и CVE-2026-109619, общее название PHP2Shell. На PHP работает большая часть сайтов в интернете: WordPress, 1С-Битрикс, Drupal, OpenCart, Joomla, сайты на Laravel. Рассказываем, чем опасна уязвимость, что нужно сделать владельцу сайта и как это прошло на наших серверах.

Чем опасна PHP2Shell

• Критический уровень. Обе уязвимости оценены в 9,2 балла из 10 по шкале CVSS 4.0.
• Не нужен пароль. Злоумышленнику не требуется вход в админку или учётная запись на сайте.
• Выполнение чужого кода на сервере. В худшем случае атакующий получает возможность запускать свои программы: красть данные из базы, подменять страницы, рассылать спам или атаковать другие сайты с вашего сервера.
• Уязвим сам PHP, а не сайт. Поэтому обновление WordPress, Битрикса или плагинов проблему не решает — исправить её можно только обновлением PHP на сервере.

Исправления вышли в версиях 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Вскоре после публикации появились сообщения о первых попытках атак, так что откладывать обновление нельзя.

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

• Обновить PHP на сервере. На обычном хостинге это делает хостинг-провайдер — стоит убедиться, что обновление уже установлено. На собственном сервере — администратор.
• Перезапустить PHP. После обновления нужно перезапустить PHP-FPM или веб-сервер и фоновые обработчики, иначе в памяти продолжает работать старый, уязвимый код.
• Проверить версию правильно. На серверах с Ubuntu и Debian исправления переносят в «свою» версию пакета: команда php -v может по-прежнему показывать, например, 8.3.6. Это нормально — смотреть нужно журнал изменений пакета, где должны быть упомянуты оба номера уязвимостей.
• Проверить сервер на следы взлома. Если обновление пришло не сразу, стоит поискать посторонние файлы, изучить журналы и при подозрениях сменить пароли и ключи доступа.

Как это прошло у нас

Сайты студии и демо-проекты работают на нашем собственном сервере. Обновления безопасности на нём устанавливаются автоматически — это одна из базовых настроек, которые мы делаем при запуске любого сервера.

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

• подтвердили по журналу изменений пакета, что установлено исправление обеих уязвимостей;
• проверили, что в памяти не осталось процессов со старой версией;
• проверили сервер на признаки взлома: посторонние файлы, изменения в коде сайтов, запланированные задачи, ключи доступа, журналы веб-сервера.

Следов атак не обнаружено. Все сайты работали без перерыва — посетители ничего не заметили.

Итого

Уязвимости в популярном ПО находят регулярно, и главное в таких ситуациях — скорость реакции. Когда автоматические обновления безопасности настроены заранее, а сервер регулярно проверяется, критическая уязвимость закрывается за дни, а не за недели, и без простоя сайта. Именно это мы включаем в техническое обслуживание сайтов наших клиентов.