PHP2Shell: критические уязвимости PHP — Ваш сайт уже обновлён?

01Что такое PHP2Shell?

PHP выполняет код сайта на сервере, например для WordPress и Joomla. В подготовке сообщений о PHP2Shell участвовали, в частности, Wiz, OpenAI и Calif. Уязвимостям присвоены идентификаторы CVE-2026-109618 и CVE-2026-109619. В бюллетенях PHP обе оценены как критические: 9,2 из 10 баллов по CVSS v4.0. Это показатель серьёзности, а не вероятности взлома Вашего сайта.

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

PHP перечисляет PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed как варианты работы, которые необходимо проверить. Для mod_php продемонстрирована атака до выполнения кода сайта. Для FPM PHP Foundation сообщает о выполнении кода через пути в приложении; при этом в бюллетене OOM полный эксплойт для этого ещё не описан. Для второй ошибки подтверждён путь атаки через FPM при определённых условиях в приложении. Поэтому само использование FPM не даёт оснований считать сайт защищённым.

По данным Wiz, затронуты версии начиная с PHP 5.4: для каждой из них актуальна как минимум одна уязвимость. Не каждая атака работает при любой конфигурации. Главное — исправить именно ту среду выполнения PHP, которая фактически используется.

02Насколько это опасно?

Успешная атака позволяет выполнять код с правами рабочего процесса PHP. Доступность файлов и баз данных зависит от его разрешений; полные права администратора сервера из этого автоматически не следуют. Wiz также продемонстрировала чтение конфиденциальных данных процесса: паролей, токенов и API-ключей. Под угрозой могут оказаться, например, данные для входа и сведения о клиентах.

Cloudflare сообщает об атакующем трафике в связи с преждевременным раскрытием уязвимостей и об изменении схем атак. watchTowr сообщает об активных попытках эксплуатации. CERT-EU рекомендует немедленно установить обновления, а если это невозможно — рассмотреть изоляцию общедоступных приложений. Аналогичные рекомендации опубликовал нидерландский NCSC. BSI выпустило предупреждение; у CERT-Bund зафиксировано уведомление WID-SEC-2026-4055.

Попытки атак ещё не доказывают, что взломы были успешными. Достоверного общего числа скомпрометированных систем в источниках нет. Сообщения о попытках делают обновление срочным, но не позволяют определить, сколько времени осталось до атаки на Ваш сайт.

03Какие версии 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. Регулярная поддержка безопасности заканчивается 31 декабря 2026 года; запланируйте переход на поддерживаемую ветку.
• PHP 8.1, 8.0 и 7.4 больше не получают регулярных обновлений от проекта PHP. Для них в виде исключения доступны патчи исходного кода и пакеты провайдеров. Plesk указывает исправленные сборки от 21 октября для 8.1.34, 8.0.30 и 7.4.33 под Linux. Отображаемая версия PHP может остаться прежней. Для cPanel и Ubuntu решающее значение имеют полные идентификаторы пакетов.
• Для более старых веток также есть отдельные бэкпорты провайдеров: Hetzner сообщает об исправленных PHP 5.6 и 7.3 для своего веб-хостинга и управляемых серверов. Это не распространяется на любые установки. Если исправление не подтверждено, нужно согласовать обновление, смену версии или временную блокировку доступа.

04Как проверить, затронут ли мой сайт?

При Shared Hosting несколько клиентов пользуются общей серверной инфраструктурой, а пакетами PHP управляет Hoster. Часто Вы можете выбрать ветку версии, но не установить обновление безопасности самостоятельно. Запросите подтверждение для каждого домена, поддомена и дополнительного PHP-приложения. Даже сайт, созданный агентством, может быть размещён у другого провайдера.

• WordPress: Инструменты → Здоровье сайта → Информация → Сервер показывает версию PHP. Даже версия с номером ниже указанного выше может быть исправлена бэкпортом. В таком случае запросите идентификатор пакета и соответствующий бюллетень безопасности.
• Plesk: Домены → Ваш домен → Настройки PHP → «Показать информацию phpinfo()». Сравните версию и «Build Date» с сообщением Plesk для конкретного пакета. Произвольная новая дата сборки не доказывает наличие исправления. Если доступа нет, обратитесь к Hoster.
• cPanel: Software → MultiPHP Manager показывает версию для каждого домена, если Ваш Hoster предоставляет эту функцию. Проверьте все нужные домены: они могут использовать разные версии PHP.
• Hostinger: hPanel → Websites → Dashboard → PHP Info. Только для собственных обновлённых пакетов Hostinger называет достаточной дату сборки 21 октября 2026 года или позднее. Сообщение о завершении обновлений управляемого хостинга опубликовано 22 октября в 06:44 UTC, то есть в 08:44 по центральноевропейскому летнему времени (MESZ). Клиенты VPS управляют PHP самостоятельно.
• Hetzner сообщает о завершении обновлений PHP 7.4 и 8.0–8.5 на веб-хостинге и управляемых серверах 21 октября в 19:50 MESZ, а версий 5.6 и 7.3 — 22 октября в 06:32 MESZ. Эти заявления провайдера не подтверждают автоматически состояние выделенных или облачных серверов, которыми клиенты управляют самостоятельно.
• Другие провайдеры: запросите подтверждение для Вашего домена. Если публичное сообщение не найдено, это не доказывает отсутствие патча. При наличии SSH-доступа команда `php -v` показывает версию для командной строки; сайт может использовать другой процесс PHP.

