Хостинг говорит, что PHP обновлён: как проверить, что это правда

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

Почему «обновлено» ещё не значит «защищено»

• Обновили не тот сайт. На аккаунте бывает несколько доменов, поддоменов и тестовых копий, и во многих панелях версию PHP выбирают для каждого отдельно.
• Обновили только консольный PHP. Команда php -v показывает версию для терминала и cron. Сайт в браузере обслуживает другой PHP: PHP-FPM, Apache или LiteSpeed, и это могут быть разные версии.
• Процессы не перезапущены. Пакет обновлён на диске, но воркеры PHP-FPM или Apache, запущенные раньше, выполняют старый код, пока их не перезапустят.
• Версия в строке обманывает в обе стороны. Дистрибутивы Linux (Debian, Ubuntu) часто переносят исправления в пакет со старым номером версии: по номеру сайт выглядит уязвимым, а по сути уже закрыт. Бывает и наоборот.

Проверка 1. Какую версию видит именно сайт

Без терминала:

• WordPress: Инструменты → Состояние сайта → вкладка «Информация» → раздел «Сервер», строка «Версия PHP».
• Временный файл phpinfo: файл с одной строкой <?php phpinfo(); в корне сайта, открыть в браузере и сразу удалить: страница выдаёт слишком много о сервере, чтобы оставлять её публичной.
• Заголовок ответа: команда curl -sI https://example.com | grep -i x-powered-by покажет PHP/8.x.y, если администратор не отключил этот заголовок. Часто он отключён, и тогда пустой результат ничего не доказывает.

Проверка 2. Сравните с исправленными версиями

Исправления вышли для веток 8.5 (8.5.12), 8.4 (8.4.27), 8.3 (8.3.36) и 8.2 (8.2.35). Для 8.1 и старше официального исправления нет. Ваша версия такая же или новее соответствующей из списка? Хорошо. Ниже? Не спешите с выводом: если сервер на Debian или Ubuntu, спросите хостинг, содержит ли пакет исправления CVE-2026-109618 и CVE-2026-109619. Журнал изменений пакета это показывает, и хостингу ответить на такой вопрос несложно.

Проверка 3. Перезапущены ли процессы

Обновление без перезапуска работает только на диске. Спросите хостинг прямо: «после обновления вы перезапустили PHP-FPM (или Apache) и когда именно?». Если у вас есть SSH, время запуска процессов видно командой ps -eo pid,lstart,cmd | grep -E "php-fpm|apache2|httpd": дата старта должна быть позже времени обновления.

Проверка 4. Все места, где живёт PHP

• Все домены и поддомены на аккаунте, включая тестовые копии и забытые старые сайты: один необновлённый сайт на аккаунте остаётся точкой входа, даже если главный уже закрыт.
• Отдельные пулы PHP-FPM для разных сайтов.
• Задания cron и консольные скрипты: они запускаются тем PHP, что в терминале, а не веб-версией.

Что спросить у хостинга

1. Какая точная версия PHP сейчас у моего сайта (не «8.3», а полностью, с третьим числом или номером пакета)?
2. Входят ли в этот пакет исправления CVE-2026-109618 и CVE-2026-109619?
3. Когда после обновления перезапущены PHP-FPM или веб-сервер?
4. Применено ли то же самое ко всем моим доменам и поддоменам?
5. Если у меня PHP 8.1 или старше: есть ли у вас пакет с исправлением, или нужно переходить на новую ветку?

Если хостинг не может или не хочет

Бывают хостинги, которые предлагают только устаревшие ветки PHP. Тогда остаются два пути: перейти на ветку с исправлением (8.2–8.5), предварительно проверив на копии сайта, работают ли плагины и модули, или перенести сайт на сервер, где вы сами управляете версией. Мы делаем и то, и другое: обновление PHP и защита сервера проходит на копии сайта, с проверкой совместимости и отчётом о состоянии.

Ни одна проверка не даёт стопроцентной гарантии. Она закрывает типичные ошибки, но не заменяет резервных копий и мониторинга.