Уязвимость PHP2Shell: что делать владельцу сайта сейчас

В конце октября 2026 года в самом интерпретаторе PHP нашли две критические уязвимости, и по сообщениям исследователей их уже используют в реальных атаках. Они касаются не одной CMS, а любого сайта на PHP: WordPress, OpenCart, Joomla, Drupal или самописного кода. Ниже: что известно, как за пять минут проверить свою версию, что сделать сегодня и что делать, если обновиться сразу не получается.

Что известно

Всё ниже взято из публикаций Patchstack и watchTowr. Это свежие сообщения, детали могут уточняться, поэтому смотрите и официальное объявление PHP.

• Уязвимости имеют номера CVE-2026-109618 и CVE-2026-109619, обе оценены в 9.2 по CVSS v4.0 (критический уровень).
• Аутентификация злоумышленнику не нужна: достаточно отправить сайту запрос.
• Ошибка в самом PHP, а не в плагине или теме. Первая связана с нехваткой памяти посреди обработки запроса, вторая с тем, что состояние запроса остаётся в памяти после её освобождения и попадает в следующий запрос того же процесса.
• Затронуты все веб-способы запуска PHP: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, FrankenPHP. По оценке Patchstack, самый рискованный mod_php.
• watchTowr фиксирует попытки эксплуатации в сети ловушек с 21 октября 2026 года; Patchstack пишет, что хостинг-партнёры сообщали об активных инцидентах. На момент написания CISA ещё не добавила эти уязвимости в каталог известных эксплуатируемых.
• По данным Wiz, которые приводит Patchstack, через уязвимости можно не только выполнить код, но и прочитать память процесса, где бывают пароли, токены и ключи API.

В цифрах

• По данным W3Techs на 27 октября 2026 года PHP используют 69,2% сайтов, для которых известен язык сервера. Среди них на PHP 8 работает 65,6%, на PHP 7 26,6%, на PHP 5 7,7%. То есть примерно каждый третий сайт на PHP (34,4%) стоит на версии 7 или старше, для которых официальных исправлений нет. Разбивку W3Techs по минорным версиям мы не приводим: в «восьмёрке» есть и 8.0 с 8.1, которые тоже без исправлений.
• Наш собственный внешний замер украинских сайтов (114 сайтов, август-сентябрь 2026): 50 работают на WordPress, WooCommerce или OpenCart, то есть на PHP. Версию PHP открыто показывают в заголовках ответа только 7 из этих 50. Из этих семи 6 на ветках без поддержки безопасности (5.5, 7.3 четыре сайта, 7.4), а седьмой на 8.3.33, что ниже исправленной 8.3.36.
• Это малая выборка, и она показывает только тех, кто не скрывает версию. Остальные 43 сайта могут быть в любом состоянии, снаружи этого не видно. Кроме того, заголовок с версией не доказывает уязвимость: хостинг мог перенести исправление в старый пакет. Поэтому проверять версию нужно изнутри.

Касается ли это моего сайта

Если сайт работает на PHP, да, пока версия не обновлена. Исправленные версии:

Номер версии может вводить в заблуждение: хостинг-провайдеры и дистрибутивы часто переносят исправления в старые пакеты, не меняя номера. По сообщениям производителей, cPanel (ea-php 7.4–8.1), CloudLinux, TuxCare и Hostinger выпустили исправленные сборки и для старых веток. Поэтому для 8.1 и старше смотрите не только на номер, но и на дату сборки и журнал изменений пакета (исправления от 21 октября 2026 года и позже), и уточняйте у хостера письменно.

Сайты на Next.js, Node.js или статика сами по себе не затронуты, но на том же сервере часто лежит старый WordPress или почта с панелью на PHP. Поэтому проверять нужно сервер, а не только основной сайт.

Как проверить версию за пять минут

1. В панели хостинга (cPanel, ISPmanager, Plesk) найдите раздел «Версия PHP» или «PHP Selector».
2. Если есть SSH: php -v. Это версия для командной строки, веб может работать на другой.
3. В WordPress: «Инструменты → Здоровье сайта → Информация → Сервер».
4. Сверяйте не только ветку, но и точный номер: 8.3.35 ещё уязвима, а 8.3.36 уже нет.
5. Помните о поддоменах, тестовых копиях и старых сайтах на том же аккаунте: каждый может работать на своей версии.

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

1. Обновите PHP до исправленной версии вашей ветки. На общем хостинге это обычно переключатель в панели; если исправленной версии там ещё нет, напишите в поддержку хостера.
2. Перезапустите все процессы PHP после обновления, иначе старый код ещё работает в памяти.
3. Проверьте совместимость на копии. Переход, например, с 7.4 на 8.4 ломает устаревшие плагины и модули, поэтому делать его сразу на боевом сайте рискованно.
4. Если обновить сразу нельзя, снизьте риск временными мерами, которые называют Patchstack и разработчики PHP: отключить session.upload_progress.enabled, ограничить размер и число полей запроса на уровне веб-сервера, использовать правила WAF (например, Cloudflare). Это закрывает только известные пути и полной защиты не даёт: PHP прямо говорит, что единственный надёжный путь это обновление.
5. Не оставляйте сайт на PHP 8.1 и старше без плана. Для них новых исправлений от PHP уже не будет.

Если сайт могли взломать

Уязвимость действует ниже уровня приложения, поэтому журналы сайта могут ничего не показать. Тревожные признаки: нетипичные запросы с большим телом (multipart), внезапные ошибки 500 и нехватка памяти, неожиданные перезапуски процессов PHP, странные или слишком большие значения cookie PHPSESSID.

Если есть подозрение:

• смените пароли к админке, базе, FTP/SSH и ключи API, потому что память процесса могли прочитать;
• проверьте, нет ли новых файлов и администраторов, и сравните файлы с чистой копией;
• восстановите из резервной копии, сделанной до 20 октября, и только после обновления PHP.

Почему «просто обновить» не всегда просто

Обновление PHP на старом проекте упирается в код. Старые темы, самописные модули и плагины без поддержки могут не работать на новой ветке. Тогда варианты такие: обновить плагины, заменить их, исправить код или перенести сайт на современную платформу. Это решается после короткого аудита, а не наугад.

Что можем сделать мы

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

Из собственной практики. Наш движок интернет-магазинов Stable мы уже переводим на исправленную сборку: образы облачной версии и демо собраны на PHP 8.5.12. Сам движок в релизе работает на Laravel 13 (он требует PHP 8.3 и новее). Так же ведём новые магазины на Laravel: берём исправленный PHP, а не оставляем сборку «как было». Если ваш магазин работает на старом PHP или OpenCart, о переносе на Stable Shop читайте здесь.

Ни один подход не даёт стопроцентной гарантии. Обновление и харденинг сильно снижают риск, но не заменяют регулярных резервных копий и мониторинга.

Источники: Patchstack, watchTowr, поддерживаемые версии PHP.