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

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

Отдельной «дыры» в PHP 8.4 нет, но CVE в ветке исправляют патч-релизами. Как проверить версию, обновиться до свежей 8.4.x и снизить риски.

Уязвимости PHP 8.4: реальная картина без паники

Единой критической уязвимости «PHP 8.4» не существует: в ветке, как и в любой другой, время от времени находят отдельные CVE, и их закрывают патч-релизами 8.4.x. Защита сводится к трём действиям: держать последнюю 8.4.x, укрепить конфигурацию и следить за зависимостями.

Опасна не сама версия 8.4, а версия, которую давно не обновляли.

Запрос «уязвимость PHP 8.4» обычно появляется после тревожной новости, письма от хостинга или сообщения сканера безопасности. Разберём, откуда берутся такие уязвимости, как проверить свой сервер и что сделать в первую очередь. Статья пригодится владельцам сайтов на WordPress, 1С-Битрикс, Laravel и Symfony, а также администраторам и разработчикам.

Что на самом деле значит «уязвимость PHP 8.4»

PHP 8.4 вышел 21 ноября 2024 года и принёс заметные новшества: хуки свойств (property hooks), асимметричную видимость свойств, новый DOM-API с разбором HTML5 и ряд устареваний. Любой крупный релиз добавляет много нового кода, а новый код неизбежно содержит ошибки. Их находят исследователи, команда PHP и участники программ вознаграждения за найденные баги.

Каждой найденной проблеме присваивают идентификатор CVE, и она исправляется в очередном патч-релизе 8.4.x. Поэтому формулировка «в PHP 8.4 есть уязвимость» без номера CVE и номера патч-релиза мало что говорит. Нужно знать, какая именно версия уязвима и в каком релизе проблему закрыли.

Стоит помнить и о другом. Иногда громкие уязвимости относятся к другим веткам. Например, известная проблема CVE-2024-4577 в PHP-CGI на Windows затрагивала ветки 8.1–8.3, но не 8.4. Тем не менее в заголовках её нередко связывали с «новыми версиями PHP». Всегда сверяйтесь с первоисточником.

ключевые даты ветки php 8.4
01
21.11.2024
выход PHP 8.4

Первый стабильный релиз ветки с property hooks и новым DOM-API.

02
31.12.2026
конец активной поддержки

До этой даты выходят исправления ошибок и безопасности.

03
31.12.2028
конец поддержки безопасности

После этой даты ветка перестаёт получать даже критические патчи.

даты приведены по официальному графику php.net, сверяйтесь с актуальной страницей поддерживаемых версий

Какие проблемы находили в ветке 8.4

Уязвимости в ранних релизах 8.4.x в основном относились к нескольким классам.

Обработка HTTP-потоков. В релизе 8.4.5 (март 2025 года) исправили группу ошибок в обёртке HTTP: некорректный разбор свёрнутых заголовков (CVE-2025-1217), заголовки без двоеточия (CVE-2025-1734), слишком длинные учётные данные и адреса перенаправлений (CVE-2025-1736 и CVE-2025-1861), неверный заголовок Content-Type при перенаправлении (CVE-2025-1219). Все они связаны с тем, как PHP обрабатывает ответы внешних серверов. Это важно, если ваш код ходит на сторонние адреса через file_get_contents или потоки.

Ошибки работы с памятью. Типичные для языка на C проблемы вроде use-after-free и переполнений в расширениях. Они исправляются патчами, а эксплуатация обычно требует определённых условий.

Новый функционал. Свежие компоненты, такие как новый DOM-API, проходят «обкатку» в первых патч-релизах, и именно там чаще всего находят ошибки.

Номера CVE и состав исправлений в каждом релизе всегда проверяйте в официальном списке изменений (changelog) на php.net и в базах NVD и БДУ ФСТЭК: список пополняется, а эта статья фиксирует лишь типичные примеры.

Почему важна именно последняя патч-версия

Исправления безопасности в PHP выходят в составе регулярных патч-релизов 8.4.x. Они не ломают совместимость: смена 8.4.3 на 8.4.х с более высоким номером обычно проходит без правок кода. Поэтому оставаться на «первой версии, которую поставил хостинг» нет никакого смысла.

