Какую версию PHP выбрать для сайта в 2026 году: сроки поддержки и совместимость CMS

21 октября 2026 года проект PHP выпустил версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35 — они закрывают две критические уязвимости PHP2Shell, через которые можно выполнить код на сервере без авторизации. В том же бюллетене одна строка касается почти каждого старого сайта: «PHP 8.1 and older no longer receive updates from the PHP project» (php.net). Для сайтов на этих ветках обновления от разработчиков PHP не будет.

После такого релиза актуальная версия PHP — это прежде всего вопрос о том, придут ли на сайт следующие заплатки, а новые функции языка отходят на второй план. Мы сверили сроки поддержки веток по php.net/supported-versions и требования WordPress, 1С-Битрикс, Joomla, Drupal и Laravel по их официальным страницам — всё на 22.10.2026. Ниже таблицы сроков и совместимости, рекомендации для нового и старого сайта и порядок проверки перед переходом. Подробности самого инцидента — в нашей новости о PHP2Shell.

Сроки поддержки веток PHP на 22 октября 2026

На странице php.net сейчас четыре поддерживаемые ветки. Две получают все исправления, две — только исправления безопасности. Ветки 8.1 и старше перечислены отдельно, на странице EOL.

Ветка 8.6 пока в стадии релиз-кандидатов. По плану в вики PHP финальный релиз назначен на 19 ноября 2026 года, но сами разработчики просят не ставить тестовые сборки на рабочие сайты. CMS официально её ещё не поддерживают: в таблице Drupal, например, для 8.6 везде стоит «No».

Active, security и EOL — что эти статусы значат для сайта

У каждой ветки PHP цикл в четыре года: два года активной поддержки и два года исправлений только безопасности. Так это описано в политике на php.net, и все даты в таблице выше из неё вытекают.

• Active support — исправляют и обычные ошибки, и уязвимости, регулярно выходят точечные релизы. Сейчас это 8.4 и 8.5.
• Security fixes only — исправляют только критические проблемы безопасности, релизы выходят по необходимости. Сейчас это 8.2 и 8.3. Если на 8.3 сайт упрётся в обычный баг интерпретатора, в 8.3 его уже не починят.
• End of life — ветка не поддерживается. Формулировка php.net: пользователям «should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities».

На примере 8.2 цикл выглядит так. Ветка вышла в декабре 2022 года, активная поддержка закончилась 31 декабря 2024-го, с тех пор приходят только заплатки безопасности — как 8.2.35 от 21 октября. С 1 января 2027 года не будет и их. В заметке к релизу 8.2.35 об этом сказано прямо: после 31 декабря 2026 года исправлений безопасности не будет, переход нужно планировать (php.net).

Почему PHP 8.1 и старше опасны после PHP2Shell

PHP2Shell — две уязвимости в самом интерпретаторе, CVE-2026-109618 и CVE-2026-109619, обе с оценкой 9.2 по CVSS v4.0 от проекта PHP. По данным php.net, под риском все установки, которые обслуживают веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Обновление CMS, тем и плагинов здесь не помогает, потому что ошибка сидит ниже уровня приложения: исследователи Calif и Sansec подтвердили выполнение кода без логина на WordPress, Drupal, Joomla, Magento, Laravel и других.

Для поддерживаемых веток вопрос решается установкой патч-релиза. Со старыми ветками всё хуже:

• 8.1, 8.0 и 7.4 — проект PHP выложил только минимальные исходные заплатки в отдельных ветках на GitHub (8.1, 8.0, 7.4). Готового релиза нет: собрать и раздать пакеты должен дистрибутив, панель или хостер.
• 7.3 и старше, вся ветка 5.x — от проекта PHP нет ничего. В FAQ Tenable версии 5.4–7.3 отнесены к EOL без исправлений.

Старая ветка из пакетов дистрибутива — отдельный случай. В Ubuntu 22.04 штатный PHP — 8.1, и Canonical выпустила для него исправленный пакет 8.1.2-1ubuntu2.28 (USN-8948-1). Номер версии в выводе php -v остался старым, а заплатка внутри есть. Сервер с таким пакетом защищён лучше, чем сервер с PHP 8.1, собранным вручную или поставленным из панели, которая обновления не выпускает. Сроки поддержки такого пакета определяет дистрибутив, а не php.net, и когда поддержка самой ОС закончится, закончатся и заплатки.

