Критические уязвимости PHP: что нужно знать владельцам сайтов на WordPress.

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

21 октября 2026 года PHP выпустил исправления для двух критических уязвимостей. Обновление WordPress или плагинов их не устраняет. Узнайте, как проверить, затронута ли ваша среда хостинга, и какие шаги следует предпринять.

Вкратце: что произошло

21 октября 2026 года проект PHP выпустил исправления для двух критических уязвимостей в среде выполнения PHP, CVE-2026-109618 и CVE-2026-109619, обе с рейтингом 9.2 по стандарту CVSS v4.0. При определенных условиях они позволяют неавторизованному злоумышленнику выполнять код на веб-сервере. Это недостатки самого PHP, а не ядра WordPress, тем или плагинов, поэтому исправление должно быть получено из пропатченной сборки PHP, установленной на сервере.

Рекомендуемые действия: Попросите вашего хостинг-провайдера подтвердить, что сборка PHP, на которой работает ваш сайт, защищена от обеих уязвимостей. Если вы управляете сервером самостоятельно, установите исправленный пакет PHP и перезапустите PHP.

В рекомендациях проекта PHP они названы уязвимостями RCE (удаление кода из-за нехватки памяти ) (CVE-2026-109618) и RCE (удаление кода из-за устаревшего глобального состояния) (CVE-2026-109619). В обоих случаях запрос, завершившийся неудачей в неподходящий момент, может оставить внутренние данные в недопустимом состоянии, которое PHP будет использовать позже.

Успешная атака запускает код с привилегиями учетной записи, от имени которой работает PHP. В зависимости от конфигурации сервера, это может позволить злоумышленнику прочитать wp-config.php и содержащиеся в нем учетные данные базы данных, получить доступ к базе данных или изменить ее, а также модифицировать файлы и контент сайта. Компрометированный PHP-воркер не предоставляет злоумышленнику автоматически права root на сервере.

Статус эксплуатации (по состоянию на 21 октября 2026 г.)

Фонд PHP заявил, что его команда безопасности не обнаружила функциональной уязвимости в коде, демонстрирующем концепцию (PoC), который появился до релиза, но разработка PoC ускорилась. 21 октября Cloudflare, которая называет эти уязвимости «php2shell», сообщила, что наблюдала трафик атак, направленных на ее клиентов, и что злоумышленники модифицируют свои полезные нагрузки, пытаясь обойти защиту. Ни один из источников не сообщает о подтвержденном успешном взломе. Трафик атак показывает, что злоумышленники активно пытаются взломать сайт, но сам по себе это не подтверждает факт взлома. Мы будем обновлять этот раздел по мере развития ситуации.

Кто потенциально может пострадать

Потенциально затронут любой веб-сайт, работающий на необновленной сборке PHP, независимо от того, какие версии WordPress, темы и плагины он использует. Рекомендации проекта PHP распространяются на все установки PHP, обрабатывающие веб-запросы, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed.

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

Как проверить версию PHP и статус обновлений

В панели управления WordPress перейдите в Инструменты → Состояние сайта → Информация и разверните раздел Сервер . Там отображается версия PHP и API сервера PHP (SAPI), которые обслуживают ваш сайт. Большинство панелей управления хостингом отображают ту же информацию. Если вы используете WP Cerber, в разделе WP Cerber → Инструменты → Диагностика также отображается версия PHP и API сервера.

Исправления содержатся в следующих релизах проекта PHP:

Важно: это версии от разработчиков, а не универсальный тест минимальной версии. Дистрибутивы Linux и коммерческие поставщики с долгосрочной поддержкой (LTS) могут переносить исправления в сборки, сохраняющие более ранний номер версии, включая сборки поддерживаемых веток 8.2, 8.3 и 8.4. Например, Ubuntu 24.04 LTS поддерживает свои пакеты PHP 8.3 под строкой версий на основе 8.3.6 и включает оба исправления в пакет версии 8.3.6-0ubuntu0.24.04.13. Система Site Health сама по себе не может определить, содержит ли сборка поставщика оба исправления. Проверьте уведомление о безопасности поставщика или журнал изменений пакетов, или обратитесь к своему хостинг-провайдеру. Не переключайтесь на сторонний репозиторий пакетов PHP только потому, что ваш номер версии ниже, чем в исправленном релизе от разработчика.

PHP 7.4, 8.0 и 8.1. Исправленные сборки этих веток, основанные на бэкпортах исходного кода проекта PHP, устраняют обе уязвимости с минимальными мерами защиты для версий, поддержка которых прекращена, что уже не так эффективно, как полное исправление, включенное в версии 8.2 и более поздние. Благодаря этой защите процесс PHP, у которого закончилась память, немедленно завершается, поэтому сайт, превысивший лимит памяти, может отображать общую ошибку сервера вместо критического экрана ошибки WordPress. В таких сборках индикатор состояния сайта может показывать один и тот же номер версии до и после обновления, поэтому подтвердите исправление у своего хостинг-провайдера или в журнале изменений пакета. Рекомендуется обновляться до поддерживаемой ветки.

