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

Что случилось 21 октября 2026 года

Разработчики PHP выпустили два внеплановых security-релиза. Уязвимости получили идентификаторы CVE-2026-109618 и CVE-2026-109619. Обе связаны с удалённым выполнением кода и не требуют авторизации на сайте. Оценка опасности — 9.2 по CVSS 4.0.

Исправления вышли для четырёх поддерживаемых веток:

Кроме готовых security-релизов, команда безопасности PHP подготовила минимальные source-backport для PHP 7.4, PHP 8.0 и PHP 8.1. Это патчи для сборки из исходников, а не готовые пакеты для панели хостинга. Их наличие и способ установки зависят от поставщика. Нельзя считать, что backport уже применён к вашей сборке, пока это не подтверждено.

Официальные advisory опубликованы в репозитории PHP: CVE-2026-109618 и CVE-2026-109619. Механику эксплуатации здесь не разбираю: для владельца сайта важнее проверить версию и получить исправление, а не повторять сценарии атаки.

Официальное объявление PHP: security advisory от 21 октября 2026 года. Сроки поддержки веток смотрите на php.net/supported-versions.php.

Речь идёт об уязвимостях PHP, который обслуживает веб-запросы, а не конкретного плагина или темы. Официальное объявление перечисляет несколько способов запуска, включая PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Наиболее высокий риск отмечен для mod_php: там продемонстрирована эксплуатация до выполнения кода приложения. Это не значит, что все конфигурации одинаково уязвимы или что атака гарантированно сработает на любом сервере. Но обновление одного расширения или «заплатка» в коде сайта проблему не закрывает: нужна исправленная сборка PHP, которую обслуживает домен.

Хостинг Beget в этот же день опубликовал предупреждение. Beget сообщает, что ограничивает работу механизма upload_progress, а ограничение обработки POST-запросов multipart/form-data описано как планируемая мера. Не считайте её уже включённой повсеместно, пока нет более позднего официального подтверждения. Часть ограничений уже действует на виртуальном хостинге и на выделенных серверах под управлением Beget; все они носят временный характер, могут нарушить загрузку файлов и работу форм и не гарантируют полной защиты. Краткое русскоязычное объяснение есть на Habr, но первоисточником остаются официальные advisory.

Какие версии PHP под угрозой

Готовые security-релизы вышли для 8.2–8.5. Для PHP 7.4, 8.0 и 8.1 есть source-backport, для PHP 5.6 и веток 7.0–7.3 официальных backport в объявлении нет. Что это значит для конкретной сборки — смотрите в таблице.

Если поставщик подтвердил, что исправление применено к вашей сборке PHP 8.0 или 8.1, не считайте её заведомо уязвимой. Но подтверждение не отменяет планирование перехода: обычная поддержка этих веток завершена.

Поддержка PHP 8.2 заканчивается 31 декабря 2026 года. Поэтому 8.2 — минимальный порог, а не долгосрочная цель на конец октября 2026 года. Если CMS и расширения совместимы, разумно рассматривать 8.3 или более новую поддерживаемую ветку. Не переключайте старый сайт на 8.5 вслепую: сначала проверьте совместимость CMS, плагинов и самописного кода.

Шаг 1. Как узнать версию PHP на сайте

Главный источник — панель хостинга. На Beget версия выбирается в разделе «Сайты» → «Управление сайтами» → шестерёнка у нужного домена. На Timeweb и Reg.ru настройка находится в панели управления сайтом. На VPS версия зависит от ispmanager, FASTPANEL или установленных пакетов, и менять её нужно самостоятельно.

HTTP-заголовок — только дополнительная проверка:

curl -sSI https://vash-sait.ru/ | grep -i x-powered-by

Если заголовка x-powered-by нет, это не значит, что PHP старый. Хостер или сайт может скрывать версию через expose_php = Off. Ориентироваться только на заголовок нельзя.

Второй способ — временный файл с phpinfo():

<?php phpinfo(INFO_GENERAL);

Создайте файл со случайным именем, откройте его в браузере, посмотрите «PHP Version» и «Server API», затем сразу удалите. Оставлять phpinfo() на рабочем сайте нельзя: это раскрывает настройки сервера.

Шаг 2. Как понять, что исправление уже стоит

Проверка состоит из четырёх шагов.

