Уязвимости PHP 8.2: что опасно и как защитить сайт
Два одинаковых лотка с ячейками, в одном все жетоны на местах и один зелёный, в другом последний ряд пуст
Интеграции и Разработка ПО10 ноября 2026 г. 8 минут чтения 4 просмотра

Уязвимости PHP 8.2: что опасно и как защитить сайт

PHP 8.2 уязвим, если не обновлён до последней минорной версии: критичные CVE закрыты в 8.2.x. Разбираем риски, сроки поддержки и порядок защиты.

Уязвимости PHP 8.2: что известно и что делать

PHP 8.2 нельзя считать небезопасным «по умолчанию», но ранние сборки ветки содержат известные критичные уязвимости. Защищает только актуальная минорная версия 8.2.x с установленными патчами.

Критичная CVE-2024-4577 (оценка CVSS 9.8) закрыта в PHP 8.2.20. Если у вас версия ниже, а PHP работает в режиме CGI на Windows, сервер под угрозой.

Запрос «уязвимость PHP 8.2» обычно появляется в двух случаях. Либо сканер безопасности или хостинг прислал тревожное уведомление, либо в новостях мелькнула очередная CVE. В обоих случаях нужен спокойный порядок действий: понять, затронуты ли вы, закрыть дыру и не допустить повторения. Ниже разобраны реальные уязвимости, сроки поддержки ветки и практический план защиты.

Почему в PHP 8.2 вообще находят уязвимости

PHP 8.2 вышел 8 декабря 2022 года. Это зрелая ветка, поэтому за её время исследователи и разработчики нашли и исправили заметное число проблем. Это нормальный процесс жизни любого крупного языка: новые CVE появляются, потому что код постоянно проверяют, а не потому, что ветка «плохая».

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

Поэтому вопрос звучит не «безопасен ли PHP 8.2 вообще», а «какая именно у меня сборка и какие патчи на ней стоят». Одна и та же ветка 8.2 с версией 8.2.3 и с версией 8.2.28 отличается по защищённости радикально.

жизненный цикл php 8.2
01
8 декабря 2022
Релиз ветки 8.2. Начинается активная поддержка: исправляются и баги, и уязвимости.
02
31 декабря 2024
Конец активной поддержки. Обычные баги больше не чинят, выходят только патчи безопасности.
03
31 декабря 2026
Конец поддержки безопасности. Дальше ветка остаётся без исправлений вообще.

Самые заметные уязвимости PHP 8.2

Ниже перечислены реальные CVE, которые затрагивали ветку 8.2 и уже исправлены в указанных релизах. Список не исчерпывающий: полный перечень всегда смотрите в официальном журнале изменений PHP.

Главное правило: если версия вашего PHP ниже указанной в таблице, обновление нужно ставить сразу, не дожидаясь планового окна.

ИдентификаторСуть проблемыИсправлено в версии
CVE-2024-4577Инъекция аргументов в PHP-CGI на Windows, возможно удалённое выполнение кода8.2.20
CVE-2024-2756Обход защиты cookie с префиксами __Host- и __Secure-8.2.18
CVE-2024-3096Функция password_verify может вернуть true для хеша, начинающегося с нулевого байта8.2.18
CVE-2023-3824Переполнение буфера при чтении каталога в расширении phar8.2.8

Что опаснее всего: разбор CVE-2024-4577

Эта уязвимость получила максимальное внимание, потому что её оценка по шкале CVSS составляет 9.8 из 10. Проблема связана с тем, как PHP в режиме CGI на Windows обрабатывает определённые символы в запросе. Из-за особенностей преобразования кодировок злоумышленник может передать скрипту лишние аргументы и добиться выполнения произвольного кода.

Затронуты версии 8.1 до 8.1.29, 8.2 до 8.2.20 и 8.3 до 8.3.8. При этом риск прежде всего у тех, кто запускает PHP на Windows через CGI, например в связке с локальными пакетами вроде XAMPP. Типичная связка Linux с PHP-FPM под эту конкретную атаку не попадает, но обновляться всё равно нужно: остальные CVE никто не отменял.

После публикации информации о дыре начались массовые автоматические сканирования. Именно поэтому откладывать патч нельзя: на уязвимые серверы боты приходят в течение считанных дней.

cve-2024-4577 в цифрах
9.8
оценка CVSS из 10: критический уровень
8.2.20
первая версия ветки 8.2 с исправлением
Windows + CGI
конфигурация, в которой атака возможна

Типичные ошибки при работе с уязвимостями PHP

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

Как делают неправильно

  • Считают, что «восьмёрка — это новая версия, значит, дыр нет» и не смотрят на номер минорного релиза
  • Ставят обновление сразу на боевой сервер без проверки на тестовом окружении
  • Оценивают риск только по строке версии, не учитывая, что дистрибутив мог перенести патч в пакет без смены номера

Как правильно

  1. 01

    Фиксировать точную версию (например, 8.2.28) и сравнивать её со списком исправленных CVE

  2. 02

    Сначала обновлять стенд, прогонять тесты и только затем выкатывать на прод

  3. 03

    Проверять статус CVE в трекере безопасности вашего дистрибутива (Debian, Ubuntu, AlmaLinux и других)

Как узнать, что у вас под угрозой

Начните с самого простого: выясните точную версию PHP на сервере. В консоли это команда php -v, а для веб-окружения нужно смотреть версию именно того PHP, который обслуживает сайт, поскольку в системе их может стоять несколько. На виртуальном хостинге версия указана в панели управления.

Дальше сопоставьте номер с таблицей исправлений. Если вы на Linux-дистрибутиве с долгой поддержкой, учтите бэкпорты: разработчики пакетов часто вносят исправление в старую версию, не меняя её номер. Строка 8.2.7 в таком случае может оказаться уже пропатченной. Точный ответ даёт официальный трекер безопасности вашего дистрибутива.