Поддержка PHP 8.2 скоро закончится. Поддержка безопасности PHP 8.2 в рамках проекта PHP завершится 31 декабря 2026 года. Если вы обновляетесь с PHP 7.4, 8.0 или 8.1, выберите PHP 8.3 или более позднюю версию, предварительно сделайте резервную копию сайта и убедитесь в совместимости вашей темы и плагинов. В качестве альтернативы, запросите у своего хостинг-провайдера исправленную сборку вашей текущей ветки.

Почему исправление необходимо применить на сервере?

Уязвимый код является частью среды выполнения PHP, которая запускает WordPress, а не частью самого WordPress.

• Обновление WordPress не устраняет эти уязвимости PHP. Обновление ядра WordPress, тем или плагинов не изменяет среду выполнения PHP.
• Плагины безопасности не могут исправить уязвимости во время выполнения. Некоторые пути эксплуатации уязвимостей могут выполняться до загрузки WordPress, поэтому ни один плагин не получает возможности проверить запрос. Правила брандмауэра веб-приложений (WAF) на уровне хостинга или сети могут уменьшить количество определенных путей атаки, но они не являются полной заменой патчам.
• Изменение настроек внутри сайта не является надежным решением. В рекомендациях проекта PHP содержится предупреждение о недопустимости использования функции ini_set() или файлов FPM .user.ini для применения мер по защите от атак, и то же самое относится к настройкам PHP, измененным в wp-config.php или плагином. Даже меры на уровне сервера, описанные в рекомендациях, лишь снижают уязвимость к определенным путям атак и не делают установку безопасной.

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

Что делать дальше?

Если вы не управляете сервером

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

Устранены ли уязвимости CVE-2026-109618 и CVE-2026-109619 в сборке PHP, обслуживающей мой веб-сайт? Были ли перезапущены соответствующие PHP-процессы для загрузки исправленной сборки?

Если вы управляете VPS или выделенным сервером

1. Обновите PHP. Установите исправленную версию из основного репозитория или пакет из дистрибутива или от стороннего поставщика, в уведомлениях или списке изменений которого подтверждено наличие обоих исправлений.
2. Перезапустите PHP. Перезапустите или перезагрузите PHP-FPM, Apache или любую другую службу, которая запускает PHP для ваших сайтов. Работающие обработчики будут продолжать использовать старый исполняемый файл до тех пор, пока их не перезапустят.
3. Проверьте. Убедитесь в разделе «Состояние сайта», что ожидаемая сборка PHP теперь обслуживает каждый сайт. Затем отдельно подтвердите в уведомлении поставщика или в журнале изменений пакета, что установленный пакет содержит оба исправления. Раздел «Состояние сайта» показывает текущую версию, но не может доказать наличие бэкпорта. Команда php -v может сообщать о другой установке PHP, чем та, которая обслуживает ваш веб-сайт, поэтому не полагайтесь только на неё.

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

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

Подвергается ли мой компьютер или браузер риску при посещении затронутого веб-сайта?

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

Нужно ли мне переустанавливать WordPress?

Нет, это не для устранения этих уязвимостей. Они исправляются обновлением PHP на сервере, а переустановка WordPress не меняет PHP. Переустановка всё же может быть частью процесса очистки сайта, который был взломан.

Могу ли я решить эту проблему без помощи моего хостинг-провайдера?

Это зависит от того, контролируете ли вы среду выполнения PHP. На VPS или выделенном сервере вы можете установить пропатченные пакеты самостоятельно. На общем или управляемом хостинге PHP контролируется хостинг-провайдером. Многие панели управления позволяют переключить сайт на другую версию PHP, но будет ли эта сборка пропатчена, всё равно зависит от хостинг-провайдера.

Источники

• PHP-проект, Уведомление о безопасности: Критические уязвимости удаленного выполнения кода, обновить сейчас , 21 октября 2026 г.
• PHP-проект, GHSA-w8hw-w9fx-j79w: удаленное выполнение кода из-за ошибки нехватки памяти (CVE-2026-109618) , 21 октября 2026 г.
• PHP-проект, GHSA-6wmf-4rv5-p3rp: удаленное выполнение кода из-за устаревшего глобального состояния (CVE-2026-109619) , 21 октября 2026 г.
• PHP Foundation, Сегодняшний релиз по безопасности PHP и как мы усиливаем безопасность PHP , 21 октября 2026 г.
• PHP-проект, поддерживаемые версии .
• php-src commit 712e60f: Предотвращение повреждения состояния с помощью bailout — минимальное средство защиты для версий, поддержка которых прекращена.
• Репозиторий RPM Реми, список изменений php74-php , запись для версии 7.4.33-31, 21 октября 2026 г.
• Ubuntu, страницы состояния безопасности для CVE-2026-109618 и CVE-2026-109619 , 21 октября 2026 г.
• Cloudflare, Cloudflare развертывает средства защиты от уязвимости php2shell , 21 октября 2026 г.