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

21 октября 2026 года команда PHP выпустила экстренное обновление, которое закрывает две критические уязвимости в самом языке. Их назвали PHP2Shell: через них злоумышленник может выполнить свой код на сервере одним HTTP-запросом, без логина и пароля. Под удар попадают почти все версии PHP за последние десять с лишним лет, а атаки начались ещё до выхода исправления. Если ваш сайт работает на WordPress, 1С-Битрикс, Laravel, OpenCart или любом другом движке на PHP, эта статья касается и вас.

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

20 октября разработчики PHP заранее предупредили о срочном релизе, а на следующий день выпустили версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Обе уязвимости получили оценку 9.2 из 10 по шкале CVSS v4.0, это критический уровень.

• CVE-2026-109618 связана с нехваткой памяти. Когда запрос превышает лимит memory_limit, PHP аварийно его прерывает, и внутренние данные запроса могут остаться заполненными наполовину, например при разборе загружаемого файла. Код очистки затем считает эти данные корректными, что позволяет повредить память и перехватить выполнение.
• CVE-2026-109619 связана с устаревшим состоянием. После фатальной ошибки часть внутренних данных запроса может пережить освобождение памяти, и следующий запрос, который попадёт в тот же процесс PHP, воспользуется ими раньше, чем они будут сброшены.

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

Ошибки нашли летом исследователи, которые использовали для поиска ИИ-модели, и всё это время команда PHP готовила исправления.

Какие версии затронуты

• Уязвимы все версии PHP с 5.4 по 8.5.11.
• Исправления вышли в версиях 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
• Для PHP 8.1 и старше официальных релизов не будет: эти ветки уже не поддерживаются. Из-за серьёзности проблемы команда PHP опубликовала минимальные исправления в исходном коде для 7.4, 8.0 и 8.1, а часть дистрибутивов Linux и поставщиков расширенной поддержки выпускает свои пакеты.
• Уязвимы все способы, которыми PHP обрабатывает веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Самой опасной конфигурацией команда PHP называет mod_php.

Учтите и то, что поддержка PHP 8.2 заканчивается 31 декабря 2026 года. Если сайт работает на 8.2 или более старой версии, после экстренного обновления стоит запланировать переход на 8.4 или 8.5.

Атакуют ли уже

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

Поэтому искать следы взлома нужно начиная с 17 октября, а не с даты выхода обновления.

Что сделать прямо сейчас

1. Узнайте версию PHP

• в WordPress: «Инструменты» → «Здоровье сайта» → «Информация» → «Сервер»;
• в панели хостинга (cPanel, ISPmanager, Plesk) в настройках PHP для домена;
• у разработчика или студии, которая поддерживает сайт.

Команда php -v в консоли показывает версию консольного PHP, а сайт может работать на другой версии через PHP-FPM. Ориентируйтесь на версию, которую видит сам сайт или панель хостинга.

2. Обновите PHP

Обновление — единственный способ полностью закрыть уязвимости. На виртуальном хостинге PHP обновляет провайдер: спросите в поддержке, установлены ли исправленные версии. На своём сервере или VPS обновите пакеты из репозитория дистрибутива и перезапустите PHP-FPM или веб-сервер. Если PHP ставили из репозитория remirepo, имейте в виду, что в день релиза обновлений там не было, и команда PHP советовала перейти на пакеты дистрибутива или собрать PHP из исходников. Сайты в Docker нужно пересобрать на обновлённом базовом образе и перезапустить контейнеры.

3. Если обновиться сегодня нельзя

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

• выключите session.upload_progress.enabled в php.ini, настройках пула FPM или веб-сервера и перезапустите все процессы PHP. Через ini_set() или файл .user.ini эта настройка не сработает;
• на PHP 8.5 дополнительно выключите fatal_error_backtraces;
• уменьшите post_max_size: 8M, если на сайте нет загрузки файлов, и 32M, если есть;
• против первой уязвимости команда PHP предлагает снять memory_limit, но тогда один запрос сможет занять всю память сервера. Это решение требует ограничения памяти на уровне контейнера, и принимать его лучше вместе с администратором.

Если сайт работает на старой версии и быстро обновить её не получается, CERT-EU советует на время закрыть его от доступа из интернета. Для сайта, который приносит заявки, это неприятно, но взлом обойдётся дороже.

4. Проверьте сайт на следы взлома

• новые или изменённые PHP-файлы начиная с 17 октября, особенно в папках загрузок и кэша;
• незнакомые администраторы в CMS и новые пользователи на сервере;
• новые задания в cron и незнакомые процессы;
• подозрительные запросы в логах веб-сервера и всплески ошибок PHP;
• жалобы клиентов на переадресацию на чужие сайты и предупреждения в Google Search Console.

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

Что этот случай говорит о поддержке сайта

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

Часто задаваемые вопросы

Сайт на WordPress, все плагины обновлены. Я в безопасности?

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

Сайт сделан на конструкторе. Меня это касается?

Обычно нет: серверами конструкторов управляет сама платформа. Но если у вас есть отдельный сервер, например для CRM, бота или личного кабинета на PHP, проверьте его.

Защищает ли Cloudflare или другой WAF?

Частично. Cloudflare обновляет правила против известных вариантов атаки, но злоумышленники уже подбирают запросы в обход фильтров. WAF даёт время на обновление, но не заменяет его.

Как понять, что хостинг уже обновил PHP?

Посмотрите версию в панели хостинга или в «Здоровье сайта» WordPress. Для своей ветки она должна быть не ниже 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Дистрибутивы Linux иногда встраивают исправление, не меняя номер версии, поэтому если версия старше, уточните у хостинга, закрыта ли PHP2Shell.

Не уверены, что ваш сервер обновлён? Свяжитесь с нами: проверим версию PHP, установим исправление и посмотрим, нет ли следов взлома.