Хостеры уже начали убирать старые ветки. NetAngels 21 октября сообщил, что установил исправления для 5.6, 7.4 и 8.2+, а 7.0–7.3 и 8.0–8.1 скоро уберёт из выбора (новость NetAngels). CISA для тех, кто не может обновиться или сидит на 8.1 и старше, советует убрать такие системы из открытого интернета до устранения проблемы (CISA).

Какие версии PHP поддерживают WordPress, Битрикс, Joomla, Drupal и Laravel

Свежая ветка PHP бесполезна, если на ней не работает движок сайта. Ниже данные с официальных страниц требований, проверено 22.10.2026. «Не указано» значит, что на официальной странице про эту ветку ничего нет, а не что она точно не работает.

WordPress. На странице требований рекомендована PHP 8.3 или новее; там же сказано, что WordPress работает и на 7.4+, но эти версии уже прошли EOL. Подробная таблица совместимости показывает, где проходит граница по старым версиям ядра: WordPress 6.4–6.8 с PHP 8.5 в ней не совместимы, 6.4–6.6 — ещё и с 8.4. Сайт на старом ядре нельзя просто переключить на свежий PHP — сначала обновляют сам WordPress. Последний релиз на 22.10.2026 — 7.1.3.

1С-Битрикс. На странице технических требований минимум — PHP 8.2. В справке «Переход на PHP 8.х в коробочных версиях» уточняется: с 01.02.2026 поддержка продуктов на PHP ниже 8.2 ограничена, рекомендована 8.3 или выше, а без перехода на 8.2 нельзя ставить обновления коробочных продуктов. PHP 8.1 там названа устаревшей и неподдерживаемой. Ветки 8.4 и 8.5 на официальных страницах явно не названы. Сайт на Битриксе с PHP 8.2 упирается в конец её поддержки 31 декабря 2026 года, и ближайшая цель для него — 8.3.

Joomla. Для текущей 6.1 руководство указывает минимум 8.3.0 и рекомендует 8.4. PHP 8.5 на странице не упоминается.

Drupal. Официальная таблица разводит ветки ядра. Drupal 10.4–10.6 работает на PHP 8.1–8.4, Drupal 11.3 и 11.4 — на 8.3–8.5, для Drupal 12.0 указана только 8.5. Drupal 11.1 и 11.2 на 8.5 не заявлены.

Laravel. В политике поддержки у каждой версии фреймворка свой диапазон PHP. Laravel 13 требует минимум 8.3 и поддерживает 8.3–8.5. У Laravel 12 исправления ошибок закончились 13.08.2026, исправления безопасности идут до 24.02.2027. Laravel 11 (PHP 8.2–8.4) получал заплатки безопасности до 12.03.2026.

Чаще всего тормозят переход не ядра, а дополнения: плагины WordPress, модули Битрикса из Marketplace, расширения Joomla, пакеты Composer. Поддержку ветки PHP у каждого из них проверяют отдельно — как это сделать, разберём ниже.

Станет ли сайт быстрее на новой версии PHP

Универсальной цифры прироста нет. В анонсе PHP 8.5 сказано про «improved performance», но без замеров. Скорость конкретного сайта зависит от кода, OPcache, базы данных и кэширования, поэтому чужие бенчмарки к вашему проекту напрямую не переносятся. Если готовый ответ отдаёт веб-сервер или CDN без запуска PHP, смена версии PHP на такие попадания в кэш практически не влияет.

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

URL=https://staging.example.ru/catalog/
for i in $(seq 1 20); do
  curl -o /dev/null -sS -w '%{http_code} %{time_starttransfer}\n' "$URL"
done | awk '$1 == 200 {print $2}' | sort -n | awk '{t[NR]=$1}
  END {if (NR == 0) {print "нет ответов 200"; exit 1}
       m = NR % 2 ? t[(NR+1)/2] : (t[NR/2] + t[NR/2+1]) / 2
       print "успешных ответов:", NR, "медиана TTFB, с:", m}'

