Уязвимость в PHP (PHP2Shell): что проверить и поручить хостингу

21 октября 2026 г. разработчики PHP выпустили экстренные исправления двух критических уязвимостей в самом PHP, получивших название PHP2Shell. На PHP работают WordPress, WooCommerce, PrestaShop и многие сайты, написанные на заказ. Если Ваш сайт использует что-то из этого, вопрос касается и Вас. Хорошая новость: исправление готово, а проверка, есть ли оно у Вас, занимает несколько минут.

В этой статье Вы найдёте: что произошло, как проверить версию PHP без программиста, что сделать сегодня и что поручить хостингу или исполнителю сайта. Я описываю ситуацию по состоянию на 30 октября 2026 г. Версии с исправлением ещё могут измениться, поэтому перед обновлением проверьте их в сообщении о безопасности на php.net.

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

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

Команда PHP оценила обе уязвимости в 9,2 по шкале CVSS от 0 до 10, то есть как критические. Компания Patchstack описала сообщения об атаках от хостинговых компаний ещё за несколько часов до выпуска исправлений, а 26 октября американское агентство CISA внесло обе уязвимости в каталог уязвимостей, эксплуатируемых в атаках (KEV). CERT Polska (польская группа реагирования на компьютерные инциденты) выпустил по этому поводу сообщение.

Повода для паники нет, но есть повод проверить сайт ещё сегодня.

Кого касается уязвимость в PHP

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

• WordPress и WooCommerce, независимо от плагинов и темы,
• PrestaShop, Joomla и других систем для сайтов и магазинов, написанных на PHP,
• собственных скриптов и форм на PHP, в том числе на простых сайтах,
• инструментов на сервере, например phpMyAdmin.

Согласно сообщению PHP, под угрозой все установки PHP, которые обслуживают сайты, независимо от способа запуска на сервере. Важно: обновление WordPress или плагинов это не исправит. Исправление нужно установить в PHP на сервере, а на обычном хостинге это делает провайдер.

Версии 8.1 и более ранние больше не получают выпусков от разработчиков PHP. Из-за серьёзности уязвимостей команда PHP подготовила для 7.4, 8.0 и 8.1 только минимальные заплатки для тех, кто сам компилирует PHP. На обычном хостинге на это не рассчитывайте: безопасный выход — переход на 8.3 или 8.4.

Как проверить, подвержен ли Ваш сайт угрозе

Важен полный номер версии, с третьим числом в конце. Одного «8.3» недостаточно: версия 8.3.35 уязвима, а 8.3.36 уже нет.

WordPress: без входа на сервер

1. Войдите в панель WordPress.
2. Откройте Инструменты → Здоровье сайта и перейдите на вкладку Информация.
3. Разверните раздел Сервер. Рядом с пунктом «Версия PHP» Вы увидите полный номер, например 8.3.36.

В PrestaShop версию PHP Вы найдёте в расширенных параметрах, в информации о конфигурации магазина.

Панель хостинга

В панели хостинга, в настройках PHP, обычно видно только «8.3» или «8.4», без третьего числа. Этого достаточно, чтобы проверить, не работает ли сайт на версии без поддержки (8.1 или более ранней). О полном номере и исправлении спросите хостинг, готовое сообщение ниже. Где сменить версию в панелях OVHcloud, home.pl и nazwa.pl, я описываю в статье о конце поддержки PHP 8.2.

Тестовый файл, только ненадолго

Если у Вас есть доступ к серверу по FTP, загрузите файл wersja.php с таким содержимым:

<?php
echo PHP_VERSION;

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

Внимание: серверы с Ubuntu

На серверах VPS, где PHP установлен из системных пакетов, номер бывает обманчивым. Ubuntu вносит исправление в более старую версию и сохраняет её основной номер. В Ubuntu 24.04 исправленный пакет имеет номер 8.3.6-0ubuntu0.24.04.13, а не 8.3.36. В этом случае о статусе исправления спрашивайте администратора сервера или исполнителя сайта.

Что сделать сегодня

1. Проверьте версию PHP одним из способов выше и сравните её с таблицей.
2. Если версия ниже, чем в таблице, напишите хостингу. На виртуальном хостинге PHP обновляет провайдер, а не Вы.
3. Если у Вас PHP 8.1 или более ранний, смените версию на 8.3 или 8.4 как можно скорее: копия, тест на копии сайта, смена в панели. Это не один клик, потому что старые плагины могут перестать работать. CISA рекомендует до этого момента отключить такие сайты, если только хостинг не подтвердит исправление для Вашей версии в системном пакете.
4. Если у Вас PHP 8.2, версия 8.2.35 закрывает эти уязвимости, но поддержка 8.2 заканчивается 31 декабря 2026 г. Это хороший момент, чтобы сразу перейти на более новую версию.
5. Сделайте свежую резервную копию файлов и базы данных и сохраните её вне сервера.
6. Заодно обновите WordPress, тему и плагины по руководству по безопасному обновлению. PHP это не исправит, но закроет другие пути проникновения.
7. Не устанавливайте «плагины, исправляющие PHP2Shell» и скрипты с форумов. Плагин не изменит PHP на сервере, а неизвестный код может содержать вредоносное ПО.

