Почему обновлённый WordPress всё ещё требует проверки PHP

Обновление ядра WordPress не устанавливает новую версию PHP: это отдельный компонент со своим циклом поддержки. Поэтому свежая CMS может работать на неподдерживаемом интерпретаторе. Я покажу, как узнать версию PHP именно для сайта, проверить её поддержку и безопасно спланировать обновление без ложного вывода, будто одна старая версия уже доказывает взлом.

Что обновляет WordPress, а что остаётся на сервере

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

Поэтому ответ на вопрос «почему сайт уязвим после обновления» зависит от того, какой компонент затронут проблемой. Если уязвимость находится в ядре, нужен исправленный выпуск WordPress. Если проблема в PHP, обновление CMS её не закрывает. Если в расширении или теме — патч ищут у их разработчиков. А ещё у сайта могут быть слабые пароли, лишние учётные записи или заражённые файлы. Сам факт, что сайт работает на старой ветке PHP, повышает риск из-за отсутствия обычных исправлений, но сам по себе не устанавливает причину конкретного взлома.

Я не считаю версию WordPress универсальным сертификатом безопасности. Это один пункт инвентаризации. Нужно знать, какие версии обслуживают публичные запросы, получают ли они исправления и какие части приложения реально включены. Удалённый неактивный плагин, оставленная старая копия сайта и активная тема — разные ситуации. В отчёте я разделяю подтверждённые уязвимости, неподдерживаемые компоненты и просто подозрительные признаки. Иначе администратор получает длинный список страшных слов, а не ответ, что исправлять первым.

• Ядро WordPress — отдельное обновление.
• Плагины и темы обновляются отдельно.
• PHP обновляется на уровне хостинга или сервера.

Как понимать версии WordPress и сроки поддержки PHP

На дату проверки, 26 октября 2026 года, в документации WordPress указан выпуск 7.1.3 от 6 октября. Это полезная точка отсчёта для примера, но перед публикацией и перед каждым обновлением я сверяю актуальный выпуск на WordPress.org: номера меняются. Ранее, 17 июля, WordPress выпустил 6.8.6, 6.9.5 и 7.0.2 с исправлениями безопасности для соответствующих веток. Это конкретный пример того, что обновление ядра закрывает проблемы именно в ядре. Оно не меняет системный PHP на том же сервере.

С PHP смотрю не только на первую цифру, но и на поддержку конкретной ветки. На официальной странице WordPress рекомендует PHP 8.3 или новее, однако в старой среде сайт ещё может запускаться на PHP 7.4. Запускаться — не значит получать исправления: PHP 7.4 и 8.0 уже сняты с поддержки самим PHP-проектом. При этом поставщик Linux или хостинг может отдельно выпускать патчи для своего пакета. Поэтому при старом номере версии нужно проверить не только баннер WordPress, но и источник пакетов и его бюллетени безопасности.

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

Есть и ближайшая дата, которую нельзя проспать: на 26 октября ветка PHP 8.2 получает критические исправления безопасности до 31 декабря 2026 года, после чего поддержка PHP Group заканчивается. У 8.3 такой срок — до конца 2027 года. Значит, «ещё поддерживается сегодня» не всегда означает «разумно оставить на весь следующий год». Владелец сайта должен записать срок следующего пересмотра версии, а не только номер, который показала панель.

• Сверьте текущую ветку WordPress с официальным выпуском.
• Уточните статус поддержки PHP у проекта и поставщика пакета.
• Проверьте совместимость темы и расширений с целевой версией.

Условный пример: PHP 7.4 за свежим ядром

Для наглядности разберу условный пример ООО «Домино-Сервис» — это сценарий, а не подтверждённый отчёт о реальном инциденте. Представим: на 26 октября 2026 года сайт обновлён до WordPress 7.1.3, а в панели хостинга для домена выбран PHP 7.4 через PHP-FPM. В админке страницы открываются, формы отвечают, и явного сбоя нет. Это говорит только о том, что текущий набор кода пока запускается. Статус безопасности PHP из этого не следует, как не следует и вывод, что именно PHP стал причиной гипотетической атаки.

