PHP2Shell: что это за критическая уязвимость PHP, затронут ли ваш сайт и что делать

21 октября 2026 года PHP выпустил экстренное обновление безопасности, закрывающее две критические уязвимости. Уязвимости с номерами CVE-2026-109618 и CVE-2026-109619 вместе называют PHP2Shell: они могут позволить злоумышленнику выполнить код на вашем сервере без какой-либо авторизации. Поскольку сайты на WordPress, WooCommerce, Joomla и Drupal работают на PHP, это касается практически каждого владельца сайта.

В этой статье я объясняю, что такое PHP2Shell, как понять, затронут ли ваш сайт, и шаг за шагом рассказываю, что нужно сделать уже сегодня. В конце я затрагиваю и SEO-сторону вопроса: что происходит со взломанным сайтом в Google.

Коротко: что нужно знать о PHP2Shell

Что это: Две критические уязвимости безопасности памяти в ядре PHP. Оценка CVSS — 9,2 (критическая).
Последствия: Удалённое выполнение кода без аутентификации и утечка из памяти сервера таких данных, как пароли, сессионные ключи и API-ключи.
Кого это касается: Почти любой установки PHP, которая обрабатывает веб-запросы: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed.
Решение: Обновить PHP до исправленной версии: 8.5.12, 8.4.27, 8.3.36 или 8.2.35.
Срочность: Попытки эксплуатации уже зафиксированы. Ждать нельзя.

Что такое PHP2Shell?

Уязвимости обнаружила команда Wiz Research в августе 2026 года, в том числе с помощью моделей искусственного интеллекта, и сообщила о них команде безопасности PHP. Исправление и публичное раскрытие последовали 21 октября 2026 года.

Суть проблемы в том, как PHP «прибирает» после фатальных ошибок во время запроса, особенно после ошибки нехватки памяти (out of memory). Если упростить:

CVE-2026-109618: Когда ошибка нехватки памяти прерывает операцию, данные запроса могут остаться записанными наполовину. Шаги очистки обрабатывают эти повреждённые данные так, будто они корректны, и это открывает путь к удалённому выполнению кода.
CVE-2026-109619: Даже после освобождения памяти, принадлежавшей запросу, PHP в некоторых местах продолжает на неё ссылаться. Следующий запрос, который обрабатывает тот же воркер PHP, может получить доступ к этим «устаревшим» данным. Это уязвимость класса use-after-free.

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

Почему это так серьёзно?

Большинство уязвимостей связано с конкретным плагином или конкретным фрагментом кода. PHP2Shell отличается по нескольким причинам:

Не зависит от приложения: По данным Wiz, эксплуатация не зависит от того, что делает приложение. В уязвимой версии PHP уязвимой может быть даже простая страница «Hello World». Поэтому даже если ваш WordPress и все плагины полностью обновлены, риск никуда не исчезает.
Один запрос — ещё до запуска вашего кода: Согласно бюллетеню PHP, один из продемонстрированных эксплойтов срабатывает ещё до того, как выполняется код приложения. Наибольший риск — для серверов с Apache mod_php.
Очень широкий охват: По словам исследователей, почти все версии PHP за последние десять лет затронуты хотя бы одной из уязвимостей.
Атаки уже начались: Ловушки (honeypot) Amazon зафиксировали попытку эксплуатации 17 октября — за четыре дня до публичного раскрытия. Cloudflare сообщил об атакующем трафике и попытках обойти его защиту. Национальный центр кибербезопасности Великобритании (NCSC) рекомендует рассмотреть временное отключение систем, которые невозможно сразу обновить.

Какие версии PHP безопасны?

Исправленные версии, выпущенные PHP:

Ветка PHP	Исправленная версия
PHP 8.5	8.5.12 и выше
PHP 8.4	8.4.27 и выше
PHP 8.3	8.3.36 и выше
PHP 8.2	8.2.35 и выше
PHP 8.1, 8.0, 7.4 и старше	Нет официальной поддержки

PHP 8.1 и более старые версии больше не поддерживаются проектом PHP. Для 7.4, 8.0 и 8.1 выпущены лишь ограниченные патчи для тех, кто собирает PHP из исходников. На виртуальном хостинге применить их самостоятельно невозможно. Поэтому, если у вас старая версия, практическое решение — перейти на поддерживаемую версию или убедиться, что хостинг предоставляет исправленный пакет.

Важное замечание: дистрибутивы Linux и некоторые хостинг-панели могут применять исправление, не меняя старый номер версии. То есть номер версии сам по себе не всегда даёт правильный ответ. Чтобы знать наверняка, лучше всего спросить хостинг: «Включает ли используемый мной пакет PHP исправление PHP2Shell?»

Как узнать версию PHP на вашем сайте

В WordPress: Консоль > Инструменты > Здоровье сайта > вкладка «Информация» > раздел «Сервер», строка «Версия PHP».
В cPanel: На экране «Select PHP Version» или «MultiPHP Manager» видно, какую версию использует ваш домен.
Если вы администрируете сервер: Вывод php -v в командной строке может не совпадать с PHP, который обрабатывает веб-запросы. Отдельно проверьте версию PHP-FPM или LiteSpeed, которую использует веб-сервер.