1. Установите версию PHP, которая обслуживает именно сайт. Не CLI, не соседний поддомен, а конкретный виртуальный хост.
2. Сравните с исправленными версиями. Для 8.2 нужна 8.2.35 или новее, для 8.3 — 8.3.36, для 8.4 — 8.4.27, для 8.5 — 8.5.12.
3. Проверьте новости и поддержку хостера. В обращении укажите CVE-2026-109618 и CVE-2026-109619 и спросите, включено ли исправление в сборку, которая обслуживает ваш сайт.
4. Получите подтверждение. Если поддержка не подтверждает патч, наличие исправления не подтверждено. Действуйте так, как будто исправления нет, и планируйте переход.

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

Официальные рекомендации для двух CVE различаются. Для CVE-2026-109618 среди мер — административное управление memory_limit, ограничение post_max_size и размера декодированного запроса на уровне фронтенда. Для CVE-2026-109619 — отключение session.upload_progress (enabled=0) с перезапуском всех соответствующих воркеров, а на PHP 8.5 ещё и fatal_error_backtraces=0. Это меры для администраторов и поставщиков, а не инструкция для владельца сайта. Не применяйте memory_limit=-1, настройки FPM или ограничения запросов вслепую: в конкретной конфигурации они могут уронить сайт или не сработать.

Запрос в поддержку лучше формулировать конкретно, иначе легко получить общий ответ «PHP обновлён». Вот шаблон:

Здравствуйте. На сайте example.ru используется PHP 8.5.
Подтвердите, пожалуйста, что сборка, которая обслуживает этот домен,
содержит исправления CVE-2026-109618 и CVE-2026-109619.
Если исправления нет — когда планируется обновление и какая версия
PHP будет установлена? Если можно, пришлите номер сборки и дату для сверки.

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

Шаг 3. Как обновить PHP без падения сайта

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

1. Сделайте бэкап файлов и базы. Не полагайтесь только на копию хостинга: перед обновлением нужна точка возврата, к которой есть быстрый доступ. Как это устроено, разобрано в статье о внешних копиях и схеме 3-2-1.
2. Разверните копию сайта. Подойдёт поддомен, тестовый домен или отдельная папка с копией базы. На копии можно ломать что угодно.
3. Проверьте требования CMS и расширений. Посмотрите официальные требования WordPress, OpenCart, Joomla или Bitrix к PHP. Старые версии CMS могут не поддерживать 8.3–8.5.
4. Обновите CMS и плагины на копии. Сначала приведите код в актуальное состояние, потом меняйте PHP. Если плагин заброшен и несовместим, ищите замену.
5. Переключите PHP на копии и протестируйте. Проверьте не только главную, но и формы, загрузку файлов, админку, cron, почту и оплату.
6. Переключите прод и оставьте путь к откату. Если появилась ошибка, сначала определите причину: несовместимый плагин, код, настройка или сама версия PHP. Полное восстановление бэкапа нужно не при каждой ошибке. Если для восстановления работоспособности приходится временно вернуть уязвимую версию PHP, считайте это краткосрочной мерой: устраните несовместимость и вернитесь на исправленное окружение.

На shared-хостинге после смены версии в панели подождите несколько минут: Beget указывает до 10 минут. Затем сбросьте кэш сайта и CMS, потому что старые скомпилированные файлы могут остаться. Если на Beget после смены PHP пропали сессии, разбор есть в статье о сессиях PHP на Beget и CloudLinux.

Перед переключением прогоните минимальный тест: главная, форма, загрузка файла, админка, cron, почта; для магазина — корзина и оплата. Подробный список проверок — ниже.

Что обычно ломается при переходе со старых версий

Чем старше сайт, тем больше сюрпризов. Вот что встречается чаще всего при переходе с PHP 5.6 или 7.x на 8.x:

• Удалённые функции и конструкции. mysql_* и ereg_* удалены ещё в PHP 7.0. each(), create_function() и обращение к символу строки через фигурные скобки ($string{0}) удалены в PHP 8.0. Код с ними не запустится.
• Dynamic properties. В PHP 8.2 создание свойств, которых нет в классе, вызывает deprecation. Это предупреждение, а не автоматическая фатальная ошибка, но код лучше поправить заранее.
• Интерполяция ${var}. Устарела и постепенно удаляется, заменяется на {$var}. Пока это deprecation, но в будущих версиях поведение может измениться.
• utf8_encode() и utf8_decode(). Помечены как устаревшие. Если сайт работает с кодировками, проверьте эти места отдельно.
• Передача null в параметры внутренних функций. Всё чаще вызывает deprecation там, где ожидается строка или число. Последствия зависят от версии PHP и конкретного кода.
• Обработка ошибок mysqli. В PHP 8.1 по умолчанию включён режим исключений. Старый код, который проверял только возвращаемое значение, может вести себя иначе.
• Старые CMS и плагины. Они могут быть несовместимы не только с PHP 8.5, но и с 8.2. Это отдельная причина сначала обновить CMS, а потом менять версию PHP.

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