В выборку попадают только ответы с кодом 200: редиректы, страницы ошибок и сетевые сбои отбрасываются, а сообщения curl об ошибках видны в консоли. Адрес указывают конечный, без редиректа, иначе замер покажет время ответа с кодом 301.

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

Какую версию PHP выбрать: рекомендации по веткам

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

Новый сайт. Выбирайте 8.5 или 8.4. Ставить 8.3 на сайт, который запускается в конце 2026 года, значит заранее назначить себе переезд через год. На 8.6 до финального релиза и поддержки в CMS не переходите.

Сайт на 8.3 или 8.4. Срочно — только установить патч-релиз от 21 октября или исправленный пакет дистрибутива. Плановый переход на 8.4–8.5 для сайтов на 8.3 укладывается в 2027 год.

Сайт на 8.2. Заплатку PHP2Shell ставят сейчас, а переезд на 8.3 или 8.4 нужно успеть до 31 декабря 2026 года. Причина — конец поддержки самой ветки 8.2; будущие минимальные требования Битрикса стоит сверять по его справке отдельно.

Сайт на 8.1 и старше. Если код на новой ветке не запускается, остаются временные меры: патченный пакет дистрибутива (как 8.1 в Ubuntu 22.04), пакет хостера или панели с бэкпортом, а для рискованных проектов — закрыть внешний доступ к PHP-приложению до переезда. Если нужна страница обслуживания, её отдают статикой с веб-сервера, не передавая запросы в PHP: режим обслуживания средствами самой CMS по-прежнему запускает уязвимый интерпретатор. Отключение session.upload_progress и правила WAF лишь снижают риск, но не защищают: по официальному бюллетеню, полных обходных мер нет и единственный безопасный вариант — обновление. Миграцию старого кода обычно выгоднее спланировать сразу до 8.4, чем идти по одной ветке.

На VPS выбор ветки начинается с выбора ОС. В штатных репозиториях Ubuntu 24.04 стоит PHP 8.3, в Ubuntu 26.04 — 8.5, в Debian 12 — 8.2, в Debian 13 — 8.4 (по бюллетеням Ubuntu и трекеру Debian). Остальные ветки ставят из сторонних репозиториев. Чем отличаются эти системы для сервера, мы разбирали в статье «Ubuntu или Debian», а серверы под такие задачи собраны в каталоге Linux VPS.

Как проверить совместимость перед переходом на новую ветку

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

1. Узнать, какая версия обслуживает сайт на самом деле. В WordPress: «Инструменты → Здоровье сайта → Информация → Сервер». В консоли php -v показывает CLI, а сайт может работать через другую ветку PHP-FPM. Подробно — в гайде как узнать версию PHP.
2. Сделать бэкап файлов и базы. Для WordPress — по инструкции бэкап WordPress перед обновлением PHP, для сервера целиком — по схеме из статьи о бэкапах VPS. Снапшот диска тоже пригодится, но бэкап он не заменяет, об этом мы писали в материале «снапшот или бэкап».
3. Обновить ядро и дополнения до версий, где разработчик заявляет поддержку целевой ветки. Заброшенные плагины без обновлений больше года — первые кандидаты на замену.
4. Прочитать раздел несовместимых изменений в руководстве по миграции на php.net: на 8.4, на 8.5. При прыжке через несколько веток читают все промежуточные.
5. Прогнать код через статический анализ (команды ниже).
6. Переключить PHP на тестовой копии, включить журнал ошибок и пройти ключевые сценарии: формы, корзину, оплату, личный кабинет, админку, задания cron. Как включить вывод ошибок и читать их — в гайде «ошибки PHP».
7. Переключить рабочий сайт в часы минимальной нагрузки, держа под рукой откат: на хостинге это смена версии в панели, на VPS — старая ветка PHP-FPM, которую удаляют после нескольких дней без ошибок. Пошагово — в инструкциях как обновить PHP на хостинге и на VPS.

Какие ветки PHP стоят на сервере и что обслуживает сайт

На Ubuntu и Debian с пакетами из репозиториев конфигурации разных веток лежат в /etc/php/, а у каждой ветки PHP-FPM своя служба. Команды ниже только читают состояние системы.

