Какие версии PHP уязвимы: список и как проверить сайт

Как устроена поддержка версий PHP

У каждой минорной ветки PHP (например, 8.2 или 8.3) есть строго определённый срок жизни. С версии 8.1 действует схема «2+2»: первые два года ветка получает активную поддержку, то есть исправления ошибок и безопасности, а ещё два года выходят только патчи безопасности. После этого наступает статус EOL (end of life): разработчики прекращают выпускать любые исправления.

Именно статус EOL и определяет, уязвима ли версия. Когда в PHP находят новую брешь, её закрывают только в поддерживаемых ветках. Исследователи и злоумышленники при этом видят изменение в коде и точно знают, что аналогичная проблема есть в старых версиях, но исправлять её там никто не будет.

Второй важный момент: даже на поддерживаемой ветке уязвимость может быть в конкретном патч-релизе. Например, PHP 8.3.7 уже считается уязвимым, а 8.3.8 содержит исправление. Поэтому оценивать нужно не только ветку, но и номер патча после третьей точки.

Что означает EOL на практике

Если вы видите в таблице статус EOL, это не абстрактное предупреждение. Это значит, что команда PHP не будет выпускать для этой ветки исправления даже при обнаружении критической бреши с удалённым выполнением кода. Всё, что найдено после даты окончания поддержки, остаётся доступным для эксплуатации.

Особенно рискованны версии PHP 5.6 и 7.x: на них до сих пор работает множество сайтов на устаревших CMS, самописных проектах и старых интернет-магазинах. Автоматические сканеры ботнетов ищут именно такие сайты по заголовку X-Powered-By, по структуре ответов и по известным путям к уязвимым скриптам.

Отдельно отметим PHP 8.0. Многие считают его «ещё новым», но поддержка закончилась 26 ноября 2023 года. Формально это уже не безопасная версия, и миграция с неё на 8.2 или 8.3 обычно проходит заметно проще, чем с 7.x.

Номер версии — не всё: бэкпорты и дистрибутивы

Есть важный нюанс, из-за которого сканеры нередко дают ложные срабатывания. Поставщики дистрибутивов (Debian, Ubuntu, AlmaLinux и другие) могут переносить исправления безопасности в «старые» пакеты, не меняя основной номер версии. Поэтому PHP 7.4 из пакета дистрибутива с активной поддержкой может быть закрыт от известных CVE, а чистая сборка 7.4 с официального сайта PHP — нет.

Тот же принцип действует для платных программ расширенной поддержки: они выпускают патчи для веток после EOL. Это допустимый временный вариант, если срочная миграция невозможна, но не замена переходу на поддерживаемую ветку: такие патчи покрывают не все проблемы, а совместимость с новыми расширениями и библиотеками всё равно будет ухудшаться.

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

Как быстро определить версию PHP на своём сайте

Чтобы понять, нужно ли вам срочно что-то делать, достаточно узнать точный номер версии, включая патч. Самый надёжный способ — посмотреть версию именно той среды, в которой выполняется сайт, а не той, что установлена в консоли по умолчанию. На одном сервере часто работают сразу несколько версий PHP, и консольный php -v может показывать совсем другую ветку, чем FPM или модуль веб-сервера.

Удобнее всего проверять версию в панели хостинга: в большинстве панелей есть раздел выбора версии PHP для каждого домена. Вторая надёжная опция — временный файл с вызовом phpinfo(), который после проверки нужно сразу удалить, чтобы не раскрывать конфигурацию. Для WordPress, Битрикс и других CMS версия обычно отображается в административной панели в разделе диагностики.

Почему «и так работает» — плохой аргумент

Самая частая причина, по которой владельцы откладывают обновление, — страх что-то сломать. Он понятен: при переходе с 7.x на 8.x действительно исчезли или изменили поведение некоторые функции, а старые плагины и самописный код могут выдавать ошибки.

Но стоимость миграции растёт со временем. Чем дольше сайт живёт на старой ветке, тем больше накапливается несовместимостей, и тем сложнее переходить сразу через несколько мажорных версий. Плановое обновление раз в 1–2 года обходится существенно дешевле, чем срочное восстановление после взлома.

Подготовка к обновлению: на что смотреть в первую очередь

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

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