Не забудьте про зависимости. Уязвимости бывают не только в самом PHP, но и в библиотеках, которые подтягивает Composer. Команда composer audit показывает известные проблемы в установленных пакетах.

План защиты сервера на PHP 8.2

  1. 01

    Определите точную версию PHP, которая обслуживает сайт, и режим запуска (PHP-FPM, Apache-модуль, CGI).

  2. 02

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

  3. 03

    Обновите стенд до последней доступной версии 8.2.x, прогоните автотесты и проверьте ключевые сценарии сайта.

  4. 04

    Выкатите обновление на боевой сервер в период минимальной нагрузки и держите под рукой план отката.

  5. 05

    Запустите composer audit и обновите библиотеки, в которых найдены известные уязвимости.

  6. 06

    Ужесточите настройки: expose_php=Off, display_errors=Off, ограничьте опасные функции через disable_functions и по возможности откажитесь от PHP-CGI в пользу PHP-FPM.

  7. 07

    Подключите WAF и мониторинг логов, а в Яндекс Вебмастере и Google Search Console включите уведомления о проблемах безопасности.

  8. 08

    Запланируйте миграцию на PHP 8.3 или 8.4 заранее, до окончания поддержки ветки 8.2.

Почему после обновления нельзя расслабляться

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

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

Взлом сайта быстро отражается на видимости. Яндекс и Google помечают заражённые ресурсы предупреждениями и снижают их в результатах поиска. Сообщения об этом приходят в Яндекс Вебмастер и Google Search Console, поэтому оба сервиса стоит подключить заранее, а не после инцидента.

чек-лист: быстрая проверка за 10 минут
  • 01Версия PHP не ниже последней доступной 8.2.x
  • 02Режим запуска: PHP-FPM, а не PHP-CGI на Windows
  • 03composer audit не показывает известных уязвимостей
  • 04display_errors выключен, expose_php выключен
  • 05Подключены Яндекс Вебмастер и Google Search Console
  • 06Есть свежая резервная копия и проверенный план отката

Что даёт своевременное обновление PHP

  1. 01

    Закрытие известных критичных уязвимостей, которые активно ищут автоматические сканеры

  2. 02

    Защита пользовательских данных, паролей и сессий от кражи

  3. 03

    Стабильная позиция сайта в Яндексе и Google без санкций за заражение

  4. 04

    Меньше аварийных работ: плановое обновление дешевле ликвидации последствий взлома

  5. 05

    Совместимость с современными библиотеками и фреймворками

Важно: PHP 8.2 получает только исправления безопасности. Обычные баги в этой ветке уже не чинят, а с 1 января 2027 года не будет и патчей безопасности. Миграцию на актуальную ветку лучше начинать заранее.

Итоги: как жить с PHP 8.2 безопасно

Ветка 8.2 остаётся рабочей до конца 2026 года, но защищает только свежая минорная версия с установленными патчами.
  1. 01

    Узнайте точную версию PHP и сравните её с известными CVE

  2. 02

    Обновитесь до последней 8.2.x, предварительно проверив всё на стенде

  3. 03

    Отключите PHP-CGI, где он не нужен, и закройте лишние функции

  4. 04

    Проверяйте зависимости командой composer audit

  5. 05

    Запланируйте переход на PHP 8.3 или 8.4 до конца 2026 года

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

Часто задаваемые вопросы

Проверим ваш сервер на уязвимости PHP до того, как это сделают другие

Оценим версию PHP, конфигурацию и зависимости, а затем составим план обновления по приоритетам.

Бесплатный экспресс-аудитОтчёт за 24 часаБез простоя сайта

Более 300 проверенных PHP-проектов

Читайте также

Белая труба с закрытым заглушкой концом, перед которой остановился маленький зелёный шарик
Уязвимости PHP 8.3: что известно и как защитить сайтОтдельной «уязвимости PHP 8.3» нет — есть серия CVE. Самая опасная, CVE-2024-4577 (CVSS 9.8), исправлена в 8.3.8. Обновите PHP до актуальной 8.3.x.
Две одинаковые белые воронки с заглушками в носиках, в левой над заглушкой лежит зелёный шарик
RCE в PHP: как работает уязвимость и как защитить сайтRCE в PHP — уязвимость, позволяющая выполнить произвольный код на сервере. Разбираем причины, примеры и меры защиты сайта.
Три белые коробки в ряд, в крышку средней проходит зелёный шарик, крышки боковых закрыты наглухо
Безопасная настройка Nginx и PHP-FPM: чек-лист для сервераБезопасная связка Nginx и PHP-FPM: скрыть версии, закрыть выполнение PHP в лишних каталогах, изолировать пулы, включить TLS и лимиты.

Политика конфиденциальности

При оставлении заявки на ресурсе «https://gurucontext.ru» пользователи предоставляют следующие сведения:

  • Имя
  • Контактный телефон или Telegram
  • Адрес сайта пользователя (не обязательно)

Также администрация сайта получает данные об IP-адресе посетителей, типе браузера, времени нахождения на сайте и прочие подобные сведения через сервисы статистики.

Использование информации

Вся полученная информация используется администрацией «https://gurucontext.ru» исключительно в целях связи с клиентом.

Защита персональных данных

Компания «https://gurucontext.ru» обязуется не разглашать сведения, полученные от пользователей, и хранит их в защищённом виде.

Предоставление данных третьим лицам

Полученные сведения не передаются третьим лицам, за исключением случаев исполнения обязательств перед клиентом (с его разрешения) и обоснованных требований закона.

Контакты

Телефон: +7 (499) 955-47-00.
E-mail: info@gurucontext.ru.