ls /etc/php/
systemctl list-units --type=service 'php*-fpm*'
php -v
apache2ctl -M 2>/dev/null | grep -i php
dpkg -l 'php*' | grep '^ii'
zgrep -lE 'CVE-2026-10961[89]' /usr/share/doc/php*/changelog.Debian.gz

Последняя строка — вспомогательная: она ищет номера CVE PHP2Shell в локальных changelog пакетов. Пустой вывод не доказывает, что исправления нет, а найденное совпадение — что сайт обслуживает именно этот пакет. Надёжнее сверить полную версию пакета, через который работает сайт (FPM, CGI или модуль Apache), с бюллетенем поставщика: в USN-8948-1 исправленные версии перечислены для каждого выпуска Ubuntu. Если версия ниже указанной, обновите PHP по инструкции для VPS.

Синтаксическая проверка на целевой ветке

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

find /var/www/example.ru -type f -name '*.php' -print0 \
  | xargs -0 -n1 -P4 php8.4 -l 2>&1 | grep -v '^No syntax errors'

PHPCompatibility для PHP_CodeSniffer

PHPCompatibility проверяет код на удалённые и устаревшие функции для заданной версии PHP. Стабильный релиз 9.3.5 вышел в декабре 2019 года, раньше PHP 8.0, поэтому для веток 8.x нужна ветка 10 — на 22.10.2026 она в статусе alpha (репозиторий проекта). Ставить её лучше в отдельный каталог, а не в корень сайта. Понадобится Composer (sudo apt install composer).

PC=$(mktemp -d) && cd "$PC" && echo '{}' > composer.json \
  && composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true \
  && composer require --dev phpcompatibility/php-compatibility:"^10.0.0@dev" \
  && "$PC"/vendor/bin/phpcs -p /var/www/example.ru --standard=PHPCompatibility \
       --runtime-set testVersion 8.4 --extensions=php --report=summary

Каждый шаг выполняется, только если предыдущий прошёл без ошибки, а mktemp -d каждый раз создаёт новый пустой каталог, так что существующие файлы не перезаписываются.

У проектов на Composer, включая Laravel, есть ещё одна быстрая проверка: composer check-platform-reqs сверяет версию PHP и расширения с требованиями установленных пакетов (документация Composer). Запускают её под той веткой PHP, на которую собираются переходить.

Популярный плагин PHP Compatibility Checker для WordPress в такой проверке не помощник. На его странице в каталоге разработчик WP Engine прямо пишет, что плагин больше не поддерживается и новых релизов, включая исправления безопасности, не будет. Проверен он только до WordPress 6.4.

Если сайт на обычном хостинге

На виртуальном хостинге версию PHP выбирают в панели, а исправленные сборки ставит сам хостер. Владельцу сайта остаётся выбрать ветку не ниже 8.3 и уточнить у поддержки, установлены ли релизы от 21 октября для выбранной ветки. Часть хостеров публиковала заявления по PHP2Shell: например, Beget 21 октября сообщил о временных ограничениях на виртуальном хостинге, а владельцам VPS предложил обновлять PHP самостоятельно (новость Beget). На VPS обновления PHP, как и остального софта, ставит владелец сервера. Другой инцидент той же недели касался уже не PHP, а панели виртуализации хостеров, — о нём в нашей новости про атаки на VMmanager 6.

Если в панели нет свежих веток или хостер не ответил про заплатки, это повод сравнить варианты. В каталоге собраны хостинги с PHP, отдельно — хостинг для WordPress и для Битрикса. При переезде полезна инструкция, как перенести сайт на другой хостинг.

Что брать в 2026 году

• Новый сайт — PHP 8.5, если её официально поддерживают CMS и плагины; иначе 8.4. Исправления безопасности: 8.5 — до конца 2029 года, 8.4 — до конца 2028-го.
• Битрикс — не ниже 8.3, как рекомендует производитель; 8.4 и 8.5 — только после проверки на тестовой копии, официально эти ветки не названы.
• Сайт на 8.2 — поставить 8.2.35 сейчас и переехать до 31 декабря 2026 года.
• Сайт на 8.1 и старше — переезд без отсрочки. До него держать только патченные пакеты дистрибутива или хостера.
• Перед любым переходом: бэкап, обновление ядра и плагинов, php -l и PHPCompatibility, тестовая копия с журналом ошибок, план отката.