Я бы зафиксировал здесь два разных результата. По CMS проверил бы, что установлен актуальный исправленный выпуск. По среде отметил бы, что PHP 7.4 больше не получает исправления от основного проекта, а поддержку хостинга надо подтвердить отдельно. Затем запросил бы у провайдера поддерживаемую целевую ветку, сделал копию сайта и проверил её. Итог аудита — понятный план обновления и точная версия PHP, которую видит сайт. Это полезный результат; фраза «перешли на новую PHP, взломы прекратились» была бы выдумкой, пока нет фактов о взломе и проверки его причины.

Я отдельно смотрю, нет ли у домена второго обработчика PHP, тестовой копии или задания планировщика, которое запускает другой бинарный файл. На shared-хостинге это выясняют в панели и у поддержки; на сервере с несколькими пулами — по конфигурации конкретного сайта. Нельзя механически переносить версию из одного окна на все домены. Сначала связываю домен, виртуальный хост и фактический PHP-процесс, затем записываю исходное состояние. Так после изменения будет понятно, какой именно сайт проверяли.

Как проверить PHP именно для сайта

В панели WordPress откройте «Инструменты → Здоровье сайта → Информация → Сервер» и найдите строку версии PHP. Это сведения о серверной среде, с которой работает сайт. На хостинге дополнительно проверьте выбранную для домена версию PHP и список обработчиков, если панель это показывает. Для собственного VPS команда php -v выводит версию командной строки. Она удобна для проверки установленного CLI-бинарного файла, но не доказывает, что запросы сайта идут через тот же PHP-FPM или CGI.

Не публикуйте файл с phpinfo() в корне сайта ради быстрого замера. Эта функция выводит не только версию, но также настройки, расширения, пути и данные окружения. Если временная диагностическая страница уже создана, ограничьте доступ и удалите её после проверки. Для WordPress достаточно сначала посмотреть «Здоровье сайта», панель провайдера и, если остаётся расхождение, уточнить у поддержки, какая версия назначена именно домену и PHP-FPM-пулу.

Запишите результат для каждого сайта отдельно: домен, версия WordPress, версия веб-PHP, способ запуска, статус поддержки и владелец обновления. Для PHP под управлением хостинга владельцем часто будет провайдер; для контейнера — тот, кто собирает и разворачивает образ; для пакетов на VPS — администратор сервера. Если обслуживание разделено, назначьте одного ответственного за подтверждение установки патча. Непроверенная задача в тикет-системе не меняет исполняемый файл.

Информацию из «Здоровья сайта» не нужно публиковать целиком в открытом тикете или пересылать незнакомому подрядчику. Там есть технические сведения о сервере, конфигурации и версиях компонентов. Для вопроса о PHP обычно достаточно названия домена, версии веб-обработчика и способа запуска, а лишние строки можно скрыть. Я сохраняю полную диагностику в доступном только рабочей команде месте, а наружу отправляю минимальный фрагмент, который нужен для решения конкретной задачи.

• WordPress: «Инструменты → Здоровье сайта → Информация → Сервер».
• Хостинг: версия PHP для нужного домена.
• CLI: `php -v` показывает именно CLI.
• После сверки зафиксируйте владельца обновления.

Как обновить PHP и не устроить простой

Перед переключением я выясняю, какая версия PHP поддерживается WordPress и его активными расширениями. Смотрю описание и журнал изменений плагинов, требования темы, критичные интеграции и ограничения провайдера. Затем сохраняю код, базу данных и загруженные файлы так, чтобы восстановление было возможно отдельно от основного сайта. Резервная копия без проверки восстановления — это обещание, а не план отката. На тестовой копии ставлю целевую ветку и прохожу сценарии, от которых зависит работа бизнеса: вход в админку, публикация материала, формы, загрузка файлов, заказ или другой основной путь посетителя.