Что делать? Пошаговый чек-лист

1. Сначала сделайте резервную копию

Перед любыми изменениями сделайте свежую резервную копию файлов и базы данных. Смена версии PHP может сломать старую тему или плагин. Резервная копия — ваш путь назад.

2. Свяжитесь с хостинг-провайдером

На виртуальном хостинге PHP обновляете не вы, а хостинг. Спросите службу поддержки: исправлены ли пакеты PHP на сервере от PHP2Shell (CVE-2026-109618 и CVE-2026-109619)? Применена ли дополнительная защита на уровне сервера? Некоторые провайдеры, например SiteGround, сообщили, что приняли меры на уровне сервера ещё до раскрытия.

3. Перейдите на поддерживаемую версию PHP

Если ваш сайт работает на PHP 8.1 или более старой версии, запланируйте переход на PHP 8.3 или 8.4. По возможности сначала проверьте всё на тестовой копии (staging). Убедитесь, что тема и плагины совместимы с новой версией, что сайт и панель управления открываются без ошибок и что формы работают. Проблемные плагины обычно решаются обновлением или заменой на аналог.

4. Убедитесь, что обновление действительно применилось

После обновления PHP работающие процессы PHP нужно перезапустить. Проверьте на экране «Здоровье сайта», что версия изменилась. Если вы сами администрируете сервер, перезапустите службу PHP-FPM или веб-сервера.

5. Если обновиться сразу нельзя, примите временные меры

Эти меры снижают риск, но не являются полным решением. Единственное полное решение — обновление.

Если вы используете Cloudflare: Cloudflare включил правила WAF против известных методов атаки для всех клиентов, включая бесплатный тариф.
Отключите отслеживание прогресса загрузки в сессиях: Примените session.upload_progress.enabled = 0 через php.ini, пул FPM или конфигурацию сервера. Согласно предупреждению PHP, эта настройка не работает, если задать её через ini_set() или .user.ini. После этого перезапустите процессы PHP.
Ограничьте размер запросов: Уменьшите post_max_size до необходимого значения (например, 8M, если у вас нет загрузки файлов, или 32M, если есть) и держите upload_max_filesize ниже этого значения.
Если на виртуальном хостинге вы не можете изменить эти настройки сами, попросите об этом хостинг.

6. Смените пароли и ключи

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

Пароли администраторов WordPress
Пароль базы данных (вместе с wp-config.php)
Ключи безопасности (соли) в wp-config.php. После их смены все пользователи будут разлогинены — это нормально.
API-ключи таких сервисов, как платёжные системы, SMTP и интеграции доставки

7. Проверьте, нет ли следов атаки

Возможные признаки, которые приводят исследователи:

Ошибки лимита памяти в журналах сервера после необычных составных (multipart) запросов
Повторяющиеся ошибки HTTP 500
Аномально большие или повреждённые cookie PHPSESSID
Необъяснимые перезапуски воркеров PHP

Со стороны WordPress проверьте также, нет ли незнакомых пользователей-администраторов, новых PHP-файлов неизвестного происхождения в папке wp-content, неожиданных перенаправлений или страниц, которые вы не добавляли. Если заметите что-то подозрительное, попросите специалиста по безопасности или службу безопасности хостинга проверить сайт.

SEO-сторона: что происходит со взломанным сайтом в Google?

Уязвимость — это не только техническая проблема. Взломанные сайты часто платят высокую цену и в SEO:

Внедрение спам-контента: Злоумышленники могут добавить на ваш сайт тысячи спам-страниц. Эти страницы индексируются, и страдают авторитет и надёжность вашего сайта.
Скрытые перенаправления: Ваших посетителей, особенно приходящих из Google, могут перенаправлять на вредоносные сайты.
Предупреждения в результатах поиска: Если Google пометит ваш сайт как опасный, в выдаче может появиться предупреждение «Этот сайт может быть взломан», а браузеры могут предупреждать посетителей. Кликабельность резко падает.
Потеря позиций: Очистка и повторная проверка со стороны Google занимают время. В этот период возможна потеря органического трафика.

Поэтому регулярно проверяйте отчёт «Проблемы безопасности и меры, принятые вручную» > «Проблемы безопасности» в Google Search Console. Если проблема обнаружена, после очистки сайта вы можете запросить проверку на том же экране. Также убедитесь, что уведомления Search Console по электронной почте включены.

Итоги

PHP2Shell — одна из самых масштабных уязвимостей PHP за последние годы. Хорошая новость в том, что решение понятно: обновить PHP до исправленной версии. Если ваш сайт работает на старой версии PHP, это ещё и хороший повод наконец перейти на PHP 8.x. Новые версии PHP, помимо безопасности, обычно дают и лучшую производительность, а скорость — один из важных сигналов для SEO.

Если вы не уверены, какая версия стоит на вашем сайте, или вам нужна помощь при переходе, свяжитесь со мной.