Уязвимости PHP 7.4: чем опасна версия и что делать
PHP 7.4 не получает патчей безопасности с 28 ноября 2022 года. Разбираем риски, известные CVE и безопасный переход на поддерживаемую версию PHP.
Уязвимость PHP 7.4: почему эта версия опасна
Да, PHP 7.4 уязвим: ветка снята с поддержки 28 ноября 2022 года, и новые уязвимости в ней больше не закрываются официально. Надёжное решение — перейти на поддерживаемую версию PHP 8.x.
PHP 7.4 до сих пор стоит на тысячах сайтов: на старых CMS, самописных проектах и недорогих хостингах. Пока всё работает, обновление откладывают. Но с точки зрения информационной безопасности такая версия — открытая дверь. В статье разберём, какие уязвимости известны, чем рискует бизнес и как перейти на актуальную версию без простоя.
Что значит «PHP 7.4 снят с поддержки»
У каждой ветки PHP есть жизненный цикл. Сначала два года идёт активная поддержка: исправляются баги и уязвимости. Потом ещё год действует только поддержка безопасности. После этого ветка получает статус EOL (end of life), то есть «конец жизни»: разработчики языка не выпускают для неё никаких обновлений.
Для PHP 7.4 релиз состоялся 28 ноября 2019 года, активная поддержка закончилась 28 ноября 2021 года, а поддержка безопасности — 28 ноября 2022 года. Это не значит, что сайт перестанет работать. Он продолжит открываться, но при этом любая новая брешь в интерпретаторе, расширениях или стандартной библиотеке будет закрываться только в актуальных ветках.
Особенно неприятно то, что исследователи и злоумышленники анализируют исправления для новых версий. По патчу для PHP 8.x несложно понять, где ошибка, и проверить, затрагивает ли она старую ветку. Для 7.4 готового исправления уже нет.
Какие уязвимости известны в PHP 7.4
Единого «убийственного бага» у PHP 7.4 нет. Проблема в том, что список проблем со временем только растёт, а закрывать его некому. Часть известных уязвимостей была исправлена до окончания поддержки (последний патч — 7.4.33), но если на сервере стоит более ранняя сборка вроде 7.4.3 или 7.4.16, эти дыры остаются открытыми.
Отдельная категория — уязвимости, обнаруженные уже после EOL. Яркий пример — CVE-2024-4577: инъекция аргументов в PHP-CGI на Windows, приводящая к удалённому выполнению кода. Разработчики PHP прямо заявили, что ветки 8.0 и старше, включая 7.4, не поддерживаются, поэтому для них исправлений нет. Остаётся только менять конфигурацию (отказаться от CGI) или обновляться.
| Уязвимость | Суть проблемы | Статус для PHP 7.4 |
|---|---|---|
| CVE-2022-31625 | Use-after-free при работе с PostgreSQL в функции pg_query_params() | Исправлено в 7.4.30, актуально для более ранних сборок |
| CVE-2022-31626 | Переполнение буфера в mysqlnd и pdo_mysql при подключении к вредоносному серверу MySQL | Исправлено в 7.4.30, актуально для более ранних сборок |
| CVE-2024-4577 | Инъекция аргументов в PHP-CGI на Windows и удалённое выполнение кода | Официального патча нет, нужно отключать CGI или переходить на новую ветку |
| Новые CVE после 2022 года | Бреши в ядре, расширениях и сторонних библиотеках, поставляемых с PHP | Официальных исправлений не будет |
Чем это грозит сайту и бизнесу
Для владельца сайта уязвимость интерпретатора — это не абстрактный «технический долг». Через неё злоумышленник может выполнить произвольный код на сервере, получить доступ к базе данных с заказами и персональными данными, встроить в страницы скрытые ссылки и редиректы либо превратить сервер в часть ботнета.
Последствия видны и в поиске. Яндекс Вебмастер и Google Search Console сообщают о заражении и выдают предупреждения, а Яндекс Браузер и Chrome показывают пользователям красный экран при попытке открыть сайт. Трафик падает за дни, а на восстановление репутации уходят недели. Добавьте штрафы за утечку персональных данных (152-ФЗ) и потерянные заказы.
Типичные ошибки владельцев сайтов на PHP 7.4
Как рассуждают и поступают
- «Сайт работает стабильно, значит, всё в порядке»
- «Нас никто не взломает, мы небольшой проект»
- Обновляют только плагины и CMS, а версию PHP не трогают
- Оставляют на сервере файл с phpinfo() и открытую админку
- Откладывают миграцию, пока не появится «свободный бюджет»
Как правильно
- 01
Считать устаревшую версию PHP отдельным риском и вносить в план работ
- 02
Помнить, что атаки автоматизированы: боты сканируют сайты по версиям ПО, а не по размеру бизнеса
- 03
Обновлять стек целиком: PHP, CMS, плагины, расширения и Composer-зависимости
- 04
Удалять отладочные файлы и закрывать доступ к служебным разделам по IP
- 05
Заложить миграцию в ближайший спринт: чем дольше откладываете, тем она дороже
- Патчей безопасности нет с ноября 2022
- Новые библиотеки и CMS требуют 8.0+
- Слабая типизация, больше скрытых ошибок
- Медленнее на типичных нагрузках
- Хостеры постепенно убирают версию из панели
- Регулярные обновления безопасности
- Совместимость с актуальными фреймворками
- Union types, enum, readonly-свойства, match
- JIT-компиляция и общий прирост скорости
- Строгие проверки, ошибки видны раньше
Можно ли остаться на PHP 7.4 временно
Иногда мгновенный переход невозможен: проект завязан на старую CMS, а плагин без поддержки не работает на PHP 8. В таком случае нужны компенсирующие меры, но это временное решение, а не стратегия.
Первый вариант — серверы с backport-патчами. Дистрибутивы вроде Debian (в рамках LTS) и Ubuntu (по подписке Ubuntu Pro) продолжают переносить исправления безопасности в свои пакеты PHP 7.4. Второй вариант — коммерческая расширенная поддержка от компаний, которые поддерживают устаревшие ветки PHP за плату. Третий — защитные слои вокруг приложения: WAF, запрет CGI, отключение опасных функций через disable_functions, ограничение open_basedir, изоляция сайта в контейнере и ежедневные резервные копии вне сервера.
Учтите: такие меры снижают риск, но не устраняют его. Кроме того, сроки поддержки дистрибутивов тоже ограничены, поэтому запланируйте миграцию заранее.
Что даёт переход с PHP 7.4 на актуальную версию
- 01
Закрытые уязвимости и регулярные патчи безопасности от разработчиков языка
- 02
Прирост производительности: страницы отдаются быстрее, а это плюс для Core Web Vitals и поведенческих факторов в Яндексе и Google
- 03
Совместимость с актуальными версиями WordPress, 1С-Битрикс, Laravel, Symfony и других фреймворков
- 04
Более строгая типизация и современный синтаксис, которые упрощают поддержку кода
- 05
Меньше расходов на «костыли» и аварийные доработки в будущем
Как безопасно мигрировать с PHP 7.4 на PHP 8.x
- 01
Проведите инвентаризацию: выясните точную версию PHP (php -v), список расширений, используемую CMS, плагины и Composer-зависимости.
- 02
Сделайте полную резервную копию файлов и базы данных и проверьте, что её можно восстановить.
- 03
Разверните копию сайта на тестовом окружении с целевой версией PHP. Не проверяйте обновление на боевом сервере.
- 04
Прогоните код через анализаторы: PHP_CodeSniffer с набором PHPCompatibility, PHPStan или Psalm, а при необходимости используйте Rector для автоматического рефакторинга.
- 05
Обновите CMS, плагины, темы и библиотеки до версий, которые заявляют поддержку PHP 8. Замените заброшенные модули.
- 06
Исправьте типичные проблемы: удалённые функции, строгие сравнения, передачу null в параметры встроенных функций, фигурные скобки для смещения строк.
- 07
Протестируйте ключевые сценарии: оформление заказа, формы, личный кабинет, интеграции с платёжными системами и CRM. Проверьте журнал ошибок.
- 08
Переключите версию в панели хостинга или на сервере в период минимальной нагрузки, оставив возможность быстрого отката.
- 09
После запуска неделю следите за логами, ошибками 5xx, скоростью ответа, а также отчётами Яндекс Вебмастера и Google Search Console.
На что обратить внимание при переходе
Самые частые сложности возникают не в вашем коде, а в сторонних модулях. Старые плагины, неподдерживаемые темы оформления и самописные расширения, написанные «под 7.4», могут выдавать предупреждения или падать с фатальными ошибками. Поэтому начинайте с аудита зависимостей, а не с переключения версии.
Выбирайте не самую свежую версию PHP, а ту, которая уже поддерживается вашей CMS и получает патчи ещё не меньше года-двух. Если проект большой, переходите поэтапно: сначала на 8.0 или 8.1, устранив предупреждения о deprecated, затем на более новую ветку. Так вы разделите риски и проще найдёте источник проблем.
Итоги: что делать с PHP 7.4 уже сейчас
- 01
Проверьте версию PHP на всех сайтах и серверах
- 02
Составьте список CMS, плагинов и библиотек, которые мешают обновлению
- 03
Протестируйте переход на PHP 8.x на копии сайта
- 04
Если мигрировать пока нельзя, используйте backport-патчи, WAF, запрет CGI и резервные копии
- 05
После обновления следите за логами и отчётами Яндекс Вебмастера и Google Search Console
Миграция с PHP 7.4 — не прихоть разработчиков, а базовая гигиена безопасности. Чем раньше вы её проведёте, тем меньше будут затраты и тем ниже вероятность потерять данные, трафик и репутацию. Начните с аудита: он покажет, насколько сложным будет переход именно в вашем проекте.
Часто задаваемые вопросы
Да. Ветка 7.4 снята с поддержки 28 ноября 2022 года, последний релиз — 7.4.33. Новые уязвимости, найденные позже, официально не исправляются, поэтому каждый год риск взлома растёт.
Только с оговорками. Подойдут дистрибутивы с backport-патчами (например, Debian LTS или Ubuntu Pro) либо коммерческая расширенная поддержка. Плюс нужны WAF, изоляция процессов и мониторинг. Без этого оставаться на 7.4 небезопасно.
Выполните в консоли php -v или создайте временный файл с функцией phpinfo(). Версию также показывает панель хостинга (ISPmanager, cPanel и другие). После проверки удалите файл с phpinfo().
На ту, что ещё получает обновления безопасности. Сейчас это ветки 8.2, 8.3 и 8.4. Актуальные сроки смотрите на странице Supported Versions на сайте php.net. Перед выбором проверьте совместимость CMS, плагинов и библиотек.
Прямого фактора ранжирования нет. Косвенно влияют взлом, внедрение спама, пометка сайта как опасного в Яндекс Вебмастере и Google Search Console, а также медленная работа. Всё это снижает трафик и доверие.
Проверьте безопасность своего сайта на PHP 7.4 до взлома
Проведём аудит версии PHP, плагинов и конфигурации сервера и составим безопасный план миграции на PHP 8.
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
PHP 7.4 без патчей уже более двух лет