Сообщение хостингу для копирования:

Здравствуйте, мой сайт [адрес сайта] работает на Вашем хостинге (учётная запись: [логин или номер клиента]). Прошу подтвердить, что PHP в моей учётной записи уже содержит исправления уязвимостей PHP2Shell (CVE-2026-109618 и CVE-2026-109619), то есть имеет версию не ниже 8.2.35, 8.3.36, 8.4.27 или 8.5.12 либо системный пакет с этим исправлением, и что процессы PHP после обновления были перезапущены. Прошу также сообщить, видны ли в логах сервера с 20 октября попытки атаки на мой сайт. Спасибо.

Если хостинг через несколько дней не подтверждает обновление, а в панели нет даже версии 8.3 или 8.4, это сигнал сменить провайдера. В рамках услуги домен и хостинг (от 390 зл без НДС в год) я переношу сайт на сервер в Польше или ЕС с актуальным PHP.

Что поручить исполнителю сайта или администратору сервера

Если сайт работает на сервере VPS, в контейнере или на сервере исполнителя, PHP обновляет тот, кто управляет этим сервером. Список для него:

• Обновление PHP до версии из таблицы или до исправленного пакета дистрибутива (Ubuntu: USN-8948-1, Debian 13: DSA-6574-1, Debian 12: DLA-4848-1).
• Перезапуск всех процессов PHP (PHP-FPM, Apache с mod_php). Без перезапуска старая версия продолжает работать в памяти.
• В первую очередь Apache с mod_php. Команда PHP считает, что там риск самый высокий.
• Образы Docker с PHP нужно пересобрать на новой версии и развернуть заново.
• Файрвол веб-приложений (WAF), по данным CISA, может частично снизить риск до обновления, но не заменяет его.
• Серверы с Windows: 26 октября PHP выпустил пересобранные пакеты 8.5.12-1, 8.4.27-1, 8.3.36-1 и 8.2.35-1 с исправленной библиотекой Brotli (CVE-2026-111497). Об этой уязвимости я пишу в статье Уязвимость в Node.js и Brotli (Node2Shell).

Если обновление должно подождать, сообщение PHP указывает временную настройку. Её нужно прописать в php.ini или в конфигурации пула PHP-FPM (не через ini_set() и не в файле .user.ini) и перезапустить процессы PHP:

session.upload_progress.enabled = 0

Это лишь частичная защита. По данным команды PHP, она блокирует подтверждённые пути атаки через сессию, но не все варианты, а по данным Tanium не защищает от CVE-2026-109618. Полную защиту даёт только обновление.

Третья уязвимость: CVE-2026-115560

23 октября команда PHP описала ещё одну уязвимость, также связанную с отслеживанием хода загрузки файлов в сессии. Версии от 21 октября её не устраняют. По данным PHP, она опасна только при необычном сочетании настроек сервера и кода приложения, поэтому исправление войдёт в следующий плановый выпуск, а не в экстренный.

До тех пор PHP рекомендует настройку session.upload_progress.enabled = 0, ту же, что и выше. Если эта настройка уже действует на сервере, оставьте её и после обновления. После изменения проверьте формы, через которые клиенты отправляют файлы. На день, когда я заканчиваю эту статью, исправления ещё нет, поэтому загляните в новости на php.net.

Мог ли кто-то уже проникнуть на сайт

Первые попытки атак зафиксировали ещё до того, как исправления вообще вышли. Поэтому после обновления стоит проверить, не успел ли кто-то оставить себе лазейку. Тревожные сигналы:

• новые учётные записи администраторов, которых никто в компании не создавал,
• незнакомые файлы на сервере, особенно файлы .php в каталоге с изображениями,
• перенаправления на чужие сайты или странные страницы в результатах Google,
• сообщения хостинга о вредоносном ПО или внезапный рост нагрузки на сервер.

Попросите хостинг или исполнителя просмотреть логи с 20 октября. CISA обращает внимание, в частности, на процессы PHP, которые запускают системную оболочку или скачивают инструменты. Если Вы найдёте следы взлома, смените пароли, восстановите чистую копию и сообщите об инциденте в CERT Polska через форму на incydent.cert.pl. План действий шаг за шагом я опишу в отдельной статье «Уязвимость на сайте компании: что делать в первые 24 часа».

Как проверить версии PHP, CMS и плагинов на Вашем сайте, я показываю в статье Как проверить версию PHP и узнать, на чём работает Ваш сайт.

Итог

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

Если Вы не хотите следить за этим самостоятельно, в рамках технической поддержки я слежу за сайтом, делаю резервные копии и устанавливаю обновления безопасности, срочные за 2 дня. Пакет «Дежурство» стоит от 149 зл без НДС в месяц, а Standard (от 349 зл) и Pro (от 749 зл) дают более быструю реакцию и часы работы в месяц. Если хотите проверить, как защищён сайт помимо самого PHP, закажите аудит безопасности или просто напишите мне. Отвечаю в течение 24 часов, а новые клиенты получают скидку 20% на первый заказ.