Почему сайт на PHP 5.6 или 7.x нельзя оставить как есть

Старые ветки PHP больше не получают обычные исправления безопасности от основного проекта. Для PHP 7.4, 8.0 и 8.1 проект подготовил минимальные source-backport, но это не значит, что они уже собраны и установлены у вашего хостера. Для PHP 5.6 и веток 7.0–7.3 официальных source-backport в объявлении нет. Крупный провайдер или LTS-вендор может выпустить собственное исправление, но рассчитывать на это нельзя. Нужно письменное подтверждение поставщика, что конкретная сборка содержит применимое исправление.

Кроме самой PHP, есть вторая проблема: старые CMS и плагины. Даже если хостер сделает backport для PHP 7.4, устаревший движок может иметь собственные дыры, которые никто уже не закрывает. Обновление PHP не исправляет код сайта автоматически.

Дальше — последствия. Скомпрометированный сайт используют для спама, подстановки ссылок, кражи данных или атак на посетителей. Для владельца это потеря трафика, доверия и времени на восстановление. Иногда дешевле сразу перейти на поддерживаемую версию, чем разбираться с последствиями взлома.

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

Как я перевожу сайт на актуальный PHP

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

1. Диагностика. Проверяю версию PHP, Server API, CMS, плагины, логи ошибок и карту функционала сайта.
2. План и оценка. Определяю целевую версию PHP, список несовместимостей и объём правок. Если сайт проще перенести или пересобрать, говорю об этом сразу.
3. Бэкап и копия. Делаю резервную копию и тестовый контур. Все эксперименты идут на копии.
4. Совместимость. Обновляю CMS и расширения, правлю самописный код, проверяю формы, загрузки и оплату.
5. Переключение. Меняю версию PHP на проде, чищу кэш и прогоняю smoke-тесты по чек-листу.
6. Наблюдение. Смотрю логи и поведение сайта после обновления. Если появляются ошибки, сначала определяю причину. При необходимости временно возвращаю прежнюю версию, но это краткосрочная мера: после устранения несовместимости сайт возвращается на исправленное окружение.

Что входит в работу: аудит совместимости, бэкап, тестовая копия, обновление CMS и плагинов, правка несовместимого кода, переключение PHP, проверка форм, загрузок, админки, cron и почты. Для интернет-магазина отдельно проверяю корзину, оформление заказа и оплату.

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

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

Проверка после обновления

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

• Главная, категории, карточки товаров или услуг, страница контактов, поиск и 404.
• Формы обратной связи, заказа, регистрации и подписки. Проверьте не только отправку, но и приход письма.
• Загрузка файлов и изображений: аватар, медиа в админке, вложения в формах.
• Админка: вход, сохранение страниц, редактор, установка и обновление плагинов.
• Cron: задачи CMS, резервное копирование, синхронизации и рассылки.
• Почта: SMTP, уведомления о заказах, письма клиентам.
• Для магазина: корзина, оформление заказа, оплата, статусы заказов и уведомления.
• Логи PHP и сервера: фатальные ошибки, deprecation, 500 и 404.

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

Когда обновление не сработает

Бывают случаи, когда просто поднять версию PHP недостаточно:

• Очень старая CMS. Движок не поддерживает PHP 8.2+ и не обновляется. Тогда нужен переезд на актуальную версию CMS или пересборка сайта.
• Самописный код без исходников. Если нет разработчика и документации, сначала нужен аудит. Иногда дешевле переписать проблемный модуль, чем чинить весь сайт.
• Заброшенное расширение. Плагин несовместим с новой версией и не обновляется. Ищите замену или отказывайтесь от функции.
• Хостер не даёт исправленную версию. Если провайдер не подтверждает исправление и не предлагает поддерживаемую ветку или применимый backport, рассматривайте смену хостинга.

Если обновление невозможно, не оставляйте сайт на старой версии без компенсирующих мер. Но любые ограничения — временные и зависят от конфигурации: согласуйте их с поставщиком и не считайте полной защитой.

Частые вопросы

Сопровождение и поддержка сайта

Защита, обновление, мониторинг, чистка вирусов.

от 5.400 ₽/мес

Подробнее

SEO аудит

Проверка сайта после взлома.

1.800

Подробнее