Критическая уязвимость PHP 21.10.2026. Что делать?

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

Если ваш сайт работает на WordPress, 1С-Битрикс или другой системе на PHP, сейчас стоит проверить его серверное окружение. Первый шаг — узнать у хостинга или администратора, установлены ли исправления для сборки PHP, обслуживающей именно ваш домен. То, что сайт открывается и принимает заявки, ещё не подтверждает наличие исправления.

Что произошло 21 октября 2026 года

В этот день команда PHP опубликовала исправления двух уязвимостей: CVE-2026-109618 и CVE-2026-109619. CVE — уникальный номер проблемы безопасности: по нему хостинг может проверить нужный патч. Обе проблемы имеют критическую оценку CVSS 4.0 — 9,2 из 10. Это оценка серьёзности, а не вероятность взлома конкретного сайта.

Исследователи Wiz используют название PHP2Shell. Если встречаете его в новостях, речь об этом исследовании и связанных проблемах PHP. Дата 21 октября относится к публикации исправлений и раскрытию информации. Это не дата первого появления ошибок в программе.

Если объяснить без устройства памяти: при обработке запросов PHP в некоторых ситуациях неправильно обращается со своими внутренними данными. Условия, при которых это превращается в атаку, зависят от версии, настроек сервера, расширений и поведения приложения. Проблема находится в самом PHP, поэтому исправный код сайта тоже нуждается в проверенном серверном обновлении.

Команда PHP рекомендует обновить установки, обслуживающие веб-запросы. Особенно высокий риск отмечен для mod_php — способа запуска PHP внутри Apache. Подтверждены и сценарии для PHP-FPM, где PHP работает отдельными процессами. Одно название способа запуска не позволяет объявить сайт защищённым. Универсальной смены настройки, заменяющей полный патч, нет.

Чем это грозит бизнесу

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

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

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

Проверьте WordPress и магазины WooCommerce, 1С-Битрикс, Joomla, Drupal, самописные сайты и другие проекты на PHP. Оценивается не только название CMS — системы управления сайтом, — а конкретная сборка PHP, её конфигурация и используемые расширения. На одном сервере разные домены могут работать на разных версиях.

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

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

Что сделать прямо сейчас

1. Выясните, какая сборка PHP обслуживает сайт. Нужны полный номер, поставщик пакета и привязка к вашему домену, а не только версия в консоли сервера.
2. Проверьте наличие исправлений обеих CVE. Подойдёт официальный исправленный выпуск или подтверждение поставщика, что патчи перенесены в его пакет.
3. Сохраните резервную копию файлов и базы данных. Уточните, где лежит копия и как вернуть прежнее рабочее состояние, если обновление нарушит совместимость.
4. Проверьте совместимость CMS, тем, модулей и расширений PHP. При возможности сначала проверьте обновление на закрытой копии сайта; она не должна отправлять настоящие письма и заказы.
5. Установите подходящее исправление в согласованное окно. На обычном хостинге это делает провайдер; на VPS — администратор с учётом способа установки PHP.
6. Проверьте основные функции сайта и фактическое окружение после обновления. Убедитесь, что веб-запросы уже обрабатываются исправленной сборкой, а нужные процессы применили обновление.

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

Увеличить

Какие версии PHP содержат исправления

В четырёх поддерживаемых ветках минимальные официальные выпуски с исправлениями следующие. Более поздний выпуск этой же ветки должен включать эти патчи; перед установкой всё равно проверяют рекомендации поставщика и совместимость проекта.

Надписи «PHP 8.2» недостаточно: она показывает ветку, но не полный выпуск и не состояние патчей. Например, официальный PHP 8.2.34 предшествует исправленному 8.2.35. При этом пакет дистрибутива с более ранним базовым номером может уже содержать нужные исправления.

Такой перенос называют backport: поставщик встраивает исправление безопасности в свою поддерживаемую сборку, сохраняя базовую версию. Для проверки нужны полный номер пакета, уведомление поставщика или его подтверждение по обеим CVE. Одного сравнения цифр с таблицей здесь мало. Таблица говорит об устранении этих двух уязвимостей, а не о полной безопасности сайта.

Как узнать версию и что написать хостингу

Начните с настроек домена в панели хостинга и раздела информации о системе в CMS. Если там видна только ветка, запросите полный номер сборки. Администратор может проверить используемый обработчик запросов и пакет на сервере без публикации служебных данных.

Консольный PHP и PHP сайта могут различаться. Ответ на команду проверки версии в терминале не доказывает, что тот же PHP обслуживает посетителей. Важны настройки конкретного домена и работающих процессов. Не оставляйте в открытом доступе phpinfo.php: такая диагностическая страница раскрывает лишние сведения об окружении.

В поддержку можно отправить этот текст:

Подтвердите, пожалуйста, какая сборка PHP обслуживает мой домен и установлены ли исправления CVE-2026-109618 и CVE-2026-109619. Если используется backport, укажите версию пакета или уведомление о применённом исправлении.

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

Почему нельзя переключать версию наугад

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

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

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

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

Как понять, что обновление прошло успешно

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

Открывающаяся главная — только часть проверки. Сравните ключевые функции с состоянием до работ, убедитесь, что резерв доступен, а по домену подтверждена исправленная сборка. Результат лучше зафиксировать: что установлено, кто подтвердил патч, какие функции проверены и какие ограничения остались.

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

Помощь с обновлением PHP

Проверю окружение и помогу обновить PHP с резервной копией и проверкой сайта. Стоимость — от 5 000 ₽. Состав работ и итоговую сумму согласуем до начала.

Обновление версии PHP: состав работ и обращение

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

Достаточно ли обновить CMS и плагины?

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

Что означает PHP 8.2 в панели?

Это название ветки. Узнайте полный выпуск и поставщика сборки. Для официальных выпусков исправления начинаются с 8.2.35; для пакетов с backport нужно подтверждение поставщика по двум CVE.

Что делать со старым сайтом, который нельзя сразу перевести на новый PHP?

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

Кто обновляет PHP на обычном хостинге?

Пакеты и серверные процессы обычно обслуживает провайдер. Владелец или разработчик проверяет настройки домена, совместимость и работу сайта. На VPS ответственность зависит от договора: наличие сервера не означает, что хостинг администрирует PHP внутри него.

От чего зависит стоимость обновления?

От состояния сайта, текущей ветки, доступного исправления, способа размещения, зависимостей и объёма проверки. Базовая работа для одного совместимого сайта стоит от 5 000 ₽. Крупная миграция, исправление кода и несколько сайтов требуют отдельной оценки до начала.