05Что написать моему Hoster?

Напишите в поддержку хостинга или специалисту, который обслуживает Ваш сайт. Если хостинг сторонний, агентству следует привлечь оператора сервера. Скопируйте этот запрос:

«Устранены ли CVE-2026-109618 и CVE-2026-109619 для всех версий PHP моих доменов [Domains]? Прошу подтвердить фактически используемые веб-версии PHP, полные идентификаторы пакетов/сборок, при необходимости — наличие бэкпорта, а также время активации и перезапуск всех рабочих процессов PHP. Обновлены ли также панель управления и веб-почта на PHP? Если что-то ещё не исправлено: когда будет установлено исправление и как до этого момента будет заблокирован публичный доступ вне PHP?»

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

PHP сайта и внутренний PHP панели нужно проверять отдельно. Для Plesk производитель указывает 18.0.81 Update 4 либо 18.0.80 Update 11 для исправления sw-engine. Для cPanel/WHM названы 11.110.0.153, 11.134.0.66, 11.136.0.50 и 11.138.0.18. Дополнительно необходимо обновить PHP-пакеты самих сайтов.

Не забудьте об электронной почте: внутренний PHP cPanel используется и для веб-почты Roundcube. Обновлённый сайт не подтверждает, что доступ к веб-почте исправлен. Попросите отдельно проверить среду выполнения веб-почты, в том числе при использовании других панелей. Уязвимости PHP не доказывают ни взлом каждого почтового ящика, ни безопасность Ваших почтовых сервисов.

После обновления: получите подтверждение состояния PHP и перезапуска, затем проверьте основные операции — вход, контактную форму и оформление заказа. Уточните наличие резервных копий файлов и базы данных, а также возможность восстановления из них. Резервная копия не заменяет патч. При подозрительных изменениях специалисту следует сохранить файлы и журналы до очистки, расследовать инцидент и после очистки заменить затронутые учётные данные. Один патч не удаляет уже внедрённый вредоносный код.

06Что делать, если обновление нельзя установить сразу?

Обсудите с оператором временную изоляцию. CERT-EU рекомендует при необходимости закрыть общедоступные приложения до установки и проверки исправления. Блокировка на веб-сервере или межсетевом экране должна срабатывать до PHP; страницы технического обслуживания WordPress для этого недостаточно. Ограничение доступа явно разрешёнными IP-адресами может сузить круг подключений, но не устраняет уязвимости.

Для администраторов PHP предлагает ограниченные временные меры: установить `memory_limit=-1`, по возможности запретив изменение этого значения; реальная нехватка памяти остаётся опасной. Установить `post_max_size=8M`, если загрузка файлов не нужна, либо `32M`, если нужна, а `upload_max_filesize` оставить ниже этого значения. Дополнительно ограничить размер и сложность запросов на веб-сервере или прокси, даже при отсутствии пригодного Content-Length. Ограничения контейнеров/cgroup могут поддержать доступность; `RLIMIT_AS` и `RLIMIT_DATA` их не заменяют. Это не инструкция по внесению непроверенных изменений в клиентской панели.

Для других путей атаки: настроить `session.upload_progress.enabled=0` до чтения запроса, например в php.ini или пуле FPM; `ini_set()` и FPM-`.user.ini` недостаточно. В PHP 8.5 дополнительно установить `fatal_error_backtraces=0`, затем перезапустить все рабочие процессы. Специалист должен проверить ошибочные настройки, возможность вызвать фатальные ошибки и превышения времени ожидания. Скрытие сообщений об ошибках не помогает. Эти меры не закрывают все пути атаки.

С 21 октября, 03:02 UTC, то есть 05:02 MESZ, Cloudflare предлагает дополнительные правила и на тарифе Free, если сайт использует защиту WAF. На платных тарифах попросите проверить Cloudflare Managed Ruleset с «Generic Rules – Anomalous Execution» в режиме Block. В Free Ruleset правила активируются автоматически. Обновление PHP всё равно необходимо.

07Что мы сделали для наших клиентов?

При проверке 22 октября на наших хостинг-серверах были установлены Plesk-PHP 8.0–8.5 со сборками от 21 октября, соответствующими бюллетеню безопасности Plesk. К утру 22 октября процессы PHP-FPM были перезапущены на всех серверах. Панель управления мы проверяем отдельно.

Для сайтов на нашем хостинге Вам не нужно ничего устанавливать самостоятельно. Это прямо не распространяется на сайты на стороннем хостинге, даже если мы их создали или обслуживаем: там наличие исправлений должен подтвердить соответствующий оператор. Пожалуйста, по-прежнему сообщайте нам обо всём необычном на Вашем сайте.

08Частые вопросы о PHP2Shell