У этого правила есть нюанс для тех, кто работает на Linux-серверах. Debian, Ubuntu, Astra Linux, ALT и другие дистрибутивы часто переносят исправления в свои пакеты, не меняя номер версии (так называемый backport). Сканер безопасности может ругаться на «старую» версию, хотя патч уже установлен. И наоборот, при установке из сторонних репозиториев вы получаете оригинальную версию с php.net. Смотрите changelog пакета, а не только вывод php -v.

На виртуальном хостинге с панелью ISPmanager, Plesk или Hestia версию PHP обычно переключают в настройках сайта. Если нужной патч-версии нет в списке, напишите в поддержку хостинга.

Ветка PHPАктивная поддержка доИсправления безопасности доЧто делать
8.1завершена (ноябрь 2023)завершены (31.12.2025)срочно мигрировать
8.2завершена (31.12.2024)31.12.2026планировать переход на 8.3 или 8.4
8.331.12.202531.12.2027работать, готовить переход
8.431.12.202631.12.2028рекомендуемая ветка для новых проектов

Что это значит для вашего проекта

Если ваш сайт работает на PHP 8.0 и старше, вы остаётесь без исправлений безопасности: любые найденные уязвимости там уже не закрывают. Для 8.1 срок поддержки безопасности вышел 31 декабря 2025 года, для 8.2 истекает в конце 2026 года. Вопрос в том, когда вы будете переезжать, и лучше это сделать по плану, а не в аварийном режиме после взлома.

Для новых проектов 8.4 даёт самый длинный срок поддержки: исправления безопасности до конца 2028 года. Но переходить нужно осознанно: проверить совместимость плагинов, тем и библиотек, особенно в CMS вроде WordPress и 1С-Битрикс, где часть расширений может отставать от свежих версий PHP.

Как безопасно обновить PHP до последней 8.4.x

  1. 01

    Узнайте текущую версию: команда php -v в консоли, phpinfo() в закрытой от посторонних странице или раздел настроек PHP в панели хостинга. Отдельно проверьте версию для веб-сервера (php-fpm) и для консольных скриптов: они могут различаться.

  2. 02

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

  3. 03

    Сверьте свою версию с последним релизом на php.net и прочитайте список изменений: нужно понять, какие CVE закрыты в новых версиях.

  4. 04

    Обновите PHP на тестовой копии сайта. В Docker это новая версия образа php:8.4-fpm, на сервере — обновление пакета или переключение версии в панели.

  5. 05

    Запустите тесты и пройдите ключевые сценарии вручную: оформление заказа, авторизацию, формы, выгрузки, cron-задачи. Просмотрите лог ошибок на предмет предупреждений об устаревших конструкциях (deprecated).

  6. 06

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

  7. 07

    Выкатите обновление на боевой сервер в период минимальной нагрузки, затем 1–2 дня следите за логами, ошибками 5xx и отчётами Яндекс Метрики или Google Analytics: резкий рост ошибок или падение конверсии выдаст проблему.

Обновление версии — это только половина защиты

Даже последняя 8.4.x не спасёт, если конфигурация сервера «по умолчанию», а код сайта строит запросы без проверки данных. Большинство реальных взломов происходит не из-за экзотических уязвимостей интерпретатора, а из-за устаревших плагинов, слабых паролей, открытых служебных файлов и ошибок в самом коде приложения.

Поэтому обновление PHP нужно сочетать с базовым укреплением (hardening). Начать можно с нескольких настроек php.ini: они занимают минут десять, но заметно сокращают поверхность атаки. Особенно полезно отключить allow_url_fopen там, где сайт не обращается к внешним адресам через файловые функции: это сужает круг сценариев, в которых могут сработать проблемы HTTP-обёртки.

php.ini: было → стало
было
  • expose_php = Onверсия PHP видна в заголовках ответа
  • display_errors = Onпути и ошибки видны посетителям
  • allow_url_fopen = Onфайловые функции открывают внешние адреса
  • session.cookie_httponly = 0cookie доступна из JavaScript
стало
  • expose_php = Offверсия скрыта от посторонних
  • display_errors = Offошибки пишутся только в лог (log_errors = On)
  • allow_url_fopen = Offесли сайту не нужны внешние запросы такого типа
  • session.cookie_httponly = 1плюс session.use_strict_mode = 1
скрытие версии не заменяет обновление, это лишь дополнительный слой защиты

Типичная ошибка: «скрыл версию PHP — значит, я защищён»