Если тестовая копия отработала, согласую окно изменения, переключаю версию в панели или обновляю пакет поддерживаемым способом, а затем повторяю проверки уже на рабочем домене. Смотрю журнал ошибок и наблюдаю за страницами, которые используют сторонние расширения. Если появилась совместимая ошибка, сначала определяю конкретный плагин или тему, а не объявляю новую PHP плохой. Откат заранее проверен и выполняется по плану. Для срочного патча откладывать решение на неопределённый срок опасно; тогда я сокращаю объём теста до ключевых функций и фиксирую остаточные риски.

Провайдер не всегда даёт клиенту самому выбирать обработчик и сроки обновления. Это ограничение конкретного тарифа, а не свойство WordPress. Я прошу подтвердить версию веб-PHP, источник пакета, наличие исправлений и доступный порядок переключения. Если нужной поддерживаемой версии нет, оцениваю перенос на тариф или площадку, где её можно получать. Смену размещения планируют отдельно: сначала проверяют резервную копию, DNS, доступы и совместимость сайта, потом переносят. Самостоятельно подменять системные библиотеки на общем сервере нельзя.

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

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

Почему WP_AUTO_UPDATE_CORE не обновляет PHP

Константа WP_AUTO_UPDATE_CORE управляет автоматическими обновлениями ядра WordPress. В официальной документации для неё описаны значения true, false и minor; они меняют политику обновления версий ядра. Ни одно из этих значений не переключает PHP на сервере. Если в конфигурации включены автообновления ядра, это хорошо для своевременных исправлений WordPress, но по версии PHP нужно смотреть отдельно.

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

Я не советую лечить несовместимость случайным отключением функций PHP или бессрочно держать сайт на неподдерживаемой ветке. Сначала ищут версию расширения, где исправлена совместимость, затем проверяют замену или оценивают доработку. Если продление поддержки старого пакета предоставляет поставщик операционной системы, это нужно подтвердить документально. Формулировка «у нас PHP 7.4, значит, скоро обязательно взломают» неверна; правильный вывод — выяснить, кто и до какого срока поставляет исправления, а затем принять решение.

• `WP_AUTO_UPDATE_CORE` относится к ядру WordPress.
• PHP обновляется на уровне хостинга, ОС или образа.
• Расширения и темы проверяются отдельно.

Что проверять, если сайт всё-таки взломали

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

После очистки отдельно проверьте ядро WordPress, все плагины, тему, PHP веб-процесса и пакеты окружения. Уберите неиспользуемый код и учётные записи, подтвердите успешное восстановление резерва и настройте уведомления о новых обновлениях. Если сведения указывают на конкретную уязвимость в PHP, сверяйте исправленный номер с бюллетенем проекта или поставщика ОС. Для отдельного разбора PHP2Shell есть материал об уязвимостях PHP в CMS; он решает более узкий вопрос, чем общий аудит обновлений.

В заключении я разделяю три вещи: обновлён ли затронутый код, получает ли серверный PHP исправления и есть ли доказательства компрометации. Отсутствие ошибок после смены PHP не подтверждает, что злоумышленника не было; неподдерживаемая версия тоже не доказывает взлом. Такая формулировка может звучать менее эффектно, зато по ней можно назначить конкретную работу и проверить её результат.

После технической очистки полезно записать дату восстановления, версию чистой копии и перечень обновлённых компонентов. Затем наблюдайте за новыми изменениями файлов и входами в административную панель, а резервную копию храните отдельно от сайта. Эти меры помогают заметить повторное заражение и восстановить известное состояние, но не позволяют задним числом угадать использованный путь атаки. Причину указывают только проверенные следы; если их нет, так и пишем в отчёте.

При проверке подозрительных файлов я сравниваю их с чистой копией той же версии WordPress и журналом развёртывания. Дата изменения файла полезна для поиска, но не доказывает, когда и кем его создали: время могло измениться при распаковке, переносе или восстановлении резервной копии. Поэтому я сопоставляю несколько независимых следов — запись в журнале веб-сервера, действие учётной записи и изменение файла. Если таких следов нет, отчёт не приписывает атаку конкретному компоненту только потому, что он выглядит старым.

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