Уязвимости PHP 8.1: что угрожает сайту и как защититься
PHP 8.1 получает только патчи безопасности и подходит к концу поддержки. Разбираем критичные CVE, как проверить сайт и безопасно обновиться.
Уязвимости PHP 8.1: что нужно знать владельцу сайта
PHP 8.1 не содержит одной «главной» дыры: опасность в том, что в ранних патч-релизах ветки были критичные CVE, а сама ветка приближается к окончанию поддержки. Безопасно работать можно только на последнем патче 8.1.x, но разумнее планировать переход на 8.3 или 8.4.
PHP 8.1 вышел в ноябре 2021 года и принёс enum-ы, readonly-свойства, fibers и другие новшества. Многие проекты на Laravel, Symfony, WordPress, Bitrix и самописных движках до сих пор работают именно на нём. В статье разберём, какие уязвимости уже находили в этой ветке, чем грозит окончание поддержки, как проверить свой сервер и безопасно перейти на актуальную версию.
Почему вопрос безопасности PHP 8.1 актуален именно сейчас
Любая ветка PHP проходит три стадии: активная поддержка (исправляются ошибки и уязвимости), поддержка безопасности (выходят только критичные патчи) и полное завершение жизненного цикла (end of life, EOL). Для 8.1 первая стадия закончилась в ноябре 2023 года, и сейчас ветка живёт в режиме «только security». По официальному графику на php.net этот период заканчивается в конце 2025 года, поэтому актуальные даты стоит проверять на сайте проекта.
После EOL разработчики языка перестают выпускать исправления. При этом исследователи и злоумышленники продолжают изучать код PHP, и новые уязвимости находят в старых ветках регулярно. Разница лишь в том, что для 8.1 патча уже не будет, а для 8.3 и 8.4 он выйдет в ближайшие недели.
Вторая причина торопиться: экосистема уходит вперёд. Новые мажорные версии фреймворков и CMS всё чаще требуют PHP 8.2 и выше, а значит, вы лишаетесь обновлений не только языка, но и всего стека.
Выход PHP 8.1.0: enum, readonly, fibers, never.
Баги больше не правятся, выходят только патчи безопасности.
По графику php.net. После этой даты патчей не будет совсем.
CVE-2024-4577: самая громкая уязвимость в ветке 8.1
Наиболее известная проблема — CVE-2024-4577, уязвимость внедрения аргументов в PHP-CGI. Она получила оценку 9.8 по шкале CVSS, то есть относится к критическим. Суть в том, что на Windows из-за особенностей преобразования символов (Best-Fit) злоумышленник мог передать в PHP-CGI специально сформированный запрос и выполнить произвольный код на сервере.
Под удар попадали версии PHP 8.1 ниже 8.1.29, а также 8.2 ниже 8.2.20 и 8.3 ниже 8.3.8. Особенно рискованными оказались установки на Windows с режимом CGI, включая типовые конфигурации XAMPP. Серверы на Linux с PHP-FPM этой конкретной проблеме обычно не подвержены, но это не повод игнорировать обновления.
После исправления в 8.1.29 вышли и другие патчи безопасности ветки (8.1.30, 8.1.31, 8.1.32 и следующие). Они закрывали ошибки разбора данных, обхода защит и проблемы в отдельных расширениях. Вывод простой: если на сервере стоит не последний патч 8.1.x, вы работаете с известными, публично описанными уязвимостями.
Опасность таких CVE в том, что после публикации информации о дыре появляются готовые эксплойты, а боты начинают массово сканировать интернет. Время между раскрытием уязвимости и первыми атаками исчисляется днями, а иногда часами.
В итоге сайт может стать частью ботнета, начать рассылать спам или раздавать вредоносный код посетителям. Это приводит к санкциям поисковиков: Яндекс и Google помечают такие ресурсы как опасные, а позиции в выдаче и трафик падают.
| Класс риска | Чем опасен | Как снизить риск |
|---|---|---|
| Удалённое выполнение кода (RCE) | Полный контроль над сервером и данными сайта | Последний патч 8.1.x или переход на 8.3/8.4, отказ от CGI на Windows |
| Утечка или повреждение памяти | Падение процессов, в тяжёлых случаях выполнение чужого кода | Своевременные обновления PHP и расширений |
| Обход проверок и защит | Подмена cookie, обход авторизации, загрузка лишнего | Актуальные CMS, плагины и серверные настройки |
| Отказ в обслуживании (DoS) | Зависание сайта, перегрузка сервера, простои | Лимиты запросов, WAF, мониторинг нагрузки |
Опасность не только в самом PHP
Когда говорят об «уязвимости PHP 8.1», часто имеют в виду совсем другое: дыры в плагинах WordPress, модулях Bitrix, устаревших библиотеках из Composer или в самописном коде. На практике именно они приводят к взломам чаще, чем баги интерпретатора.
Старая версия PHP усугубляет ситуацию: не все современные библиотеки поддерживают 8.1, а значит, вы рискуете застрять на устаревших пакетах с известными уязвимостями. Поэтому безопасность нужно оценивать комплексно: версия языка, зависимости, конфигурация сервера и права на файлы.
Как проверить и обезопасить сайт на PHP 8.1
- 01
Узнайте точную версию. Выполните php -v в консоли и проверьте версию, с которой реально работает веб-сервер (php-fpm или модуль Apache): они могут отличаться от консольной. Страницу phpinfo() после проверки обязательно удалите.
- 02
Сверьте патч-релиз. Сравните номер 8.1.x с последним выпуском на php.net. В Debian, Ubuntu и RHEL исправления часто переносят в «старые» номера, поэтому сверяйтесь ещё и с журналом изменений пакета в вашем дистрибутиве.
- 03
Проверьте зависимости. Запустите composer audit: команда сопоставит установленные пакеты с базой известных уязвимостей. Обновите то, что имеет исправления.
- 04
Поднимите тестовую копию на PHP 8.3 или 8.4. Включите error_reporting в режим E_ALL, прогоните автотесты и изучите deprecated-сообщения в логах.
- 05
Обновите CMS, фреймворк и плагины. Убедитесь, что используемые версии совместимы с новым PHP, и заменяйте заброшенные расширения.
- 06
Переключите продакшн и наблюдайте. Сделайте полный бэкап, переключите версию в часы минимальной нагрузки и следите за логами ошибок, откликом сайта и разделами безопасности в Яндекс Вебмастере и Google Search Console.
Перед переключением версии стоит заранее продумать откат. Хорошая практика — держать на сервере две версии PHP одновременно (например, 8.1 и 8.3) и переключать их на уровне пула php-fpm или домена. Тогда в случае проблем вы вернётесь на прежнюю конфигурацию за минуты.
Для крупных проектов разумно перейти поэтапно: сначала вынести на новую версию админку и второстепенные разделы, затем основной трафик. Так вы поймаете несовместимости на небольшой доле пользователей.
Типичные ошибки при работе с PHP 8.1
Как делают неправильно
- Не обновляют патч-релизы, потому что «сайт и так работает»
- Оставляют на проде phpinfo() и включённый display_errors
- Запускают PHP-CGI на Windows с настройками по умолчанию
- Откладывают миграцию до момента полного EOL
Как делать правильно
- 01
Подписаться на рассылку о релизах PHP и ставить патчи по графику
- 02
Отключить вывод ошибок на проде, писать их в лог, скрыть expose_php
- 03
Перейти на PHP-FPM и актуальный веб-сервер, закрыть лишние порты
- 04
Запланировать миграцию на 8.3/8.4 заранее и вести её итеративно
Базовое укрепление конфигурации
Даже пока вы готовитесь к миграции, можно снизить риски настройками. В php.ini отключите display_errors, выставьте expose_php в Off, ограничьте open_basedir для каждого сайта и уберите из disable_functions-списка только те функции, которые действительно нужны приложению (exec, system, passthru и подобные обычно остаются закрытыми).
На уровне сервера используйте отдельных пользователей для каждого сайта, минимальные права на каталоги, запрет исполнения PHP в папках загрузок и актуальные TLS-настройки. Дополнительно поможет WAF или правила фильтрации на веб-сервере, но это страховка, а не замена обновлений.
Что даёт переход с PHP 8.1 на актуальную версию
- 01
Регулярные патчи безопасности без риска остаться с открытой дырой
- 02
Прирост производительности и более экономное использование памяти
- 03
Совместимость с новыми версиями фреймворков, CMS и библиотек
- 04
Современные возможности языка: типизация, readonly-классы, улучшенные атрибуты
- 05
Спокойствие при аудитах, требованиях заказчиков и проверках платёжных систем
Итоги: что делать с PHP 8.1 прямо сейчас
- 01
Проверьте версию PHP и убедитесь, что установлен свежий патч 8.1.x
- 02
Запустите composer audit и обновите уязвимые зависимости
- 03
Отключите вывод ошибок, закройте лишние функции и ограничьте права
- 04
Подготовьте тестовую копию на PHP 8.3 или 8.4 и спланируйте переход
- 05
Следите за уведомлениями о безопасности в Яндекс Вебмастере и Google Search Console
Уязвимости в PHP находят постоянно, и это нормальная часть жизни любой технологии. Опасно не их наличие, а отсутствие процесса обновления. Выстроите регулярные проверки, закрепите ответственного и планируйте миграцию заранее, а не после инцидента. Если нужна помощь, специалисты проведут аудит и подготовят безопасный переход без простоя сайта.
Часто задаваемые вопросы
Сама ветка 8.1 не «дырявая», но в ранних патч-релизах были критичные уязвимости, например CVE-2024-4577 (исправлена в 8.1.29). Кроме того, ветка выходит из поддержки, и новые проблемы перестанут закрываться.
Активная поддержка 8.1 закончилась в ноябре 2023 года. По графику на php.net исправления безопасности выпускаются до конца 2025 года. Актуальные даты лучше сверять на официальном сайте проекта.
Выполните в консоли php -v или посмотрите версию в панели хостинга. Помните, что у php-cli и php-fpm могут быть разные версии, а дистрибутивы Linux часто переносят патчи в «старые» номера.
Оптимально на PHP 8.3 или 8.4: они проще в миграции, чем кажется, и дольше будут получать патчи. Перед переключением прогоните тесты и проверьте совместимость CMS, плагинов и библиотек.
Технически да, но каждая новая найденная уязвимость останется открытой. Для интернет-магазинов, сервисов с персональными данными и платёжными формами это неприемлемый риск.
Проверьте, насколько безопасен ваш сайт на PHP 8.1
Проведём аудит версии PHP, зависимостей и конфигурации сервера и составим план безопасного обновления
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
Более 100 проверенных проектов на PHP