Многие администраторы отключают expose_php, видят «чистый» заголовок ответа и считают задачу выполненной. На самом деле злоумышленнику не нужно знать вашу версию: автоматические сканеры проверяют уязвимости напрямую, а не только по заголовкам.

Как делать не стоит

  • Скрыть версию в заголовках и не обновлять PHP годами.
  • Оставить display_errors включённым на боевом сайте и показывать посетителям пути к файлам.
  • Ставить обновление сразу на боевой сервер без резервной копии и проверки на тестовой копии.
  • Игнорировать устаревшие плагины и библиотеки, потому что «сам PHP же свежий».

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

  1. 01

    Регулярно ставить последние патч-релизы 8.4.x и сверять changelog с известными CVE.

  2. 02

    Сочетать обновления с настройкой php.ini, правами на файлы и ограничением опасных функций (disable_functions) и каталогов (open_basedir).

  3. 03

    Проверять зависимости командой composer audit и обновлять плагины CMS.

  4. 04

    Настроить мониторинг: журналы ошибок, отчёты безопасности в Яндекс Вебмастере и Google Search Console.

Как уязвимости PHP отражаются на SEO

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

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

чек-лист: проверка php-сайта за 15 минут
01
Версия PHP

php -v и сравнение с последним релизом 8.4.x на php.net.

02
Срок поддержки

Ваша ветка ещё получает исправления безопасности?

03
Зависимости

composer audit, обновление плагинов и тем CMS.

04
Конфигурация

expose_php, display_errors, allow_url_fopen, параметры сессий.

05
Резервные копии

Свежая копия файлов и базы и проверка восстановления.

06
Отчёты поисковиков

Разделы безопасности в Яндекс Вебмастере и Google Search Console.

Следите за официальными источниками: страницей выпусков и списком изменений на php.net, базами NVD и MITRE, а также БДУ ФСТЭК России. Именно там выходит первичная информация о CVE, а не в пересказах и заголовках новостей.

Итоги: как относиться к уязвимостям PHP 8.4

PHP 8.4 — рабочая ветка с поддержкой безопасности до конца 2028 года, но только если вы регулярно ставите патч-релизы.
  1. 01

    Отдельной «уязвимости PHP 8.4» нет: CVE находят в разных релизах и закрывают в патчах 8.4.x.

  2. 02

    Держите на сервере последнюю 8.4.x и проверяйте changelog, особенно если используете пакеты дистрибутива с backport.

  3. 03

    Ветки 8.1 и старше уже не получают исправлений безопасности, а 8.2 перейдёт в этот статус в конце 2026 года: планируйте миграцию заранее.

  4. 04

    Сочетайте обновление с настройкой php.ini, проверкой зависимостями через composer audit и резервными копиями.

  5. 05

    Подключите Яндекс Вебмастер и Google Search Console: они помогут заметить проблемы безопасности до того, как пострадают позиции.

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

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

Проверим ваш сайт на уязвимости PHP и безопасно обновим версию

Определим версию PHP, найдём устаревшие зависимости и подготовим план перехода на актуальную 8.4.x

Бесплатная первичная оценкаОбновление без простояОтчёт с приоритетами

Проверяем версии, конфиги и зависимости

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

Две одинаковые трубы разного размера: из отверстия большой падают шарики, в малой стоит зелёная заглушка
Уязвимости PHP: виды, примеры и защита сайтаУязвимости PHP возникают из-за ошибок в коде и настройках: SQL-инъекции, XSS, include, загрузка файлов. Разбираем виды и как защитить сайт.
Прозрачная ёмкость с перегородкой: слева жидкость почти до края, справа вдвое ниже, на ней лежит зелёный шарик
php -v: как узнать версию PHP в консоли и на сайтеЧтобы узнать версию PHP, выполните в терминале команду php -v. Разбираем вывод, альтернативы, работу на Windows, Linux и macOS и типичные ошибки.
Белая труба с закрытым заглушкой концом, перед которой остановился маленький зелёный шарик
Уязвимости PHP 8.3: что известно и как защитить сайтОтдельной «уязвимости PHP 8.3» нет — есть серия CVE. Самая опасная, CVE-2024-4577 (CVSS 9.8), исправлена в 8.3.8. Обновите PHP до актуальной 8.3.x.

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

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

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

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

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

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

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

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

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

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

Контакты

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