PHP2Shell: две критические уязвимости в PHP и когда мы их закрыли

21 октября вышли исправления двух критических уязвимостей в самом PHP. Все сайты, которые мы размещаем, работают на исправленном PHP с 22 октября, 02:59 UTC. Делать ничего не нужно.

Тёмно-синий сервер с четырьмя окнами сайтов, логотипом PHP на верхней панели и шкалой, заполненной до последнего кораллового деления; стопка бланков с коралловой скрепкой и коралловый пунктир к значку обновления на сервере; полумесяц, тёплый кремовый фон

Почти все сайты, которые мы размещаем, работают на PHP — языке программирования, на котором написаны WordPress и большинство других систем управления сайтами (CMS) и интернет-магазинов. 21 октября разработчики PHP закрыли две критические уязвимости в самом PHP — CVE-2026-109618 и CVE-2026-109619. Исследователи, которые их нашли, назвали атаку PHP2Shell.

Чем опасны эти уязвимости#

В опубликованных атаках всё начинается со специально подготовленного запроса — такого, какой отправляет веб-форма, когда вы прикрепляете к ней файл. Из-за него PHP бросает обработку на полпути — например, когда у него кончается память, — и остаётся с недостроенными данными. То, что он делает с ними дальше, можно направить так, чтобы на сервере выполнился код злоумышленника. Другой способ воспользоваться уязвимостями позволяет вместо этого прочитать данные из памяти PHP, а среди них могут оказаться пароли и ключи. Входить на сайт для атаки не нужно; обе уязвимости оценены в 9,2 балла из 10.

Они есть во всех версиях PHP, которые разработчики ещё поддерживают, — с 8.2 по 8.5 — и в более старых тоже. Исследователи показали, что атака срабатывает на WordPress, Drupal, Laravel, phpMyAdmin и других программах — в том числе на WHMCS и Roundcube, на которых работают наш личный кабинет и веб-почта.

Исправления должны были выйти 22 октября, но 20 октября новость об уязвимостях просочилась в сеть, и разработчики PHP выпустили их на сутки раньше — 21 октября, около 14:00 UTC. Специалисты Amazon по безопасности заметили первую попытку воспользоваться уязвимостями ещё 17 октября, а новые — ночью и утром 21 октября, до выхода исправления; сработала бы хоть одна из них, неизвестно. Сами разработчики PHP пишут прямо: полностью защититься без обновления нельзя, обновиться — единственный безопасный вариант.

Когда исправление дошло до личного кабинета, сайтов и веб-почты#

Время везде указано по UTC.

  • Личный кабинет, наш сайт и сам cPanel, включая phpMyAdmin: 21 октября с 14:40 до 14:42, меньше чем через час после выхода исправления.
  • Ваши сайты. PHP на наших хостинг-серверах поставляет CloudLinux — компания, которая разрабатывает их операционную систему и сама собирает исправленные версии PHP. Нужные нашим серверам версии она выложила вечером 21 октября, последние из них — сразу после полуночи. Ночное обновление наших серверов установило их 22 октября в 02:57, и уже с 02:59 все сайты, которые мы размещаем, работали на исправленном PHP — примерно через 13 часов после выхода исправления от разработчиков PHP.
  • Веб-почта webmail.maxinodes.com — это Roundcube на отдельном сервере. Её ночное обновление установило исправленный PHP 22 октября в 03:49. С того момента, как 20 октября новость об уязвимостях просочилась в сеть, и до этого обновления к ней не попал ни один запрос с отправкой формы.
  • JetBackup и WP Toolkit — два дополнения к cPanel со своей копией PHP (JetBackup делает наши резервные копии): 22 октября в 01:14 и 05:52.

Ещё до того, как исправление дошло до ваших сайтов, файрвол веб-приложений (WAF) на наших хостинг-серверах, который проверяет каждый запрос к размещённым у нас сайтам, уже блокировал запросы опубликованного инструмента для атаки — начиная с 21 октября, 13:13. Это дополнительная защита, а не исправление: она перекрывает лишь часть путей к уязвимостям.

Что мы нашли в логах#

Мы просмотрели логи каждого из этих серверов начиная с 17 октября — дня самой ранней известной попытки атаки — и до момента, когда каждый из них получил исправление. Мы искали следы, которые описывают исследователи: нехватку памяти или сбои PHP при обработке запросов с загрузкой файлов, ошибки сервера при таких запросах и PHP-файлы, появившиеся неизвестно откуда. Ничего такого не нашлось. Правила файрвола для этой атаки ни разу не сработали, а сканер вредоносных программ на наших хостинг-серверах с 17 октября не нашёл ни одного подозрительного файла — в том числе при полной проверке всех аккаунтов, которая закончилась уже после исправления. Нашёлся лишь один запрос от инструмента, созданного для поиска этих уязвимостей: 21 октября в 08:42 он пришёл на IP-адрес нашего хостинг-сервера, а не на какой-либо сайт, и система защиты сервера отклонила его ещё до того, как он дошёл до PHP. Логи не могут доказать, что ничего не произошло, но ни одного из признаков, которые мы искали, в них нет.

Номер версии PHP не изменился#

CloudLinux встраивает исправление в ту версию PHP, которая у вас уже стоит, и не меняет её номер. Поэтому на наших хостинг-серверах PHP 8.2 по-прежнему показывает 8.2.34 (а не 8.2.35), 8.3 — 8.3.35, 8.4 — 8.4.26, а 8.5 — 8.5.11, хотя исправление в них уже есть. Если плагин безопасности или онлайн-сканер предупреждает, что в вашей версии PHP есть эти уязвимости, причина именно в этом. Напишите нам — мы проверим ваш сайт и подтвердим, что исправление на месте.

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

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

Большинство сайтов, которые мы размещаем, работает на PHP 8.2, а поддержка этой версии разработчиками PHP заканчивается 31 декабря. Вот как заранее перейти на более новую версию.

В иллюстрации использован логотип PHP без изменений. Его автор — Colin Viebrock, лицензия — CC BY-SA 4.0.